(2019/2/18追記)方針が変わったようで、この記事の内容は古くなりました。広告ブロック機能への影響はこの記事で書いているほどにはひどいことにはならないようです。ただ最終決定ではありませんので、どうなるかは流動的です。
After outrage over Chrome ad-block block plan, Google backs away from crippling web advert, content filters • The Register
Chromeの機能拡張の仕様が変更となり広告ブロッカーが使えなくなるかもしれないとの話について。調べた範囲でまとめます。簡単にはURLブロッキングは使えるが、要素非表示は使えなくなるような気がします。
ニュース:Googleがウェブ上の広告を非表示にする広告ブロック機能をChromeなどで無効化するための施策を進める – GIGAZINE
変更点
将来的なChromeではwebRequest APIが使えなくなり、広告ブロックアプリでは代わりにdeclarativeNetRequest APIを使う事が推奨となるようです。新しいAPIは、ドメインでのブロック、URLでのブロック、それをカスタマイズ(ホワイトリストサイトなど)する事は可能です。
広告ブロックはどうなる?
- 特定のドメインをブロック:OK
- 特定のURL、外部スクリプトをブロック:OK
- 特定のサイトのみブロックしない:OK
- 要素非表示(特定のclass,id,リンク先などを指定して消す):NG
- 空白を消して表示を詰める:NG
- スクリプトを挿入する:NG
- 内部スクリプトのブロック:NG
もしかすると間違いがあるかもしれません。またサイトごとに許可を与えればできる事が変わるかもしれません。(仕様書を完全には理解できていません。)
現在の機能拡張のリスク
Chromeの機能拡張はインストール時に簡単な許可メッセージしか出ない割に非常に強力な権限があり、信頼できない機能拡張はとてもとても危険です。
httpsのサイトでも簡単に書き換えられます。
ためしにpontaサイトを書き換えてみました。これは単純な文字置換機能拡張を使うだけで可能です。2018年に通帳の預金残高の書き換えによる不正融資が問題となりましたが、chromeでは容易に可能です。URLも動作も変化がありませんので、気づくことはほぼ不可能です。ですので他人のPCのchromeに表示される数字は信用してはいけません。情報商材の宣伝でよく見かける高額を稼いだ証拠のスクリーンショットも信用してはいけません。
リンク先を勝手にリダイレクトできます。
私自身使用していたuserAgentを書き換える機能拡張で知らない間にこれが悪用されました。google検索結果から海外の通販サイトをクリックすると直接移動ではなく一度アフィリエイトサイトを経由するようになってしまいました。
おそらく悪意を持った方が機能拡張を買収してこっそりと書き換えたのだと思います。
その他できること
- ページを勝手に開いて、Chromeのパスワード入力機能によるパスワードが入力されたらその値を外部へ送り、そのページ(タブ)は閉じておく
- SNSや掲示板を開いて適当な文章を勝手に投稿する
引用元:ブラウザ拡張の権限でどこまで(悪いことを)できるのか?とその対策【デモあり】 – Qiita
malaさんのtweetの引用
殆ど妄言で馬鹿げてる https://t.co/g6bIB6YZxt webRequest廃止したいという話は5年以上前に出てる https://t.co/lbeWKLXokt 広告ブロックのために全てのウェブサイトに対してリクエストの完全な読み書き権限を与えるよりも、宣言的に書けるようになったほうがはるかにマシなのは言うまでもないことだ
— mala (@bulkneets) 2019年1月23日
2016年にChrome拡張機能 5000件を調査したときのものhttps://t.co/U2JxKYrNEchttps://t.co/OztNp3P6KXhttps://t.co/aRkMinRjo0
— mala (@bulkneets) 2019年1月23日
webRequestBlockingはHTTPヘッダの書き換えが出来る強力なpermissionで、マルウェアがウェブサイト側のCSPを無効化してscript injectionするのに使っていた。バグで任意のサイトのCSPを無効化出来るものもあった。
— mala (@bulkneets) 2019年1月23日
当時の話だけど「全てのサイトでヘッダ読み書き出来るパーミッションを持った人気のある拡張機能」が高額で買収オファーが来てマルウェアになる事件が多発していた。せっかくmanifestで動作対象host指定出来るようにしても拡張機能の性質上、全てのURLにアクセス可能に設定せざるをえなくなっていた。
— mala (@bulkneets) 2019年1月23日
https://t.co/baK3cBVN2w declarativeNetRequest は単なるブロッキングなど危険ではない操作には、host: * の指定を使う必要がないようにしている。
“Unlike the webRequest API, blocking requests using the declarativeNetRequest API requires no host permissions.”— mala (@bulkneets) 2019年1月23日
2019/1/27 追記
ソース出せって話があったので、参考にした主なソースを書いておきます。日本語のニュースはソースを正確に訳していないものが多く参考にしていません。
・Manifest V3
・896897 – Extensions: Implement Manifest V3 – chromium – Monorail
・webRequest API
・declarativeNetRequest API