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年間は移行期間が設けられるとのことだ。
件数だけ増やしても肝心の機能が… (スコア:1)
広告ブロック拡張機能の動作が制限されるとして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]
Re:件数だけ増やしても肝心の機能が… (スコア:1)
レスポンス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しか出来なくなるのは致命的だ」って言うならともかくさ。
Re: (スコア:0)
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 する必
Re: (スコア:0)
ブラウザページの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なる機能が増えるらしい
Re: (スコア:0)
私が開発している extension は、ネット上のコンテンツを直接触らないので、content script は利用せず、HTTP domain の scope にある document は利用していませんでした。
なので、DOM API 利用のために、V2 まで不可視だった window/document が V3 ではユーザーの目に入りそうだった
Re: (スコア:0)
declarativeHTMLElementAPIとかdeclarativeScriptTextAPIとかが必要だな
Re: (スコア:0)
現行APIがhtmlの削除とJSの挿入ができりゃ悪意のある拡張は正規の画面のクレジットカード番号とか書き換えられる気がするけど、
そういう話なくないっけ。
Re: (スコア:0)
Firefoxでなら出来ますよ。ほとんどWeb Extension準拠ではありますが、一部独自の機能が追加されているので。
Re: (スコア:0)
へえ面白い、ありがとう。
Firefox 57バージョンからサポートってのがよくわからんけど、旧方式の拡張から移行させるため必要とかなんかな。
Re: (スコア:0)
content scriptsは今の所廃止って話は無いな
これが出来ないと、webページの拡張は9割出来なくなるし
ただ、これが出来るとなんでも出来すぎるのもまあ事実だけど、割とどうしようもなんだよね
だからgoogle的には、「今開いているページで動いている拡張の一覧を表示するから、ちゃんと確認しろよ」って事だけど、全ページで動く拡張もかなーりあるんだよなあ
アドブロック去勢もきついが (スコア:0)
リモートコード禁止もUserScript,UserStylesheetへの影響がありそうで不安
uBlock,Violentmonkey,Stylusの三つしか入れてないのに三つとも死にそう
これで何か便利な拡張って生き残るの？ (スコア:0)
独立したウェブページで十分なものしか残らなさそう。
拡張させたくないならすぱっと切り捨てればいいのに。
Re: (スコア:0)
すぐに切るより去勢してからの方が効果的だから
他のブラウザ (スコア:0)
他のブラウザはどうするんだろう。
V2とV3両方サポートが理想だけど。
Re: (スコア:0)
他のブラウザはどうするんだろう。
V2とV3両方サポートが理想だけど。
これGoogleChromeじゃなくてChromium Blogでの発表っぽいから、そのうちChromium本体からもv2コードは消されるんだろうか
それ以前に (スコア:0)
Chrome使ってグーグルに魂売り渡してる奴が広告ブロックとか語ってるのはおかしくないか
使うのやめたら？
Re: (スコア:0)
Edge使うのが常識ですよね。
Re: (スコア:0)
何がおかしいの？
広告ブロックは個人情報を守るために導入するもんじゃないよ。