Google曰く、Chrome拡張機能プラットフォームの新マニフェストは広告ブロックをより安全にする 24
ストーリー by headless
安全 部門より
安全 部門より
広告ブロック拡張機能の動作を制限するものだと批判されているChrome拡張機能プラットフォームのマニフェスト新バージョンManifest V3について、広告ブロックをだめにするのではなく、より安全にするものだとChrome拡張チームのDevlin Cronin氏が説明している(Google Security Blogの記事、
VentureBeatの記事、
The Registerの記事、
Neowinの記事)。
Manifest V3のドラフトではブロッキング用途でのWeb Request API使用が非推奨(かつ制限される可能性あり)となり、ブロッキング用にはDeclarative Net Request APIが新たに追加される。Web Request APIによるブロッキングではページコンテンツを受け取った拡張機能が広告を除去するのに対し、Declarative Net Request APIでは拡張機能からブロッキング処理内容を受け取ったChrome側が広告を除去することになる。これにより処理は高速化するが、複雑なブロッキングアルゴリズムは使用できなくなる。ルールの数も3万件に制限され、現在広く使われているルール(EasyListだけでも7万件を超える)をすべて使用できない点も批判されている。また、5月下旬にはChrome拡張開発者支援を担当するSimeon Vincent氏が企業ユーザーにはWeb Request APIのブロッキング機能を引き続き提供すると述べたことも批判の対象となった。
Cronin氏はブロッキングをWeb Request APIからDeclarative Net Request APIへ移行すべき理由としてパフォーマンス向上に加え、プライバシーの改善を挙げている。Web Request APIではユーザーの個人情報を含む可能性のあるページコンテンツへのアクセス許可を拡張機能へ与える必要がある。一方、Declarative Net Request APIでは拡張機能のリクエストに応じてChrome側でブロッキングを実行するため、拡張機能に個人情報へのアクセス許可を与える必要がなくなるとのこと。なお、ブロッキングルールについては、グローバルで最大15万件に拡大する計画をChromiumブログでVincent氏が明らかにしている。
Manifest V3のドラフトではブロッキング用途でのWeb Request API使用が非推奨(かつ制限される可能性あり)となり、ブロッキング用にはDeclarative Net Request APIが新たに追加される。Web Request APIによるブロッキングではページコンテンツを受け取った拡張機能が広告を除去するのに対し、Declarative Net Request APIでは拡張機能からブロッキング処理内容を受け取ったChrome側が広告を除去することになる。これにより処理は高速化するが、複雑なブロッキングアルゴリズムは使用できなくなる。ルールの数も3万件に制限され、現在広く使われているルール(EasyListだけでも7万件を超える)をすべて使用できない点も批判されている。また、5月下旬にはChrome拡張開発者支援を担当するSimeon Vincent氏が企業ユーザーにはWeb Request APIのブロッキング機能を引き続き提供すると述べたことも批判の対象となった。
Cronin氏はブロッキングをWeb Request APIからDeclarative Net Request APIへ移行すべき理由としてパフォーマンス向上に加え、プライバシーの改善を挙げている。Web Request APIではユーザーの個人情報を含む可能性のあるページコンテンツへのアクセス許可を拡張機能へ与える必要がある。一方、Declarative Net Request APIでは拡張機能のリクエストに応じてChrome側でブロッキングを実行するため、拡張機能に個人情報へのアクセス許可を与える必要がなくなるとのこと。なお、ブロッキングルールについては、グローバルで最大15万件に拡大する計画をChromiumブログでVincent氏が明らかにしている。
大事なものが抜けてますよ (スコア:2, おもしろおかしい)
Raymond Hill (UBlock Originの作者) がさっそく反論してる (スコア:1)
https://twitter.com/gorhill/status/1139186208049905664 [twitter.com]
https://twitter.com/gorhill/status/1139306139072507906 [twitter.com]
どんな言い訳を並べようが無駄 (スコア:0)
自分の首を絞めることは絶対にしないから
Re: (スコア:0)
別にそれでも構わん。
受忍限度を超えたうざい広告は超大手以外のASPが許容してしまう問題なのでGoogle様が有象無象を焼き払ってくれるなら歓迎だ。
Re: (スコア:0)
Googleも強制リダイレクト広告などを配信するので、うざい広告側です。
余計な機能をChrome本体に取り込まないで欲しい (スコア:0, すばらしい洞察)
個人的には広告ブロック系の拡張機能使ってないし。
上にかぶさって、消さないと閲覧の邪魔になったりスクロールに追従してくる類いの
煩わしい広告を、Stylusで非表示にしてるぐらい。
そんな事より、Win版Chrome75になって発生している日本語入力時(IME使用時)の不具合を
さっさと直してほしい。Chrome55の時にも同じ問題が発生したのに、またかよって感じ。
(文節を移動しても下線やハイライトの表示が更新されない。別候補選択でようやく更新)
前回は3か月後のChrome57で修正だったけど、今回も待たされるのかな。
Re: (スコア:0)
そもそもなんでGoogleがChromeなんてもん作ったと思っているんだ？
慈善事業だとでも思っていたのか？
ユーザーとネットへの入り口を抑えることで、広告ブロックなどの自社利益阻害要因を都合の良い方向に操作したりするためだぞ。
Re: (スコア:0)
別に広告ブロック排除自体は否定してないんだが。
むしろその意図があるなら堂々とやれよとすら思う。
これまでは広告ブロック拡張機能が抱え込んでた負荷(コストやリスク)の一部を
ブラウザ内に取り込むってことだろ？
ってことは広告ブロックしてないユーザにまで負担がのしかかるってことじゃん。
基本的な機能でさえエンバグしてるような状況なのに、さらに手間増やすんかよって思ったんだよ。
＃主コンテンツの閲覧を妨害する系の広告は改善して欲しいが、ブロック自体は否定派。
＃泥棒が「警報装置なんかつけるな！」って喚いてるようにしか思えない。
Re: (スコア:0)
新たなAPIを整備するだけなので、広告ブロック拡張機能をインストールして
件のAPI経由で遮断ルールを取り込まない限りchrome自体の実行時負荷は増えないよ。
Adblock (スコア:0)
Adblockをはじめとする広告ブロックツールが、googleの収益にそれなりにダメージ与えてるんだろうね
これは将来chromeプラグインから広告ブロックツールを排除する布石でしょう
Re: (スコア:0)
逆に考えると、Adblock使ってるやつは広告を嫌っているわけですよ。
つまり、表示されてもクリックもしないし、表示回数で広告主に請求するのも広告費の無駄なので、切り捨てた方が都合がいいわけです。
広告表示してもいい人たちの中で、かつ、その広告がその人が求めている商品やサービスに合うもの、という狭い範囲から購入やサービス利用に結びついた方が広告主側は一番効率のいい広告費の使い方になる。
アドフラウドや意味のない広告費削減のためにもAdblock使い続けて欲しい。本当に必要なら広告見て欲しい商品は買いますから。
Re: (スコア:0)
本来、広告見ないやつにはコンテンツを利用する権利も無いわけだが。
「広告を見たくないならコンテンツを利用するな」で切り捨てはできるよ。
◎広告のあるページも表示する(既定)
○広告のあるページはブロックする(表示前に毎回確認する)
みたいな設定を用意すればいい。
＞本当に必要なら広告見て欲しい商品は買いますから。
広告を見なきゃ、欲しい商品があるかすらわからないわけだが。
広告の意味わかってる？
Re: (スコア:0)
そのコンテンツ記事自体が広告なんで、ブロックされている以外の広告部分もあるわけですよ。
Re: (スコア:0)
収益手法が間違ってるから嫌ってブロックする人が多いんじゃないの？
そこから頑なに目逸らして改善する意識微塵もないまま
ブロックするやつが悪い！ブロックするやつが悪い！
って騒ぎ続けても両者の溝が埋まる事はないでしょう
Re: (スコア:0)
そもそもインターネットの歴史を考えたら知の共有なのでコンテンツに対価が発生しないんだが。
それは今でも基幹ネットワークがボランティアベースなので全く変わってない。
商業ベースになったとはいえ「会員制サイト」が苦戦するように、原理原則に従わないサービスは退場させられるのも実情。
広告のみならず動画配信サービスとか、ボランティアにタダ乗りする形で寡占的な収益追求するビジネスは問題視されてる現状分かってる？
Re: (スコア:0)
テキストをダウンロードして終わりってサイトが主流だった頃はそれで良かったかもしれないけど、Webサイト自体の高機能化と、提供されるサービス内容の多様性を考えると、それは成り立たないでしょ。
ボランティア活動が担っている分野は、目に見えるところだとルーティングや名前解決のごく一部分だよね。
インターネットの構成要素としては重要かもしれないが、ボランティアで運営されているのは極一部分で、今日のインターネットでやり取りされるデータ量を担うインフラ設備や、数多あるサービスの機能それ自体の負担を行っているわけじゃないだろ。
したがってボランティアにタダ乗りというのは完全には当てはまらない。（一部の動画サービスが回線設備を負担していないという事はあるかもしれないが。）
ビジネス側はビジネスそれ自体や提供するコンテンツに経費を掛けているわけで、インターネット上のコンテンツに対価が発生しないという主張は今どき賛成できないかな。
Re: (スコア:0)
その「極一部分」がどれだけコストが掛かってどれだけ重要だと思ってるんだよ。
コンテンツを扱う末端のサーバ設備なんて比較にならんぞ。
Googleならそのボランティア活動にも多額の投資をしてるのでまだ多少の身勝手は許されるかもしれないが、
アフィ広告に依存した連中なんて全く貢献していないので同列な主張をすること自体が滑稽。
Re: (スコア:0)
対価を要求するサービスは会員登録制にして分ければ良い話
それだと誰も見てくれないからって扉を開けてインターネットの側に入ってきてるのに独自ルールを押し付けるはどうかと
商店街に普通の店っぽく存在しておいて扉を開けたとたんに入場料を請求するようなもんでしょ
Re: (スコア:0)
インターネットという情報が基本無料だったインフラ自体にタダ乗りして商売してるからなあ。
広告見ない人はブロックする程度の入り口は商売する側で用意すべきでしょ。
Facebookみたいな形が理想だけどAdblockもAdblockblockもそういう意味では良い文化。
嫌なら見せるな (スコア:0)
コンテンツをロードしなきゃ、要らない広告があるかすらわからないわけだが。
誰でも読めるようにアップロードしといて「読むな」ってどれだけマヌケよ。
ところで、Do Not Track設定てのが用意されて久しいんだけど、尊重してくれるサイトってどれだけあるんだ？
Re: (スコア:0)
> 本来、広告見ないやつにはコンテンツを利用する権利も無いわけだが。
広告分の通信料を広告屋が負担してくれるならそうかもしれないが、タダ乗りは広告屋側。
リンク先に遷移すると数秒固まる (スコア:0)
SSDに切り替えても再インストールしても駄目で
広告ブロックのアドオン停止したらサクサクになった。
流石に広告ブロックは外せないのでそのまま不便に使っているけど
もし改善するなら絶対して欲しい。
Re: (スコア:0)
Chromeの新API、初版のAPIだと広告ブロッカーの実用上の問題点があってRaymond Hillがコメントしたりして炎上っぽくなったんだけど、
初版の時にGoogle側が言っていた利点の一つが現行APIだとブラウザ側で待ちが入ってしまう所があって、それが無くなるってのがあったはず。
それでAPIを改版して問題点のほうは解消しているんだと思うんだが、UX的にサクサクがどうかは、
今のままに戻ってるかもしれない。知らんけど。
googleルール (スコア:0)
将来は、googleの広告ガイドラインに沿った広告に関しては、
chromeプラグインやら、google playアプリでブロック禁止とかになるんじゃないでしょうか？
もちろん、google自体がやる広告に関しては、ガイドラインに沿ってるとして
ブロック禁止になる