GoogleはすでにWEIをChromiumに導入している

(github.com/chromium)

1 ポイント投稿者 GN⁺ 2023-07-27 | 1件のコメント | WhatsAppで共有

Chromiumのコミット 6f47a22 は、Web Environment Integrity を Origin Trial で有効化した際に Web API 全体へアクセスできるよう、feature 構造を調整した
核心となる変更は、base::Feature を content_features.h から runtime_enabled_features.json5 ベースの生成 featureへ移し、機能フラグと Web API の公開制御を分離した点にある
Web API は引き続き RuntimeFeature が制御し、デフォルト無効のままだが、Origin Trial がこれを有効にすると API へアクセス可能になる
Finch で base::Feature を無効化すると、機能全体のkill-switchとなり、Origin Trial が機能を有効化することも防げる
変更は 15 ファイルにわたり、173 行追加・18 行削除で構成され、WebView には既知の origin からレスポンスをスプーフィングできる点を活用したテストが追加された

Origin Trial で WEI API アクセスを開く構造変更

コミットタイトルは [wei] Ensure Origin Trial enables full feature で、対象は Chromium リポジトリのコミット 6f47a22
変更の中心は、Web Environment Integrity を Origin Trial で有効化したときに API 全体へアクセス可能にすることにある
base::Feature の配置が content_features.h から runtime_enabled_features.json5 で生成される feature に移動した
この構造では base::Feature はデフォルトで有効化できる一方、Web API の公開は RuntimeFeature が担い、初期状態では無効のままとなる

Origin Trial、RuntimeFeature、kill-switch の関係

Origin Trial は RuntimeFeature を有効化して API アクセスを開ける
API 全体へアクセス可能にするには RuntimeFeature だけでなく base::Feature も有効である必要があり、関連条件は origin_trial_context.cc の変更に反映されている
base::Feature が Finch によって無効化されると、機能全体のkill-switchとして動作する
- この場合、Origin Trial が機能を有効にすることもブロックされる

WebView テストで確認された動作

WebView テストは、既知の origin からレスポンスを容易にスプーフィングできる点を活用して追加された
AwWebEnvironmentIntegrityTest.java には次の動作を確認するテストが含まれる
- デフォルト状態では navigator に getEnvironmentIntegrity が存在しない
- BlinkFeatures.WEB_ENVIRONMENT_INTEGRITY を有効にすると API を利用できる
- 該当 feature を無効化すると API は再び利用できなくなる
- Origin Trial ヘッダーとトークンを使って getEnvironmentIntegrity('contentBinding') 呼び出しと encode() の結果を検証する
テストでは https://example.com/ origin、Origin-Trial ヘッダー、Origin Trial トークン、TOKEN_BASE64 値 AQIDBA== などが使われている

コードパスと feature 参照の移動

複数箇所の既存 features::kWebEnvironmentIntegrity 参照は blink::features::kWebEnvironmentIntegrity に変更された
変更された主要ファイルは次の通り
Android WebView の production flag 一覧も ContentFeatures.WEB_ENVIRONMENT_INTEGRITY から BlinkFeatures.WEB_ENVIRONMENT_INTEGRITY に変更された

変更規模とコミット情報

