Mozillaの標準ポジション、Web Environment Integrity APIに反対
(github.com/mozilla)- Mozilla の standards-positions イシューで Web Environment Integrity API に対する立場が求められ、Mozilla はこの提案がウェブのオープン性の原則と衝突するとして
position: negativeと整理した - この提案は Chromium のプロトタイプが現在 Google Play Integrity に依存しているものの、仕様上はベンダー中立だとされており、依頼者は EME のように実際には少数ベンダー中心に固定化される可能性を懸念した
- Mozilla はこの API がデバイス、OS、ブラウザーの選択を制限する仕組みになり得るため、ウェブ生態系のオープン性 に有害で、ユーザーにとっても望ましくないと判断した
- 提案されたユースケースのうち「非人間トラフィックの検出」は、支援技術、自動テスト、アーカイブ、検索エンジンスパイダーのように、人間向けコンテンツを変換・検証・索引・要約する既存のウェブ利用を妨げる可能性がある
- Mozilla は不正行為と無効トラフィックの検出が難しい問題であり、その解決に関心があるとしつつも、この提案は実際のユースケースの進展についての説明が不足しており、採用時に明確な欠点があるとみている
イシューの要請と提案範囲
- GitHub イシューは Mozilla に Web Environment Integrity API という新興ウェブ仕様に対する公式見解を求めた
- 要請に含まれていた資料:
- Chromium のプロトタイプは現在 Google Play Integrity に依存しているが、依頼者は仕様自体は ベンダー中立 だと記している
提起された初期の懸念
- 依頼者は、EME は理論上ベンダー中立だが、実際に広く認められているベンダーは少数である点を例として挙げた
- Google Widevine: ほとんどのプラットフォームの Firefox、Chrome、Android で使用
- Microsoft PlayReady: Microsoft Edge、Windows、一部の Android デバイスで Widevine と併用
- Apple FairPlay: Safari と Apple エコシステムで使用
- 同じ状況が Web Environment Integrity API にも起こり得て、実際のウェブサイトが 事前承認されたブラウザー を要求するようになる可能性があると懸念した
- あるコメントでは、この API はエンドユーザーに提供するものがなく、ユーザーを制限するためにしか使われ得ないうえ、仕様が曖昧で underlying mechanism も不明確だと批判した
Mozilla の反対理由
- Mozilla はこの提案が Mozilla の ウェブ原則とビジョン に反すると述べた
- Mozilla のウェブビジョンでは、共通標準を実装するブラウザー、サーバー、パブリッシャーは自動的にウェブの一部となるべきだとしている
- 標準は配備可能なハードウェアやソフトウェアに関する前提を避けるべきであり、特定の主体がどのフォームファクター、デバイス、OS、ブラウザーがウェブにアクセスできるかを決めるべきではない
- こうした選択の自由は、支援技術、ローカライゼーション、フォームファクター、価格の面で多様な人々が同じウェブに到達できるようにする
- したがって、選択を制限しようとする仕組みは ウェブ生態系のオープン性 に有害であり、ユーザーにとって望ましくない
「非人間トラフィックの検出」ユースケースの問題
- Mozilla は、提案されたユースケースが「detect non-human traffic」の能力に依存しているとみている
- この方式は既存のウェブ利用を妨げる可能性がある
-
支援技術
- 自動テスト
- アーカイブ
- 検索エンジンスパイダー
- これらのツールは、人間向けのコンテンツを受け取り、再び人間のために変換、テスト、索引、要約できなければならない
- 提案書の保護策である「holdback」または attestation の生成をランダムに失敗させる方式は、効果的である可能性が低く、Mozilla が提起した懸念を解消するには不十分だと判断されている
-
結論とイシュー処理
- Mozilla は、不正行為と無効トラフィックの検出は難しい問題であり、この問題の解決に関心があると述べた
- ただし Web Environment Integrity API の提案は、列挙されたユースケースにおいて 実質的な進展 をどのようにもたらすのか説明できておらず、採用時には明確な欠点がある
- Mozilla メンバーはこの分析に基づき、この提案に対する立場を negative とラベル付けした
- この提案は個人 GitHub リポジトリ上の提案であり、標準トラック作業や公開インキュベーショングループの作業ではないため、別個の dashboard entry は不要と判断された
- イシューは 2023 年 7 月 25 日に
position: negativeラベルが付けられた後、完了状態でクローズされた
1件のコメント
Hacker News の意見
攻撃の手口はおおよそこうだ。攻撃者がスマートフォンのようなデバイスを作り、鍵ペアを生成してデバイス内の HSM、通常 trusted enclave と呼ばれる場所に保存したうえで、公開鍵にマスターキーで署名する。
デバイスは攻撃者のソフトウェアを実行し、ユーザーが選んだソフトウェアが高い権限で実行されると、HSM が再起動前までは取り消せない形でその事実を知るように設計される。HSM は「このデバイスは攻撃者のソフトウェアを実行中である」という文と、攻撃者のソフトウェアが伝えようとする内容に署名するが、ユーザーが選んだソフトウェアが実行中であれば署名しない。そこにマスターキーで署名された公開鍵まで含めることで、共謀者が、そのデバイスがユーザーの管理下ではなく ユーザーの自由を制限する主体 の管理下にあることを確認できるようにする。
任意で、この証明は攻撃者のサーバーを経由して、匿名化や任意の条件チェックを受けた新しい証明に置き換えられることもある。結局、第三者はこの方式によって、デバイスが攻撃者のソフトウェアを実行中であることを保証され、ユーザーが望むソフトウェアを実行できないようにしたり、攻撃者と共謀者が望む方法でデバイスを使わせたりできる。この攻撃はすでに Android では Google の SafetyNet と Play Integrity API によって、iOS では Apple によって実行されており、今度はウェブへ拡張されようとしているわけだ。
この Web Integrity API は、自分たちを選択可能な中間者ではなく 必須の中間者 として固定する手段だ。
そしてこの「攻撃者」が得るものもない。これは攻撃者ではなく デバイスメーカー だ。TPM を攻撃者と呼んでリモートアテステーションの過程を説明しているようなもので、違和感がある。
だからこうした制度は一般ユーザーにコストを押し付けつつ、そうした能力を持つ側にだけ利益を与える。
予想どおりのことだが、人々を Firefox に向かわせ、Chromium 系から離れさせられなければ意味がない。ウェブの安全性とセキュリティ、広くは 信頼 に投資してきた人たちには、ある程度の責任がある。
Brave がこれをサポートするかについてはまだ見ていない。ただ、自分の理解が正しければ Chromium を使う以上は選択肢がなさそうで、自分が間違っていることを願っている。
結局、IE の抱き合わせ販売問題の後のように、法律で裏付けられた ブラウザー選択画面 へ恒久的に戻るべきだと思う。そうでなければ、摩擦とインセンティブが支配的なプレイヤーをさらに固め続けるだろう。
より重要なのは自由と相互運用性だ。
おまけに uBlock Origin も事前に入れておけばいい。私たちはそうしている。
これが実装されると、ユーザーの身元が「不十分」と判断され、特定のウェブサイトやサービスにアクセスできなくなる可能性があり、そうなればこの機能のない別のブラウザーへ移る動機になるかもしれない。
ほかでも言ったが、人々は Firefox を使うべきだ。みんながやめてしまえば、Google のたわごとに対抗する声を持つ主体がいなくなる。Google は Chrome を所有していて、望むようにできる。
Firefox が完璧だとか、より優れているという話ではなく、必要だという話だ。Google が最終的に支配していないレンダリングエンジンを持つ、意味のあるシェアの競合ブラウザーが必要だ。そうでなければ、不満を言うのをやめて、Google の望むようにさせるしかない。
ざっと調べたところ、5〜10年前には収益の50%以上が Google から来ていたが、より最近の資料は見つけられなかった。Google が Mozilla の主要な収益源、特に過半を占めているなら、Google は Mozilla の最大の収益源を断てるというレバレッジによって、実質的に Mozilla を支配している。
さらに、どの会社や組織がブラウザーを開発すべきなのかという問いも生じる。誰もがブラウザーを無料だと期待しているが、開発・運用・保守は無料ではない。Brave のような営利ブラウザー企業は、BAT 暗号トークンや新規タブ広告のような形でブラウザーを収益化せざるを得ない。
Mozillaも、インターネット全体でユーザーを追跡する独自の IPA提案について立場を明らかにしてもらえるだろうか？
searchengine.exampleで商品の広告を見て、後でreviews.exampleでその商品を調べ、その後shop.exampleで購入すると、Mozillaブラウザーがこれらすべてのイベントを1つ以上の集計サービスに送り、shop.exampleがユーザーがsearchengine.exampleで広告に接触し、reviews.exampleでも再び接触したことを、少なくとも集計レベルで理解できるようにする。もちろん、集計サービスを運営するカルテルを信頼するという前提が付く。
以前は広告技術企業が、Cookieを無効にしても送信元IPアドレスをもとにユーザーを追跡できたが、IPAは固有の追跡識別子によって複数のIPアドレスをまたぎ、Cookie設定に関係なく追跡できるようにする。OSが、端末内のすべてのアプリとブラウザーで使える固有の追跡識別子を提供する案も提案されており、同じIPの背後にある複数の端末も区別可能になる。
https://github.com/patcg-individual-drafts/ipa/
これは、ユーザーの関心プロファイルを構築する広告トラッキングや、過去の訪問者を対象に広告を買うリマーケティングとは別の話だ。ほとんどのプライベートなアトリビューションシステムは、広告運用者が何人が広告をクリックしたかは数えられるが、誰がクリックしたのか、ほかに何をしたのかは分からないように設計されている。Safariの提案には、ドメインごとに実行可能なキャンペーン数の制限があり、ユーザーごとに別の「キャンペーン」を作って一度にフィンガープリント追跡することを防ごうとしていた。Mozillaの提案がどう違うのかは分からない。
ユーザーエージェントがこうしたことを気にすべきかどうかは別の問題だ。
https://www.theregister.com/2023/06/29/google_trueview_skepticism/
特にリマーケティングは、何かを1つ検索すると翌週ずっとその商品の広告1万件が追いかけてくるという、現代の広告における「監視されている感じ」を生む原因だ。
MozillaがIPAのようなゴミに合わせているのは残念だが、少なくとも現時点ではユーザーには無効化・削除・フォークなどを行う自由がある。一方でリモート証明は、ユーザーエージェントという概念そのものにとって、事実上ゲームオーバーだ。
ブラウザー検出、「環境」検出
特定のウェブサイト運営者が抗議手段として、Chromeからアクセスできないウェブサイトを設計することもできる。Googleがそれを回避しようとする様子を見るのは面白そうだ。特に、小規模で非商業的なウェブサイトの間だけで流行るならなおさらだ。
ただし完全に遮断するのではなく、必要最小限の機能だけを残し、別のブラウザーに切り替えるかTampermonkeyのようなものを使うよう繰り返し案内するつもりだ。何をすべきかについての明確な案内も併せて提供する必要がある。
こうした機能の対応有無を検出する良い方法は何だろう？ JavaScript API？
幸いGoogleも約4か月前に修正した。複数の無料クロスブラウザーテストツールでは、いまでもバージョンテストでその壊れ方を示せる。
モバイル側の対応物である Play Integrity API は違法化し、法廷で争うべきだ。サードパーティROMを排除することが中核的なアイデアなので、EUの修理する権利や電子廃棄物関連法にも反する可能性が高いと思う。
議論の焦点を、Googleとその広告が生み出したセキュリティ問題へと移し始めるべきだ。
Googleの利害関係がAndroidとChromeを汚染できないよう、Googleを分割すべきだ。
Mozillaに寄付したいが、自分のお金がCレベル幹部の懐に入るのではないかと心配。FirefoxコアチームやMDNに限定して寄付する方法はあるのか？
途方もなく過剰な報酬を受け取るCEOでさえ、会社には必要だ。米国で優秀なCEOを連れてくるには高額を払わなければならないという理屈は信じていないが、悪いCEOはGE、Enron、Boeing、Twitterのように会社を壊し得る
予算用途の制限がどう失敗するかの面白い例として、AtlantaのMARTAがある。以前、資金に関する法律で運営費と資本支出を50/50に固定したところ、新しい列車はあるのに、それ以外は崩壊していった
事業とは、お金が入り、お金が出ていき、製品が作られる仕組みだ。好きな製品にお金を払うか払わないかを選べばいい。受け取ったお金をどう使うかは彼ら次第だ
ただし、お金は代替可能だ。MDN支援用に500ドルを寄付すると、もともとの収益からMDNに回っていた500ドルを置き換え、別の500ドルがCレベルの懐やPocketなどに回る可能性がある。ドルそのものは指定した先に行くが、気に入らない別の支出を可能にしてしまうことがある
逆に、MDN支援用に500億ドルを寄付するなら少し事情は違う。既存のMDN支援予算は確実に浮くだろうが、MDNの支出が500億ドルであるはずはないので、MDNの必要分を超えたお金は行き場がない
製品を使って顧客になるほうが、彼らや彼らのマニフェストにとって、より価値がある可能性が高い
Mozillaが反対することはできるが、Chromeに搭載されて活発に使われ始めれば、結局はCDMのように実装することになるだろう
結局ユーザーは、あるWebサイトがChromeでは動くのにFirefoxでは動かない、としか見ない。潜在的なシェア喪失という実際のコストが生じれば、Firefoxは反対する理由がないと判断するだろう
WebKitの標準に対する立場も見る価値がある: https://webkit.org/standards-positions/
この件はまだ反映されておらず、おそらく反対する可能性が高い
古典的な意味でのハッカーたちが、コンピュータを使って他の人々が望まないことをしてきた長い歴史があり、その相手方は何もできないか、せいぜい軍拡競争を繰り広げるしかなかった。彼らにとっては悪いことだったが、社会全体にとっては非常によいことだった
それがGNU、「IBM Compatible」、広告ブロッカー、Firefox、BitTorrent、YouTube ReVanced/youtube-dlなど、数多くのものを生み出した
コンシューマー向けソフトウェアにおけるデバイス証明の目的は、これを終わらせることだ。AppleがiOSで最初に切り開き、今や資本主義の力によってあらゆるコンピューティングへ広がりつつある。デバイス証明はハッカーが敗北することを意味し、悪い結末だ
もう一つの双子の脅威は、ソフトウェア産業がセキュリティをきちんと整理しつつあることだ。以前はiOSの脱獄が一般的だったが、1年間iOSの脱獄はなかった。Rustも助けにはならない
私たちは、制作者と知的財産権の保有者が、自分たちの作ったコンテンツを完全に支配し、最先端の暗号技術と、極めて安全だが消費者に敵対的なソフトウェアによってその状態を維持する世界へ突き進んでいる。これは歴史上もっとも危険な展開の一つであり、現実になれば元には戻せない。Stallmanは正しかった
銃口を突きつけられて財布を差し出せば幸福度が改善される、と言うのに似ている