#3: WebBundleは、コンテンツブロック、セキュリティツール、開かれたウェブに有害（ウェブ標準特集 第２弾）

要旨

Googleが新しいウェブ標準、WebBundleを提案しています。WebBundleは、ウェブサイトのリソースを「バンドル（統合）」すると同時に、ブラウザからURLを通してサブリソースを判定することを不可能にします。これによりウェブは、ハイパーリンクによるリソースの集合体（監査、選択的取得、置換が可能なもの）から、個別要素を判定できないオール・オア・ナッシングの「BLOB」（PDFやSWFのようなもの）の集合へと移行しかねません。ユーザー中心のオープンで透明性が高いウェブ世界を信じる組織、ユーザー、リサーチャー、規制当局は、この標準に反対すべきです。

WebBundleなどの提案を通して問題解決 ¹ を目指すこと自体は評価しますが、他の方法で、ユーザー中心のオープンで透明性が高いウェブ世界の本質を維持したまま同じ効果を得ることができると考えています。例えば、個別のサブリソースのに署名するといった方法もあるでしょう。こうした代替案については、仕様作成を進めているものもあり、今後、機会があれば改めてご紹介させていただきます。

URLがウェブのオープンな一意性を担保しています

ウェブの価値とは、ユーザー中心であり、ユーザーによる管理や編集が可能であることです。少し専門知識をもつユーザーであれば、ページ内のウェブリソースを見て、ブラウザにそのページを読み込ませるかどうかを決めることができます。また一般のユーザーは拡張機能やプライバシー保護ツールをインストールすることでこの仕組みを利用することができます。

ウェブのユーザー中心という性質は、一般的なアプリケーションや情報配信システムと大きく異なります。一般のアプリケーションではコードとリソースがコンパイルされていて、それぞれを区別して判定することはほぼ不可能です。これは重大な違いです。ウェブではプライバシー保護ツールが多数あるにもかかわらず、「バイナリ」のアプリケーションシステム用にはほとんどないのはこの違いが一因です。

ウェブをオープンでユーザー中心なものにしている基本はURL です。URL は（一般的に）一つのものを指し示しているので ² 、リサーチャーや活動家はこうしたURL を事前に測定し、分析し、判定することができます。他のユーザーはこの情報に基づいて、そのURLにあるリソースを読み込むべきか、またはどのように読み込むべきかを決めることが可能です。さらに重要なのは、専門家が https://tracker.com/code.js を読みこみ、それがプライバシーを侵害していると判断した場合、その情報を他のユーザーと共有することで、将来的にそのコードを読み込まないようにすることができるということです。

WebBundleはURLを無意味なものにします

Googleは最近、WebBundle、Signed HTTP Exchanges（SXG）、Loadingという3つの関連するウェブ標準を提案しています。特に断りのない限り、本記事ではこの３つの規格をあわせて「WebBundle」と呼ぶことにします。これまでのところ、WebBundleは、Googleが提案している広告システム（TURTLEDOVEやSPARROWなど）で使用したり、GoogleのAMP（Accelerated Mobile Pages）システムのフォローアップとして使用することが想定されたものですが、これは氷山の一角に過ぎないと考えています。

概念的に言うと、WebBundleはリソースをまとめる機能です。ブラウザは、ウェブサイト、画像、JavaScriptファイルを個別にダウンロードする代わりに、1つの「バンドル」されたファイルをダウンロードします。そのファイルにはページ全体の読み込みに必要な情報が全て含まれています。そして、URLはもはやウェブリソースの共通グローバル参照ではなく、バンドルファイルへの任意のインデックスとなります。

つまり、WebBundleによってウェブサイトはPDF（または Flash SWF）のような動きをするものになります。PDFには、PDFをレンダリングするために必要な画像、動画、スクリプトがすべて含まれており、各アイテムを個別にダウンロードする必要はありません。これには利点もありますが、PDF 内の画像を PDF 自体から切りはなして判定することはほぼ不可能です。これが、PDFに対するコンテンツブロック・ツールが存在しない理由の一つです。PDFは事実上、オール・オア・ナッシングであり、WebBundleによってウェブサイトも同じ形になるのです。

