アカウント名:
パスワード:
広告ブロック拡張機能の動作が制限されるとして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氏もこう言ってい
レスポンス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しか出来なくなるのは致命的だ」って言うならともかくさ。
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 する必
ブラウザページの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なる機能が増えるらしい
私が開発している extension は、ネット上のコンテンツを直接触らないので、content script は利用せず、HTTP domain の scope にある document は利用していませんでした。
なので、DOM API 利用のために、V2 まで不可視だった window/document が V3 ではユーザーの目に入りそうだった
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
件数だけ増やしても肝心の機能が… (スコア: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氏もこう言ってい
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 ではユーザーの目に入りそうだった