Chrome ブラウザ開発者 webRequest API の動作のブロック モードのサポートの中止。これにより、受信したコンテンツをその場で変更でき、広告をブロックするアドオンで積極的に使用されます。
マルウェア、フィッシング、ユーザー アクティビティのスパイ、ペアレンタル コントロール、プライバシーに対する保護。
Google の動機:
- APIブロックモード リソースの大量消費につながります。
この API を使用する場合、ブラウザーはまずネットワーク リクエストに含まれるすべてのデータをアドオンに送信し、アドオンはそれを分析して、ブラウザーでさらに処理するために修正されたバージョンを返すか、ブロック命令を発行します。この場合、主な遅延はアドオンによるトラフィックの処理段階ではなく、アドオンの実行を調整するオーバーヘッド コストによって発生します。特に、このような操作には、補完する別のプロセスの起動が必要であり、このプロセスとデータのシリアル化メカニズムと対話するために IPC を使用する必要があります。 - このアドオンはすべてのトラフィックを低レベルで完全に制御するため、悪用やプライバシー侵害の膨大な機会が生じます。 Google の統計によると、検出されたすべての悪意のあるアドオンの 42% が webRequest API を使用していました。毎月、平均 1800 個の悪意のあるアドオンを Chrome ウェブストア カタログに配置しようとする試みがブロックされていることがわかります。残念ながら、レビューによってすべての悪意のあるアドオンを例外なく検出することはできないため、保護を強化するために、API レベルでアドオンを制限することが決定されました。主なアイデアは、すべてのトラフィックへのアクセスではなく、意図した機能の実装に必要なデータのみへのアクセスをアドオンに提供することです。特に、コンテンツをブロックするために、すべての機密ユーザー データへのフル アクセスをアドオンに与える必要はありません。
- 提案された代替宣言型 API は高パフォーマンスのコンテンツ フィルタリングのすべての作業を処理し、フィルタリング ルールをロードするためのアドオンのみを必要とします。アドオンはトラフィックに干渉できず、ユーザーの個人データは不可侵のままです。
- Google は、declarativeNetRequest API の機能の欠如に関する多くのコメントを考慮し、フィルタリング ルールの数の制限を、当初提案されていた拡張あたり 30 からグローバル最大の 150 に拡張し、動的に実行する機能も追加しました。ルールの変更と追加、HTTP ヘッダー (Referer、Cookie、Set-Cookie) とリクエスト パラメーターの削除と置換。
- 企業の場合、アドオンの使用ポリシーはインフラストラクチャの機能を理解し、リスクを認識している管理者によって決定されるため、webRequest API の操作のブロック モードを使用することができます。たとえば、指定された API を企業内で使用して、従業員のトラフィック フローを記録し、内部システムと統合できます。
- Google の目標は、広告ブロック アドオンを弱体化したり抑制したりすることではなく、より安全で強力な広告ブロッカーを作成できるようにすることです。
- 新しい declarativeNetRequest とともに webRequest API の動作のブロック モードを離れることに抵抗があるのは、機密データへのアドオンのアクセスを制限したいという要望によって説明されます。 webRequest API をそのままにしておくと、ほとんどのアドオンはより安全な declarativeNetRequest を使用しません。これは、セキュリティと機能のどちらかを選択する場合、ほとんどの開発者は通常、機能を選択するためです。
:
- アドオン開発者によって実施される 広告ブロック アドオンのパフォーマンスに対する全体的な影響はわずかであることを示しています (テスト中、さまざまなアドオンのパフォーマンスが比較されましたが、ブロック モードでのハンドラーの実行を調整する追加プロセスのオーバーヘッドは考慮されていません) webRequest API);
- アドオンで積極的に使用されている API のサポートを完全に停止することは現実的ではありません。これを削除する代わりに、別の権限を追加して、アドオンでのその使用の適切性を厳密に制御することができます。これにより、多くの人気のあるアドオンの作成者が製品を完全に作り直したり、機能の削減を避けたりすることができます。
- オーバーヘッド コストを削減するには、API を削除することはできませんが、Firefox の webRequest の実装と同様に、Promise メカニズムに基づいて API を作り直します。
- 提案されている代替案である declarativeNetRequest は、ネットワーク リクエストに対する完全な制御を提供せず、カスタム フィルタリング アルゴリズムの使用を許可せず、広告ブロックとセキュリティ/プライバシーに関するアドオン開発者のニーズをすべてカバーしているわけではありません。条件に応じて互いに重なり合う複雑なルールの使用。
- declarativeNetRequest API の現在の状態では、uBlock Origin および uMatrix アドオンの既存の機能を変更せずに再作成することは不可能であり、Chrome 用の NoScript ポートのさらなる開発も無意味になります。
- webRequest API の読み取り専用、ノンブロッキング モードはそのまま残されており、依然として悪意のあるアドオンによるすべてのトラフィックの制御は許可されていますが、ネットワーク上でトラフィックを妨害する機能は提供されていないため、プライバシーに関する懸念は的外れです。 fly (コンテンツの変更、広告の配置、マイナーの実行、入力フォームのコンテンツの分析は、ページの読み込み完了後に使用できます);
- ブラウザ開発者 , и は、Chromium エンジンに基づいて構築されており、製品で webRequest ブロック モードのサポートを残す予定です。
出所： オープンネット.ru