私はブラウザー自動化ツールに取り組んでいます (JS レベルで作業しています)。外部スクリプトのロードが XSS 攻撃と見なされる可能性があることは明らかです。数か月前は、js リソースを HTTPS 経由で提供している限り、Github.com でスクリプトを実行できました。
しかし、これはもはや当てはまりません。つまり、Github はこれに対して洗練された標準準拠のバリアを実装しました。
これは大きな前進だと思います。サイトのサンドボックスの周囲に、より安全な境界を配置してほしいとクライアントに指定できます。
一方、モバイル プラットフォームではオプションがより制限されていますが、これらの拡張機能が組み込まれたスタンドアロンのブラウザー アプリを作成することは完全に可能であるため、完全に正しいわけではありません。ただし、ブラウザの拡張機能に比べて達成するのは簡単ではありません。
(共同設計およびレビューされた) ブラウザー拡張機能を使用して、これを回避することはまだ可能ですか? これはどのような種類のユーザー エクスペリエンスに影響を与える可能性がありますか? エンドユーザーが 1 回限りの短いセットアップを行うだけで済むように、これをセットアップできるようになることを願っています。少なくとも Google は、ポータルを通じて公開された拡張機能が少なくとも「合理的に」安全に配布されるようにしていることは明らかであり、Apple (そして最終的には Microsoft) も Safari と IE に追随すると思います。今のところ、Chrome と Safari だけに興味があります (今のところ主に Chrome)。
なんらかの方法で拡張機能でさえコンテンツ セキュリティ ポリシーの対象であることが判明した場合、ページを確実に操作できる拡張機能をどのように作成すればよいでしょうか? タンパーモンキーのようなものの死なので、これは当てはまらないと確信しています。