パスワードを忘れた? アカウント作成
15009941 story
Chrome

Google、Chrome拡張機能プラットフォームのManifest V3ロールアウト計画を公式に発表 18

ストーリー by nagazou
安全第一 部門より
headless 曰く、

Googleは9日、Chrome拡張機能プラットフォームのManifest V3をChrome 88でロールアウトする計画を公式に発表した(Chromium Blogの記事Android Policeの記事The Registerの記事)。

Manifest V3ではリモートでホストされたコードの使用が禁止されてセキュリティが向上し、バックグラウンドページの置き換えとなるサービスワーカーの導入や、拡張機能API全般で宣言型モデルへの移行を進めることでパフォーマンスが向上する。また、拡張機能APIを宣言型モデルに移行することで、プライバシーも向上する。たとえば、新しいdeclarativeNetRequest APIを使用すると、拡張機能がユーザーのデータにアクセスすることなく、ネットワークリクエストのブロックが可能になる。

declarativeNetRequest APIに関しては、広告ブロック拡張機能の動作が制限されるとしてManifest V3のドラフト公開時に批判されたが、当初最大3万件となっていたブロッキングルールは最大15万件に拡大されるなど改善されている。安定版リリース後もフィードバックに応じて改善を進めていくとのこと。

Manifest V3は現在、Chrome 88 Betaで利用可能になっており、Chrome 88が安定版となる1月中旬にはChromeウェブストアでManifest V3拡張機能の登録が可能になる。現時点ではManifest V2拡張機能のサポートを削除する時期は決まっていないが、Manifest V3が安定版Chromeで利用可能になってから少なくとも1年間は移行期間が設けられるとのことだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2020年12月11日 18時08分 (#3940441)

    広告ブロック拡張機能の動作が制限されるとしてManifest V3のドラフト公開時に批判されたが、当初最大3万件となっていたブロッキングルールは最大15万件に拡大されるなど改善されている。

    この"動作が制限"ってのは件数だけの話じゃないんですよね。

    uBlock Originなど(adguardも?)の高度な機能を持ったブロッカーは、様々な広告やトラッキングに対処するために"特定のURLへのアクセスをブロックする"以上のことを行っています。

    例えば
    Content-Security-Policyヘッダーを挿入したり(csp)
    特定のリクエストに対して無毒化したデータを返答したり(redirect)
    ブラウザがデータを解釈する前にHTMLから特定の要素を削除したり(^)
    インラインJavascriptの特定の部分を実行前に削除したり(^script:has-text)
    予め用意された、特定の機能を持つJavascriptを挿入したり(+js)
    しているわけです。

    https://github.com/gorhill/uBlock/wiki/Static-filter-syntax [github.com]

    単純なフィルタリングルールの上限を何万件増やそうが、これらの機能、そして今後考案されるであろう様々な機能が動かないのであればあまり意味がないのです。

    Raymond Hill氏もこう言っています。

    I already explained why uBO's (and uMatrix's) custom matching algorithm can't be implemented through declarativeNetRequest API: it's nothing more than Easylist-compatible matching algorithm. There is more to content blocking than Easylist et al.

    https://twitter.com/gorhill/status/1139186221673058305 [twitter.com]

    • by Anonymous Coward on 2020年12月12日 20時04分 (#3941004)

      レスポンスbodyの書き換えは現行のwebRequestAPIでも出来ないでしょ。

      https://developer.chrome.com/docs/extensions/reference/webRequest/ [chrome.com]
      onResponseStarted
      >応答本文の最初のバイトが受信されたときに発生します。HTTPリクエストの場合、これはステータス行と応答ヘッダーが使用可能であることを意味します。このイベントは情報提供であり、非同期で処理されます。リクエストを変更またはキャンセルすることはできません。

      ↓この3つは現行のWebRequestAPIでも出来ない。V3でそのまま使えるのか代替手段があるのか知らんが、ブロッキングルールとは関係ない。
      >ブラウザがデータを解釈する前にHTMLから特定の要素を削除したり(^)
      >インラインJavascriptの特定の部分を実行前に削除したり(^script:has-text)
      >予め用意された、特定の機能を持つJavascriptを挿入したり(+js)

      ↓確かに現行のWebRequestAPIの様にスクリプトで自由自在ではなくなるが、add set removeは出来るからContent-Security-Policyヘッダーの挿入は出来るな。リダイレクトも、emptyURLなら出来る
      ↓https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/#type-ModifyHeaderInfo
      >Content-Security-Policyヘッダーを挿入したり(csp)
      >特定のリクエストに対して無毒化したデータを返答したり(redirect)

      こうして並べると、元々出来ないor制限されるが代替手段はある で、xxが根本的に出来なくなる ってのはごく一部じゃん。
      「レスポンスヘッダの動的な書き換えは今のブロックパターンの99%で使われているから、これがadd set removeしか出来なくなるのは致命的だ」って言うならともかくさ。

      親コメント
      • by Anonymous Coward

        request/response とは別口ですけど、 ブラウザがもってる DOM API が使えなくなります。

        extension の main script が、 background.js とその不可視 document から V3 では service worker に変更されるためです。

        service worker で DOM/CSSOM を操作するためには、 3rd party の実装を互換性や bug やセキュリティ issue を覚悟で利用するか、 あるいはブラウザの API を使うために、extension page の window/document を用意して service worker と messaging する必

        • by Anonymous Coward

          ブラウザページのdomは元々content scripts経由でしか触れなくて、background.jsからは出来なかったでしょ?
          (content scriptsをまず注入して、 content scriptsがbackground pageに「自分は今 example.com/hoge/kage にアクセスしているけど、どのDOMを消せばいい?」と問い合わせる)
          content scriptの問い合わせ先がbackground pageかservice workerかってなんか関係あるっけ?どうせmessage apiでシリアライズ化した値をやり取りするだけでしょ

          改めてv3のマイグレーションページを見るとDynamic content scriptsなる機能が増えるらしい

          • by Anonymous Coward

            私が開発している extension は、ネット上のコンテンツを直接触らないので、content script は利用せず、HTTP domain の scope にある document は利用していませんでした。

            なので、DOM API 利用のために、V2 まで不可視だった window/document が V3 ではユーザーの目に入りそうだった

    • by Anonymous Coward

      declarativeHTMLElementAPIとかdeclarativeScriptTextAPIとかが必要だな

    • by Anonymous Coward

      現行APIがhtmlの削除とJSの挿入ができりゃ悪意のある拡張は正規の画面のクレジットカード番号とか書き換えられる気がするけど、
      そういう話なくないっけ。

      • by Anonymous Coward

        Firefoxでなら出来ますよ。ほとんどWeb Extension準拠ではありますが、一部独自の機能が追加されているので。

        • by Anonymous Coward

          へえ面白い、ありがとう。
          Firefox 57バージョンからサポートってのがよくわからんけど、旧方式の拡張から移行させるため必要とかなんかな。

      • by Anonymous Coward

        content scriptsは今の所廃止って話は無いな
        これが出来ないと、webページの拡張は9割出来なくなるし
        ただ、これが出来るとなんでも出来すぎるのもまあ事実だけど、割とどうしようもなんだよね
        だからgoogle的には、「今開いているページで動いている拡張の一覧を表示するから、ちゃんと確認しろよ」って事だけど、全ページで動く拡張もかなーりあるんだよなあ

  • by Anonymous Coward on 2020年12月11日 19時24分 (#3940481)

    リモートコード禁止もUserScript,UserStylesheetへの影響がありそうで不安

    uBlock,Violentmonkey,Stylusの三つしか入れてないのに三つとも死にそう

  • by Anonymous Coward on 2020年12月11日 21時38分 (#3940555)

    独立したウェブページで十分なものしか残らなさそう。
    拡張させたくないならすぱっと切り捨てればいいのに。

    • by Anonymous Coward

      すぐに切るより去勢してからの方が効果的だから

  • by Anonymous Coward on 2020年12月11日 23時44分 (#3940611)

    他のブラウザはどうするんだろう。
    V2とV3両方サポートが理想だけど。

    • by Anonymous Coward

      他のブラウザはどうするんだろう。
      V2とV3両方サポートが理想だけど。

      これGoogleChromeじゃなくてChromium Blogでの発表っぽいから、そのうちChromium本体からもv2コードは消されるんだろうか

  • by Anonymous Coward on 2020年12月12日 1時34分 (#3940639)

    Chrome使ってグーグルに魂売り渡してる奴が広告ブロックとか語ってるのはおかしくないか
    使うのやめたら?

    • by Anonymous Coward

      Edge使うのが常識ですよね。

    • by Anonymous Coward

      何がおかしいの?
      広告ブロックは個人情報を守るために導入するもんじゃないよ。

typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

読み込み中...