来年初めに実験的な Android WebView Media Integrity API
(android-developers.googleblog.com)- アプリに埋め込まれたメディア提供者が再生環境を検証できるようにする Android WebView Media Integrity API が、来年初めに一部のメディア提供者と実験的にパイロット運用される
- 証明サービス には Play Integrity API や Firebase App Check がすでにあるが、その情報を埋め込みコンテンツ提供者に渡す方法は単純ではなく、拡張性も低い
- Chrome チームは Web Environment Integrity 提案をこれ以上検討しておらず、新しい API は Android アプリ内の WebView と、ストリーミング動画・音声のような埋め込みメディアに範囲が限定される
- WebView の柔軟性はアプリ統合には有用だが、アプリ開発者が Web コンテンツやユーザー操作にアクセスしたり変更したりできるため、不正や悪用 の可能性も生じる
- 整合性レスポンスにはデバイス・アプリの判定のみが含まれ、ユーザー・デバイス識別子は含まれず、アプリは必要に応じて パッケージ名 を判定から除外できる
埋め込みメディア検証のための新しい WebView API
- Android WebView は、Android 開発者がアプリ内にメディアを埋め込めるようにする 強力で柔軟な API である
- 埋め込みメディア提供者は、自身のメディアが 信頼できる安全な環境 で再生されているかを確認する必要がある
- Android アプリ開発者と SDK 提供者はすでに、ユーザーのプライバシーを保ちながらアプリのサーバーリクエストを検証する証明サービスを利用できる
- 現在でもアプリ開発者は、こうした証明サービスの情報を埋め込みコンテンツ提供者に渡せるが、この手順は 単純ではなく拡張性もない
- この制約を減らすため、来年初めに一部の埋め込みメディア提供者と 実験的な Android WebView Media Integrity API のパイロットが実施される
Web Environment Integrity とは異なる限定的な範囲
- Chrome チームは Web Environment Integrity proposal をこれ以上検討していない
- Android WebView Media Integrity API は、それよりも 狭い範囲 だけを対象とする
- アプリに埋め込まれた Android WebView のみを対象とする
- Google Mobile Services(GMS) を搭載した Android デバイスの既存機能を拡張する
- ストリーミング動画や音声のような 埋め込みメディア の外に提供する予定はない
- Android WebView の外に提供する予定もない
WebView の柔軟性と悪用の可能性
- Android WebView API は、アプリ開発者が Web ページを表示しメディアを埋め込めるようにし、UI 制御と高度な設定オプションによってアプリとシームレスに統合される
- この柔軟性は、アプリが独自の Web コンテンツを埋め込む際には有用だが、アプリ開発者が Web コンテンツやユーザー操作にアクセスしたり、それを横取りして変更したりすることもできる
- その結果、コンテンツ改変 や出所の誤認といったリスクが生じうる
整合性レスポンスとプライバシー保護の条件
- 新しい API は、埋め込みメディア提供者向けにカスタムの 整合性レスポンス を提供する
- レスポンスにはデバイス整合性判定とアプリ整合性判定が含まれる
- 埋め込みアプリがどのアプリストアからインストールされたかに関係なく、ストリームが安全で信頼できる環境で実行されているかを確認できる
- 判定はアプリとデバイスに関する単純で低エントロピーなメタデータである
- ユーザー識別子やデバイス識別子は含まれない
- Play Integrity API を使うアプリ・ゲームとは異なり、メディア提供者はアプリの Play ライセンス状態を取得しない
- アプリは必要に応じて自分のパッケージ名を判定から除外できる
- Android チームは、Android アプリの多様なメディアコンテンツのエコシステムを維持することを目標としており、来年初めの早期アクセスプログラムへの参加に関心のあるメディアコンテンツ提供者から 参加意思の提出 を受け付けている
1件のコメント
Hacker Newsの意見
WEI 自体はすでに複数のスレッドで扱われており、読む価値のある議論が多い
（2023年7月、コメント456件） https://news.ycombinator.com/item?id=36854114 - "Google's nightmare Web Integrity API wants a DRM gatekeeper for the web"
（2023年7月、コメント431件） https://news.ycombinator.com/item?id=36817305 - "Web Environment Integrity API Proposal"
（2023年7月、コメント434件） https://news.ycombinator.com/item?id=36875940 - "Unpacking Google’s Web Environment Integrity specification"
（2023年7月、コメント111件） https://news.ycombinator.com/item?id=36857676 - "So, you don't like a web platform proposal" - 提案に人々がどう対応すべきだったかについてのGoogle社員の視点
（2023年8月、コメント100件） https://news.ycombinator.com/item?id=36960882 - "Web Environment Integrity: Locking Down the Web"
技術者たちは善意の論拠を持ち出したが、相手は悪意あるイメージ戦で、それにやられてしまった形だ
Google が Web Integrity API を進めないことにしたという知らせは、オープンウェブの中立性にとって非常に前向きだ
ただし Google はウェブ全体の利益よりも自社の利害で大きく動いてきたので、何で置き換えてくるのか見守る必要があり、しかもそれほど時間はかからない気がする
FLoC や Topics のときのように、見た目はやや穏当でも、実際にはユーザーに同じくらい有害な仕様を用意しているのではないかと疑っているし、広告課金をクリック単位からインプレッション単位に変えるという最近の発表と時期が重なっているのも怪しい
Google はウェブの信頼できる管理者には見えなかったし、今回の apparent victory に安住してはいけない
今後も単一の主体がウェブの未来を支配しようとする試みを防ぐには、ブラウザとブラウザエンジンの多様性 が重要だ
世界中の広告主にデータを供給する グローバルなデータブローカー を、ウェブ技術の正当で善意ある管理者と見なすのはやめるべきだ
まずサーバーとクライアントの関心の分離に反している
クライアントはユーザーエージェントであり、つまりユーザーが望むことをする存在であって、サーバーが望むことをする存在ではない
この基本的な誤解と視点の歪みが問題の一部だ
HTTP(S) と関連技術を誰にとっても自由で開かれたプロトコルとして保つには、Google を意思決定プロセスから外すべきだ
Encrypted Media Extensions、Manifest v3、そして今度は WEI まで、Google が背後にいた
ウェブは Google のものではないし、Google は QUIC でもやって HTTP には手を出さないでほしい
「Android WebView Media Integrity API はスコープが狭い」と言われるが、ユーザーにとっての利点が見えない
WebView を埋め込みたいアプリであれば、ネイティブコードで既存の Android Integrity API を使う API をその WebView に接続すればいいのではないかと思う
私には、たとえば広告なしで YouTube を再生する「改造」アプリを防ぐための迂回路のように見え、この API はユーザーの利益にならない
これは WebView ベースのアプリでそれをやりやすくするだけだ
差し込まれたクライアントを使う 中間者攻撃 は Apple と Google の囲いの外では現実的な脅威で、囲いの中でも多少は存在する
WEI は実際の問題を解こうとする試みだった
もちろん副作用は受け入れがたいものだったかもしれないし、利益より害のほうが大きかったのかもしれず、今では死んだ提案だ
ただ、ここでは誇張された論争の中で根本問題が完全に埋もれ、人々は隠れた意図や全般的な悪意を次々に投げつけた
私たちのコミュニティにとって最良の瞬間ではなかった
そうしたコメントのかなりの部分が、非標準クライアントに客観的により不寛容な Appleデバイス から書かれていたというのも皮肉だ
これがどう動くのか理解できない
「新しい Android WebView Media Integrity API は、埋め込まれたメディア提供者がデバイスおよびアプリの完全性判定を含むカスタム完全性レスポンスにアクセスできるようにし、埋め込みアプリがどのアプリストアからインストールされたかにかかわらず、ストリームが安全で信頼された環境で実行されていることを確認できるようにする」という内容だ
だが、これは Google Chrome のような独立したブラウザーではなく、Android WebView API にしか適用されない
それとも元の Web Environment Integrity 提案に戻るということなのか
とはいえ、誰も WebView API を必ず使わなければならないわけではないし、Chromium はオープンソースだ
悪意あるAndroid開発者の Bob が Chromium を自分でコンパイルしてアプリに同梱し、その邪悪な心の赴くままにあらゆるウェブサイト向けの悪さをするのを、何が止められるのか分からない
言い換えれば、これが特殊な WebView API にしか入らないのなら、悪意ある開発者は単にその API を避ければいいのではないかと思う
ステップ2: 代替手段を禁止する
ステップ3: 収益化する
タイトルが誤解を招く
Chrome に適用される提案は廃案になったが、実質的に Chrome を包んだラッパーである Android WebView API 向けとしては引き続き進められている
ときどき怪しいサードパーティー製アプリの埋め込みログインに使われるためだ
これを合理的だと見る観点があるのは分かる
個人的には、独立ブラウザーの一部でない限り、埋め込み WebView に一般的なブラウジング機能を許可すべきではないと思う
たいていは、本来オープンな Web に出ていくはずのトラフィックを横取りするためのごまかしとして使われる
WEI 公開討論スレッドに 公式確認 が投稿された: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...
次の波が来るまで、オープンなインターネット のために押し返し続けなければならない
消耗する話だ
大企業だから、人々が疲れるまでただ待つことができる
リポジトリはアーカイブされており、“NOTE: This proposal is no longer pursued.” と書かれている
https://github.com/RupertBenWiser/Web-Environment-Integrity
すでに、より分かりにくい解決策の作業を始めている可能性が高い
Google がたまにやるようにアイデアの方向性そのものを諦めるのではなく、論争の少ない別のインフラに概念実証を展開しておき、タイミングが良くなったらまた持ち出す証拠があるかどうかを、記事を読みながら探していた
例えば大きな サイバーセキュリティ事故 の後を狙うこともあり得るので、覚えておく価値がある
実際まさにそうしていて、Android チーム側へ戻したうえで、論争の少ない小さなサンドボックスで改善すると約束しただけだ
公には Web 向けの取り組みを “ひとまず” 引っ込めるとしか言っていない
かつて知っていた、オープンなインターネットの擁護者だった Google に戻って、やることなすことの MBA化 から引いてほしい
“don’t be evil” を捨てた時点から、そちらへ向かったように感じるし、本当にうんざりする
勝利を祝う代わりに、オープンなインターネット側の人々は、より小さなプロジェクトの実施と Web プラットフォーム版の一時停止だけを祝うことになってしまった
大きく影響力のある主体が、結局はどこかの収益のために方向を操るようになる
そろそろ Web のハードフォーク が必要なのではないかと思い始めている
すでに Web には、JavaScript が重くサイトがアプリ化した Web と、文書とリンク中心の Web という 2 つの「圏域」がある
前者は後者の上位集合だと主張できるかもしれないが、その陣営からユーザーに反する試みが次々に出てきて、オープンなプラットフォームとは正反対の最終目標を持っているのだとすれば、主要な主体が分かれる以外にどんな現実的な選択肢があるのか分からない
Google にはこれを実際に押し通す力があった
元のタイトルは “Increasing trust for embedded media” である
「誤解を招いたり釣りでない限り元のタイトルを使い、編集しないこと」というガイドラインがある
https://news.ycombinator.com/newsguidelines.html