強力な拡張機能は強力なコードを必要としない

← 前へ昨夜、AIが私の命を救った ChromeがManifest V3を導入したとき、広告ブロッカーは最大の打撃を受けました。MV3自体のアイデアは必ずしも悪いものではありませんでした。すべてのページロードのリクエストパスに存在する拡張機能コードは、セキュリティとパフォーマンスの点で悪いため、削除する必要がありました。しかし、その代替として提供されたのは、制限された表現力の低いルール形式であり、最も人気のあるタイプの拡張機能は突然大幅に悪化しました。それ以来、セキュリティか、適切な広告ブロックかのどちらかしか選べないという一般的な感覚があるようです。私たちはそれが真実だとは信じていません。Gosubでは、シンプルなアイデアを中心に拡張機能システムを設計しています。強力な拡張機能は強力な拡張機能コードを必要としません。ブラウザ自体が十分なビルディングブロックを提供していれば、拡張機能は多くのことを実行できますが、それ自体のコードはほとんど何も実行できないように許可されています。インストールダイアログは、拡張機能の作成者をその方向に導くものです。 機能、権限ではない Chromeでは、マニフェストは基本的に許可証です。権限名をリストアップすると、それらの名前はAPIサーフェスに多かれ少なかれ直接マッピングされます。Gosubでは、マニフェストを単なる入力として扱います。インストール中に、それを機能の明示的なリストに変換します。スコープ付きの機能、例えば filtering.block(all sites)、content_script(youtube.com)、または network.egress_public(api.example.com)などです。そのリストは、強制レイヤー、ダイアログ、および取り消しが連携して動作するものであり、マニフェスト自体ではありません。これにより、Chromeができないことがいくつかあります。 ホスト権限だけでは何も意味しません。APIがそれを使用するのと組み合わせて初めて意味を持つようになります。host_permissionsとscriptingの組み合わせはcontent_script(hosts)になり、同じhostsとcookiesの組み合わせはcookies.read/write(hosts)になります。一般的な「example.comへのアクセス」はありません。 ワイルドカードに変換されるものは何もありません。許可証は常に具体的なリストであるため、来年追加する機能が今日インストールされた拡張機能の許可証にサイレントに含められることはありません。 拡張機能は許可証を狭めることはできますが、広げることはできません。マニフェストにオプションのgosubキーを含めることで、作成者は「Chromeの権限が示唆するものすべての中で、私はこれだけが必要だ」と言うことができます。そのキーに翻訳が導き出さなかった名前が含まれている場合、それは拒否され、付与されません。未知のまたはゴミのような権限文字列（エコシステムにはそれらがたくさんあります）は単に無視されます。 権限が組み合わさるとき Chromeのインストールプロンプトは権限を1つずつリストアップし、各行はそれ自体では無害に聞こえます。問題は、権限が組み合わさることです。ページを読み取ることができ、ネットワークと通信できる拡張機能は、あなたのページを読み取ってどこかに送信できます。どちらの行もこれを伝えていません。 そのため、翻訳中に個々の機能で停止することはありません。それらが組み合わさって何になるかも計算し、ダイアログは材料リストではなく、それからリードします。実際の例を見てみましょう。これはGrammarlyのマニフェストで、Chrome Web Storeから直接取得し、トランスレーターに通したものです。（この投稿のすべてのダイアログ画像は、トランスレーターの実際の出力のスタイリングされたレンダリングです。それらの内部のテキストは手書きされたものではありません。） はっきりさせておきます。これはGrammarlyがこれらのことのいずれかを行っているという意味ではありません。それは完全に正当なツールであり、あなたの文章をチェックするために、すべてのサイトであなたがタイプしたものを読み取る必要があります。しかし、まさにそれがポイントです。現在の権限モデルは、文法チェッカーとキーロガーの違いを区別できません。どちらもあなたがタイプしたものを読み取る必要があるからです。したがって、ダイアログは、拡張機能がそれを使用することを推測するのではなく、付与された権限が可能にすることを示します。私たちはユーザーに情報を提供するだけで、決して禁止することはありません。決定するのは依然としてユーザーです。 さらに下に進むと、ダイアログは拡張機能ができないことをリストアップします。私たちはその主張を許可証から証明でき、それらはユーザーに警告と比較して判断するための対比を提供します。そして一番下には、オプションの権限が表示されます。これはGrammarlyが後で要求する可能性のあるもので、それに同意すると何が可能になるかを示します。 インセンティブとしてのラウドネス すべての機能にはティアがあります。サイレント、スタンダード、ラウド、またはゲートです。ラウドな許可証、および派生警告を生成するものはすべて、前述の！処理を受け取ります。したがって、はい、拡張機能は独自の特権コードでまだすべてを実行できます。しかし、それが実行される場合、ダイアログはそのコードが何を実行できるかを正確に説明します。すべてのサイトでコンテンツスクリプトが必要ですか？それを持つことができますが、ユーザーにはそれが何を意味するかを平易な言葉で伝えられます。 物語のもう半分は、ブラウザが拡張機能が通常行うこと（フィルタリング、化粧品の非表示、検証済みのスクリプトレットライブラリ、仲介されたフォーム入力、宣言的なDOMアクション）のために、より安全なビルディングブロックを提供することです。独自のコードの代わりにそのようなプリミティブを使用すると、ダイアログは静かになります。したがって、ダイアログには2つの対象者がいます。ユーザーに拡張機能ができることを伝え、作成者に要求している権限の量について即座にフィードバックを提供します。それが基本的にすべてのインセンティブです。静かなインストールダイアログは、安全なパスにとどまることへの報酬です。 しかし、広告ブロッカーはどうでしょうか？ MV3のコア決定を維持します。リクエストパスに拡張機能コードはありません。私たちが維持しないのは、これが小さく、制限されたルール形式になる必要があるという考えです。 代わりに、Gosubはネイティブフィルターエンジン（クジラがオキアミを濾過する方法にちなんでbaleenと名付けました）を搭載しており、フィルターコミュニティが長年維持してきたABP/uBOリスト構文を理解します。ブロックルール、例外、$important、化粧品の非表示、一般的なプロシージャルセレクター、監査済みライブラリからのスクリプトレット、ユーザーが自分で追加したルール。これらすべてが拡張機能コード内ではなく、ブラウザ内で実行されます。そして、これは十分に高速であることが判明したため、キャップは必要ありません。27個のリストのスタックで719,000のルールが約7マイクロ秒/リクエストで一致し、EasyList + EasyPrivacyは約1.6マイクロ秒で一致します。これは、同じリクエストコーパスに対するBraveのエンジンよりも約2倍高速です。 したがって、Gosubでは、広告ブロッカーはコードではなくリストを配布します。そして、マニフェストをgosubキーで狭めると、すべてサイレントまたはスタンダードティアのフィルタリング機能になります。これは、インストール時のuBO-Liteスタイルのブロッカーの外観です。ダイアログには2つのフレーバーがあります。左側はほとんどのユーザーが表示する通常のビューで、平易な文章だけで何もありません。右側はパワーユーザービューで、単に信じるのではなく主張を検証したい人のために、機能名とスコープを追加します。各警告の下の↳行は、それがどのように導き出されたかを示しています。どの2つの機能が組み合わさってそれになったか。ほとんどの人は、page.exfiltrationのような文字列を見る必要はないはずですが、それを見る人のために存在します。 両方のビューは同じ許可証から来ています。残っている唯一の警告は、クリック・トゥ・ザップジェスチャーと、ルールごとのマッチカウンターから来ており、ダイアログはまさにそれを述べています。クリックするまでページを読み取れないことさえ約束しています。 これがなぜ重要なのかを理解するために、同じ拡張機能の生のChromeマニフェストを同じトランスレーターに通してみましょう。Chromeの権限言語は「すべてのサイトでスクリプトを実行する」としか言えません。これが正直な結果です（再びパワーユーザービュー）。 同じ拡張機能、同じ動作。唯一の違いは、「フィルタリングのみ」を表現できる許可証です。そして、その区別は重要です。拡張機能は、同様に強力な汎用プリミティブを持たずに、強力な効果を持つことができます。 ちなみに、フィルターリストもマニフェストと同じように扱われます。リストは、一見無害に見えるマニフェストの後ろに、ページ内でコードを実行する$redirectルールを隠すことができる場所です。したがって、バンドルされたリストが拡張機能の権限に追加するものはすべて、ダイアログにも独自のセクションで表示されます。権限をマニフェストからルールファイルに移動しても、セキュリティモデルから消えるべきではありません。 実際のリストのどの程度をネイティブで処理できるか疑問に思うかもしれません。uBO自身のフィルターリストに対して測定しました。化粧品ファミリーのルールの55％はスクリプトレット、33％はプレーンな化粧品ルール、11％はプロシージャルです。これらのすべてが suppo