WebBundleはURLを意味のあるグローバル参照からパッケージに紐づいた任意のインデックスに変えてしまいます。広告主やトラッカーにとっては、プライバシー保護やセキュリティ保護のウェブツールを回避する新たな手段を手に入れることを意味します。次のセクションでは、その理由を例をあげて説明いたします。

WebBundleによってウェブサイトはプライバシーやセキュリティのツールを回避可能

WebBundleのURLは、バンドル内のリソースへの任意参照 ³ であり、グローバル参照ではありません。これにより、サイトがプライバシーやセキュリティのツールを回避することが複数の手段で可能となります。

こうした回避が可能になる共通した根本要因は、WebBundleがリソースに対してローカルの名前空間を生成し外部の認識と切り離してしまうことです。これによって、さまざまな名前の混乱が起き、長年をかけてプライバシーやセキュリティ保護の改善にむけてリサーチャーや活動家が実施してきた成果を台無しにします。以下、WebBundlesを利用したウェブサイトが名前の混乱を悪用する可能性について、３つだけですがご紹介します。

URLをランダム化してプライバシーツールを回避

今までは、もしサイトに（例えば）フィンガープリント・スクリプトが含まれる場合、サイトで使用するフィンガープリント・スクリプトを指し示す<script>タグが1つ含まれていました。そのサイトでは、全ページが同じURLの単一のフィンガープリント・スクリプトを参照します。リサーチャーやクラウドソーサーは、そのフィンガープリント・スクリプトのURLをEasyPrivacyといったリストに記録することで、プライバシーを重視するユーザーがフィンガープリント・スクリプトを取得せずにサイトを閲覧できるようにしてきました。これが、現在のウェブのブロッキングツールやプライバシーツールが機能する一般的な仕組みです。

WebBundleによって、プライバシーツールがブロックするリソースのURLもランダム化するため、容易にブロックを回避できます。たとえば、現在のウェブ上ではexample.org/tracker.jsと共通して参照されていたものが、あるWebBundleでは1.js、次のWebBundleでは2.js、3番目のWebBundleでは3.jsなどと参照されるようになります。WebBunldeのこの仕組みはウェブサイトの負担が減るため有利です。例えば、サイト運営者はキャッシュに煩わされなくなり（リソースは全ユーザーに送信しバンドルをキャッシュしているため）、URLマップを保持する必要もありません（ユーザーに送信したバンドル内にランダム化されたURLが保持されているため）。

URLの再利用によるプライバシーツールの回避

さらに悪いことに、WebBundleではバンドルごとに同じURLで違うリソースを示す事が可能になることから、ブロッキングツールを回避できるようになりす。現在のウェブでは、https://example.org/ad.jpgは誰からも同じものを指しています。同じURLから2つの違う画像を返すことは困難です ⁴ 。よって、ブロッキングツールがad.jpgをブロックした場合、誰に対しても間違いなく広告がブロックされています。ad.jpgが一部のユーザーにとっては広告だったが、他のユーザーにとっては会社のロゴであった、というリスクはほぼありません。

WebBundleはこの状況を変えてしまいます。 Example.orgは、WebBundleを使うことで、あるバンドル内ではhttps://example.org/ad.jpgは広告を参照し、別のバンドルではサイトロゴを参照し、3番目のバンドルでは何か他のものを参照するようにすることが可能です。 これではブロックリストを構築することはほぼ不可能です。サイトは、ブロックリストを無効にする強力な新しい機能を手に入れたことになります。

危険なURLを隠し、プライバシーツールを回避する

最後に、WebBundleはさらに危険な回避を可能にします。uBlock OriginやGoogleのSafe Browsingプロジェクトでは、現在有害で危険なリソースのURLリストを構築しています。この2つのプロジェクトにおいて、それぞれのリソースが有害かどうかを判断する唯一もしくは重要な判定基準はURLです。URLが普遍的でグローバルであることが、こうしたリストの有効性を担保しています。

WebBundleを使うと、こうした保護機能を回避することが可能になります。既知の有害でないURLを使って既知の有害なリソースを参照することが可能なためです。たとえば広いウェブの世界で、https://cdn.example.org/cryptominer.js を、あたかもhttps://cdn.example.org/jquery.jsであるかのように（あるいは逆もしかり）、サイトに認識させることは非常に難しいことですが、WebBundle を使えば極めて簡単になるでしょう。