コミットでは 15 ファイルが変更され、変更量は 173 行追加と18 行削除だった
関連バグ項目は 1439945、b/278701736
レビュー対象リンクは chromium-review.googlesource.com/c/chromium/src/+/4681552
コミット位置は refs/heads/main@{#1173344} と表示されている

1件のコメント

GN⁺ 2023-07-27

Hacker News の意見

状況を把握するための入門資料としては、Vivaldi のまとめがよかった
https://vivaldi.com/blog/googles-new-dangerous-web-environme...
- 興味があったので Vivaldi を試してみたが、10分でそのプライバシー主張を信じにくくなった
  OS の既定ブラウザは Firefox に設定されていて、ほかのアプリはすべてそれに従うのに、インストール中にプライバシーポリシーのようなリンクを開く際には Microsoft Edge を使っていた。しかもコンテナ化機能がまったくなく、あるタブの Google Cookie が別のタブで読まれるのを防ぐには、新しいプライベートウィンドウを使う必要がある。アンインストールした直後、削除理由を尋ねるページも Edge で開いた
Mozilla は今回の Web Environment Integrity 実装を理由に、Google を W3C から追放するよう求めるべきだ
「Chrome のシェアは65%なのに、Google のいない W3C に何の意味があるのか」という声は出るだろうが、Google がウェブの基本原則を一方的に変えられるなら、W3C はすでに役に立っていない。Google が W3C は重要だという体裁を保ちたいなら、この実装を撤回すべきだ
わずか3日で、ウェブの潜在的な未来がここまで危険なものになったとは信じがたい。すでに Private Access Tokens という、問題はより少ないが、それでも悪い提案が標準化委員会で進んでいるのに、Google はそれを無視した。個人の GitHub アカウントで非常に怪しげに提案を出し、外部からのコントリビューションとコメントを即座に閉じ、反発があるにもかかわらず Chromium に完全な実装を押し込んでいる
必要なのは実際の行動であり、Mozilla は常に自らをウェブの理念を守る「真の」中立的な守護者として位置づけてきた。今こそ証明する時だ。単に反対の立場を表明するだけでは不十分だ。これは、ウェブをあらゆる閉鎖型エコシステムと区別してきた根本を狙った攻撃である。誰かが W3C に「既存のブラウザだけがウェブページのレンダリングを許可されるべきだ」という提案を出したなら、正しい対応は「その提案に反対する」ことではなく、提出者にその組織へ参加する資格があるのかを真剣に問うことだ。今起きているのはまさにそれだ
- ウェブ標準化の一般的なやり方は、新機能の支持者がまず実装してデプロイし、実際に動作することが証明されてから標準化団体に仕様を持ち込むものだと広く受け入れられている
  通常はうまく機能するが、標準化前の実装が成功しすぎると、後から承認された標準に従う実装へ変更するのが難しくなる場合がある。標準化の過程では大きな変更がよく起きるからだ
  例として CSS グリッドレイアウト がある。Microsoft が IE 10 に -ms- ベンダープレフィックス付きで追加し、ほぼ誰もが気に入ったため標準化されたが、Microsoft の元の実装とは差が大きく、CSS から -ms- だけを取り除けば標準の CSS グリッドがうまく動くというわけではなかった
  Microsoft が IE 10 に最初に配布してから、ほかのブラウザで既定で有効になるまで4.5年かかった。Chrome は1年以内に、Firefox はそれより2年ほど後に実験的機能として入れたが、ユーザーが自分で有効にする必要があった。その4.5年の間に、IE だけを気にするサイトが -ms- 形式を十分多く使ってしまったため、Microsoft は IE 10 と 11 で標準ではなくその形式に縛られることになった
- すでに遅すぎる。W3C は事実上無関係になっており、そもそも大きく重要だったこともあまりない
  インターネットは標準化団体ではなく大企業が作っている。実際に生きている標準は WHATWG にあり、実際のソフトウェアは Google、Apple、Cloudflare、Amazon が作っている。W3C を気にしている人はいないし、Mozilla はとっくに力を失っている
- Apple が Safari で似たようなことをした時も何も起きず、みんな静かで、HN ではその機能が有効になったApple Safari 独占を積極的に擁護していた。なのに今だけ違う理由があるのか
- Mozilla がここで実際に意味のあることをする可能性はない。オープンなウェブを支持する声明を出して美徳シグナリングくらいはするだろうが、それ以上ではないはずだ
- 正直、W3C は WHATWG が XHTML 標準を押しのけて HTML5 委員会に置き換えた時点で、すでに発言権を失っていた
  当時は「ウェブは XHTML2 だ。望むなら自分たちだけのインターネットを作ればいい」と言えるだけの重みがあったが、今は交渉力がはるかに弱い
  その時に責任を大手インターネット企業へ移した判断は、ある程度合理的だったのかもしれないが、結局は今のように事実上、初期の Microsoft Network へ逆戻りする状態を作った原因だ
  [1]http://www.codersnotes.com/notes/the-microsoft-network/
コメントで不満を言うだけでなく、今日中に反トラスト当局へ連絡すべき
US: https://www.ftc.gov/enforcement/report-antitrust-violation / antitrust@ftc.gov
EU: https://competition-policy.ec.europa.eu/antitrust/contact_en / comp-greffe-antitrust@ec.europa.eu
UK: https://www.gov.uk/guidance/tell-the-cma-about-a-competition... / general.enquiries@cma.gov.uk
India: https://www.cci.gov.in/antitrust/ / https://www.cci.gov.in/filing/atd
- antitrust@ftc.gov にさっきメールを送った。メールを書くところで詰まる人には、Bing Chat がかなり良い下書きを作ってくれて、少し手直しするだけで済んだ
  1. Edge で https://vivaldi.com/blog/googles-new-dangerous-web-environme... ページを開く
  2. 右上の Bing Chat サイドバーを開くと、記事を自動で要約してくれる
  3. プロンプトは「このWebページの要約を使って、Alphabet の反トラスト法違反を通報する手紙を書いて。次の内容を含めて」とし、会社は Alphabet、競争を害した理由は記事の内容を使用、自分の立場は Firefox ブラウザのユーザーだと入れた
- FTC にさっきメールを送った。かなりすっきりしたし、これで残りの一日中この件で怒らずに済みそうだ。他の人にもやってみることを勧める
- Canada: https://www.competitionbureau.gc.ca/eic/site/cb-bc.nsf/frm-e...
- EU の反トラスト関連の連絡先としては https://competition-policy.ec.europa.eu/antitrust/procedures... のほうが良さそう
  ここでは新しい反トラスト苦情を具体的に作成できる
- 楽観論は尊敬するが、他はともかく UK の機関が指一本でも動かしたら驚くと思う。あまりに役に立たない
この提案はあまりにも徹底してユーザー敵対的なので、技術的根拠で批判するのも難しい
悪い提案というより、危険で邪悪で悪意ある提案なので、細部を批判しても徒労だ。全体が問題であり、廃棄されるべき
静かな抗議では今回は通用しない。目標は、政府と規制当局の関心を引くほど大きな問題にし、反トラスト手続きを開始させることだ
Google は検閲や「礼儀を守れ」という通知を持って消えてくれて構わない。いよいよ本性を現したし、行動規範は良い慣行や歓迎される環境を強化するものではなく、反対意見を抑え込む道具になった
Firefox に乗り換えたし、他の人にもそうすることを勧める
- Google 側の「立場」、動機や技術的理由が気になるなら、説明文書はここにある
  https://github.com/RupertBenWiser/Web-Environment-Integrity/...
  露骨にユーザー敵対的だ。「ユーザーエージェント」の関係を反転させ、エージェントが画面の向こうの人間を監視する広告主・企業・政府のために働くようにしようとしている。導入部が、これをユーザーが必要としている、あるいは望んでいるかのように装っているやり方は胸くそが悪い
  正直に書き直すならこうだ。Google のような企業は、広告主がユーザーについて可能な限り多くを知れる必要がある。収益は、クライアント環境のフィンガープリント採取、行動と履歴の追跡、キーボードの向こうに十分な可処分所得を持つ人間がいることの証明に依存できる。このような個人情報の採掘は Google のビジネスモデルの根幹であり、Web 支配力と莫大な利益率を維持するために不可欠だ
- 完全に同意。FTC に送る手紙を書こうと座ったが、この仕様を読んだ後では、反対理由をまともな文章にできなかった。反応はただ「これはいったい何なんだ」に集約される
  過去に Chromium チームのメンバーたちと働いたことがあり、概して有能で善意があると思っていたが、この仕様提案からは善意も能力も見えない。Google が従来のようにゆっくりすべてを取り込んでいく流れを超えて、はるかに直接的で権威主義的な方向へ振る舞いを変えたように感じる
- 提案だけでなく、Google 自体も問題だ。Google は必ず分割されるべき
- WEI をよく知らない立場として、これが何をするもので、なぜ悪いのか要約してもらえるか
- この機能が Google ユーザーに対してどう敵対的なのか
  Web サイトがアプリの代わりに Web 上でより多くのことをできるようにする実質的な利点もある。CAPTCHA が減り、ソーシャルメディアのボットも減るかもしれない
  大多数が使っているプラットフォームは利益を得るだろうし、Apple ユーザーはすでにそうした恩恵を受けているように見える
  オープンソース環境が悪化するという主張は理解する。だが google.com は引き続き動作するはずだ。ユーザー体験を悪くするのは他の Web サイトのほうだ
この問題に反対する理由は多いが、検索エンジンへの影響はあまり取り上げられていない
Webサイトがこれを実装すると、新規参入者がWeb検索エンジンを作ることは事実上不可能になる。既存事業者は自社クライアントを許可リストに入れるか証明し、他のスクレイピングクライアントはすべてボットに分類できる
他に理由がなくても、検索企業であるGoogleが、ブラウザのような別領域での市場支配力を使って競争を潰せるものを推し進めることが、どうして許されるのか分からない
- 反トラスト法はしばらく死んでいたからだ。Chromeは人々をGoogleとGoogle広告へ送るための道具にすぎない
  IEとEdge時代のMicrosoftのブラウザエンジンは、IEが悪名高いほど苦痛な存在だったとしても、この分野に競争をもたらしていたという点ではありがたかった。だが今ではChrome（Blink）、Firefox（Gecko）、Safari（WebKit）だけで、Chromeが支配的なシェアを得た後に何をしたかはかなり明らかだ
  Webをより安全な場所にしていると心から信じているGooglerもいるだろうが、一歩引いて見ると本当の理由はかなり明確に見える
- この点は考えが及ばなかった。間接的にでも、これをフェアユースの制限を根拠に拒否する手続きはあるのだろうか
- このAPIを5%程度は失敗するように実装して、Webサイトが証明の失敗だけを理由に個人をブロックできないようにするやり方は可能だろうか
  https://github.com/RupertBenWiser/Web-Environment-Integrity/...
- 既存事業者が自社クライアントを許可リストに入れ、他のスクレイパーをボットに分類することは、すでに普通のクライアント証明書でもできるのではないか
  あるいは共有秘密鍵でURLのHMACを含むリクエストヘッダーを送るだけでもよい
  もっと根本的には、自分が所有するコンテンツをなぜわざわざスクレイピングする必要があるのか。GoogleがYouTubeの結果を検索結果ページに入れるときに使うように、任意のバックチャネルを作ってデータへアクセスすればよい。有用にスクレイピング可能なWebサイトを提供する必要はまったくない
- Seleniumのような方法で承認済みのブラウザインスタンスを起動するスクレイパーには、これはどう機能するのだろうか
The Registerによる、また別の穏健な記事
https://www.theregister.com/2023/07/25/google_web_environmen...
仕様がまだ半煮えの状態にもかかわらず、先週の反発は素早く、WEIのGitHubリポジトリにはおおむね批判的なコメントが殺到し、提案の作成者に向けられた罵倒もあった。Googleの開発者たちは、以前にそのリポジトリへ貢献したことのある人だけがコメントできるよう制限し、礼儀を守るよう促す通知として行動規範の文書を掲げた
最近、反対意見に対応するよくあるやり方だ
- リアクションボタン、つまり親指やハートなどもロックされた点も重要だ。後で「特定のトピックXについて懸念を示した人は少数にすぎなかった」と言うためのもっともらしい否認可能性を与えるからだ。記者たちはこの点をもっと知るべきだ
  それとは別に、仕様の著者と直接連絡を取りたい記者や人々は、彼の公開Webサイトを見ればよい。仕様が載ったGitHubプロフィールの他のリポジトリの一つにあり、個人メールアドレスもある。彼が2022年に以下の文章を書いていたというのは、痛々しいほど不条理だ
  「結局、これをアプリにすることにした。ここから費用がかかり始めた。iOSアプリをビルドするために中古のMacBook Proを買わなければならなかった。Appleの戦略は明白で、実際にうまく機能しているが、LinuxノートPCだけではアプリを作れないというのは今でも非常に腹立たしい。アプリを1か月以上維持し、友人たちが簡単にインストールできるようにするには、開発者アカウントに99ドルを払わなければならなかった。Apple、人々にApp Storeを使わせたいのは分かるが、これは少し残酷だ。自分の小さなアプリを使い続けるために、今や事実上毎年99ドルを払わなければならない。」
  [0] https://benwiser.com/blog/I-just-spent-%C2%A3700-to-have-my-...
- 「私たちが、あなた方の知っていたWebを破壊している間は、礼儀を守ってください。念のため耳栓もしています」
- 「私たちがあなたの腹に突き刺しているナイフに抗議したいなら、どうぞ。ただし資格証明と礼儀が必要です」
- 投稿を制限し、礼儀を求めることは、個人がたとえ何千人を相手にしても意味のあるコミュニケーションを取るための唯一の方法だ
  人間の精神は、生涯の心拍数よりも多くの異なる声が存在する、インターネット規模の社会的インターネットには適応していない
小さいけれど実際にできる行動はある。自分のWebサイトに、控えめに Firefox の利用を推奨するメッセージを入れることだ。
必ずしも目立たせる必要はなく、小さな文言でいい。Firefoxでも、ほかの非Chromium系ブラウザでも勧めればいい。
私も自分のWebサイトに追加した: https://geeklaunch.io/
Chromium系ブラウザでだけ表示されるようにした。少しずつ流れを変えられる。
- こういうものを入れたい人向けの文言例は次のとおり。
  このWebサイトは、プライバシーを尊重するWebブラウザである Firefox 向けに設計されています。
  .hidden クラスは要素を何らかの方法で隠せばよく、ここでは .hidden { display: none; } のように処理している。
- アイデアは気に入ったが、Mozillaがこの件についてどんな立場を表明しているのか気になる。
  Firefoxユーザーではあるものの、かなり前からMozillaに対して良い印象ばかりを持っているわけではない。こうして宣伝する前に、Mozillaがこの問題で正しい側に立っていることを知りたい。
- この助言は 1998年っぽさが強い。
- ほとんどの人はChromeとFirefoxの違いを知らないし、変更後も使っていたWebサイトをそのまま使えるなら気にしないと思う。
  違いを説明しても、99%は翌日には忘れているだろう。
  結局、意味がない。こうした過剰な権限の乱用には、政府の介入と規制だけが助けになり得る。Googleは財布で対抗できる相手ではなく、大きすぎる。
- Chromium系ブラウザでだけ出ると言っていたが、どう検出しているのかは分からないものの、Orionでもこの案内が表示される。OrionはWebKitベースで、Safariでは表示されない。
  ユーザーエージェントを明示的にFirefoxやSafariに変えても、表示され続ける。
この一連の出来事にも、ひとつ明るい面があると感じる。行動規範、企業による検閲、広告、魔女狩り、さまざまな制限によって World Wide Web がますます浄化・殺菌されていくほど、価値があり面白い部分は代替空間へ流れていってほしい。
かつてのインターネットは、ギーク、変わり者、アウトサイダー、反社会的傾向のある人たちが集まる場所だった。あらゆることが許され、あらゆることが可能だった。私を含む多くの人は、それが世界を変えることを望んでいたが、そうはならなかった。誰の目にも明らかなように、世界がまた勝ちつつある。それでも、Webの正常化が、企業向けの安全地帯以上の何かを求める人々の臨界量を生み出してくれることを願っている。
視覚的ノイズや「動的」機能を取り払った Geminiのようなプロトコルが十分なユーザーを得る未来を、心から望んでいる。そうでなくても、主流のソーシャルメディア、GoogleやMicrosoftのサービス、LLMやその他の現代的でディストピア的なものを使っていない立場からすれば、失うものは多くない。百回の人生を満たせるほど素晴らしい本があり、歩く山道も、一緒に酒を飲む友人も十分にいる。もしかすると、そのほうがいいのかもしれない。
- 昔の多彩なインターネットは、銀行業務を銀行の支店で済ませていた時代と共存していた。
  今では銀行業務はおおむねオンラインへ移り、銀行は物理店舗を多く廃止した。多くの国での行政サービスへのアクセスも同様だ。ここで心配すべきなのは、ギークやアウトサイダーのための小さな趣味のインターネットが生き残ったとしても、対応ブラウザなしでは重要な日常業務ができなくなることだ。
Wikimedia Foundationを巻き込み、Wikipediaやその他の大規模なMediaWikiホストが、ブラウザでこの機能が検出された場合には一切のコンテンツを表示しないようにすべきだ。
また、ディストリビューションのメンテナーなら、Apacheとnginxのデフォルトをそう設定すべきだ。
さらに、政治的・技術的な理由を長々と説明する壁にリダイレクトするのではなく、このモジュールのせいでブラウザがサポートされていないという大きな ERRORメッセージと、可能なら about:config で無効化するための短い案内だけを表示するほうがよいと思う。
- WEIを理解しないサーバーが正しく動作できなくなるというのでない限り、Apacheとnginxのデフォルト設定をそう変えることには賛成しない。少なくとも見たところ、そういうケースではない。
  システム管理者が設定を変えることはできるだろうが、ここで話しているのはデフォルト値だ。
  ただし、それ以外の提案は良さそうに見える。ディストリビューションのメンテナーは、クライアントのデフォルト設定でWEIをオフにしたり、WEIが入ったクライアントプログラムを含めないようにしたりもできる。
「don’t be evil」からここまで180度転換した姿を見ると、がっかりする。
友人や家族全員にMozilla Firefoxを勧めている。
- 私もそうしていて、疲れる会話を続けているが、非専門家に要点を伝えるのは本当に難しい。
  技術分野の友人の中にも、Firefoxで本当に動かないものがあるときだけChromeに戻ればいいのに、楽だからという理由でChromeを使い続けている人が多い。技術に詳しくない人たちをどう説得すればいいのか。
- 妻をようやくFirefoxに戻すことができた。MacでChromeがただ固まってページを開けなくなり、それ以外はすべて正常に動作していた。
  今は機能が制限されていない uBlock Origin と一緒に、Firefoxを快適に使っている。
- 残念ながら、Firefoxは結局UI/UXが良いとは言いにくい。
  最後に確認したとき、マルチプロファイル対応もどこか中途半端な状態だった。

GoogleはすでにWEIをChromiumに導入している

Origin Trial で WEI API アクセスを開く構造変更

Origin Trial、RuntimeFeature、kill-switch の関係

WebView テストで確認された動作

コードパスと feature 参照の移動

変更規模とコミット情報

関連記事

1件のコメント

Hacker News の意見