WebBundleは、プライバシー侵害を容易にする

WebBundleの設計者や支持者は、上記で述べたプライバシー保護を回避する手法には、目新しいものはなく今でも可能だと主張しています。この主張は、技術的には確かに正しいですが、経済性を考慮していないので見落とがあります。現在は、コストがかかり安定性がなく適用困難だった回避技術が、WebBundleを使うと低コストで容易なものになるのです。

例えば、ブロッキングツールを回避するために、多数のURLをつかって同じファイルを参照させることが今でも可能なのは事実です。しかし、実際に運用するのは困難です。理由は、URLをランダム化するとキャッシュに悪影響があること、ランダム化したURLからオリジナルの値へのマップをどこかに永続的に保存しなければいけないこと、そしてそれをコンテンツデリバリーネットワーク（CDN）上に配信する必要があること、などです。実施することは不可能ではありませんが、適用困難でコストがかかるため一般的ではありません。

同様に、今でもクッキーなどのトラッキングを使用し、一つのURLでユーザーごとに違うものを指すことで、先述したURL再利用による攻撃を行うことができます。しかし、これもまた堅牢性はなく（新規訪問者に対してどうするか）、困難で（クッキーとリソースのマップを維持・配信する必要があります）、高コストです（ほとんどのウェブサーバやホスティングサーバは、スケールするためにキャッシュを積極的に使っているため、こうした回避テクニックは巨大企業並みに大規模なサイトを運営していない限り不可能です）。

つまり、WebBundleによって、悪意のある行為が低コストで極めて容易に実現することができるようになるのです。

その他の懸念事項

本記事では、WebBundleの問題のうちプライバシーやセキュリティツールに関するものをご紹介しました。しかしWebBundle や関連するウェブ標準については、他にも懸念事項があります。今後、そうした懸念に関する記事を投稿する可能性はありますが、ここでその一部についてご紹介します。

• SXGに否認手段がないこと： 今は、サイトが誤ってマルウェアなどを含んでいた場合、サイトを更新するだけで問題を解決することができます。サイトが SXG で WebBundle に署名された場合、署名者が 「この特定のバンドルはもはや信用できない」ということを示す明確な手段がありません。
• Manifest v3 との組み合わせ: Manifest v3によると、拡張機能による広告ブロックにはURLパターンしか使用できません。一方WebBundleはURLを意味がないものにします。この2つが組み合わされば、ブロッキングを完全に回避されることになります。
• オリジンの混乱： LoadingとSXGの適用により、あるサーバーからコンテンツを取得し、別のサーバーのプライバシーやセキュリティのプロパティを使って実行することが可能になります。これによりユーザーに混乱がおこる可能性はきわめて大きくなります。Google社員がUI/UXの問題を解決すべく懸命に努力していることは間違いないですが、今のところユーザーへのリスクは非常に大きく、リスク軽減する方法はありません。

結論

Braveは、ウェブ上のプライバシーを向上させるために、ウェブブラウザを構築し、ツールを作成・共有し、標準化団体でアドボカシーを行っています。そして、ウェブ標準がプライバシー、透明性、ユーザー中心であり続けることを担保すべく活動しています。この投稿で共有した懸念事項は、こうした活動から生まれた一例にすぎません。

Braveはこうした懸念事項に対応すべく、WebBundleの設計者と長い時間をかけて話し合ってきましたが、うまくいきませんでした。Braveは、Google と WebBundleの開発グループに対し、この投稿で指摘したプライバシーとセキュリティの問題が解決されるまで、開発を一時中断することを強く求めます。また、ウェブのプライバシーとセキュリティのコミュニティのメンバーには、こうした議論を理解していただき、問題が解決されるまでは仕様を実装しないようお願いしたいと思います。

議論にご参加いただくには、WebBundleの懸念事項を話し合っているこちらの課題（Issues）にコメントください（本記事の執筆者と同一人物が書いたものです）。また、仕様に関する新しい課題（Issues）を登録することも可能です。もしくは、ご自身にとってプライバシーツールの重要性を明らかにし、WebBundleがプライバシーツールにもたらすリスクをウェブブラウザのプロバイダーに伝えるという方法もあります。