AppleはすでにWebデバイスのアテステーションを展開しており、私たちはほとんど気づかなかった
(httptoolkit.com)- GoogleのWeb Environment Integrity提案が物議を醸す一方で、AppleはすでにmacOS 13、iOS 16、Safariに、同様のWebデバイス証明システムであるPrivate Access Tokensを展開していた
- Private Access Tokensは、サーバーがHTTP 401と
PrivateTokenチャレンジを送ると、ブラウザとOSがデバイスの状態についてattesterの確認を受け、署名済みトークン付きで再度リクエストする仕組みである - CloudflareとFastlyはCAPTCHAを減らすためにこれを統合したが、同じ構造はWebサーバーがユーザーのデバイスに正当なクライアントであることの証明を求める基盤にもなる
- Safariのシェアは約20%のため影響は限定的だが、Chromium系は70%以上であり、Googleの提案まで加わればWebクライアントの約90%がアテステーション対象になり得る
- アテステーションは新しいブラウザ・OS・オープンソース・ユーザーが改変したデバイスを排除し得るうえ、公式サポート期間や広告ブロック拡張の有無といった条件でルールが強化される危険がある
Apple Private Access Tokensの展開と目的
- Googleの執筆者たちが開発し、Chromiumでプロトタイプ化されていると見られるWeb Environment Integrity提案をめぐって懸念が高まっている
- この提案はWebにおけるattestationに相当し、クライアントが信頼された発行者に承認されているかどうかによって、機能やサイト全体へのアクセスが制限され得る
- 実際の信頼発行者はApple、Microsoft、Googleになる可能性が高い
- Appleはすでに1年前に、非常によく似たシステムであるPrivate Access Tokensを開発・展開しており、現在はmacOS 13、iOS 16、Safariに統合されている
- AppleはPrivate Access Tokensを「身元を明かさずに、HTTPリクエストが正当なデバイスから来たことを証明する強力なツール」と紹介している
- この機能の主な目的はCAPTCHAの排除であり、CloudflareとFastlyが実際のクライアントを認識する仕組みとして統合している
Private Access Tokensの動作方式
- Private Access TokensはHTTP上で行われる比較的単純なやり取りであり、組み込みのブラウザAPIが処理し、OSコンポーネントと連携してブラウザとOSが正当であるかを確認する
- ここでいう「正当」の基準は、attester、つまりAppleのような主体が決定する
- 基本的な流れは次のとおり
- ブラウザがWebサーバーにHTTPリクエストを送る
- Webサーバーがリクエストを拒否し、HTTP 401レスポンスと
PrivateTokenチャレンジを返す - ブラウザがチャレンジの一部と、OSが提供した検証済みデバイス情報をattesterに送る
- attesterがデバイスが本物で改変されていないことを確認した後、originが信頼し、かつattesterを信頼するトークン発行者とともに署名済みトークンを返す
- ブラウザが
Authorizationヘッダーに署名済みトークンを入れて、再度リクエストを送る - サーバーは、クライアントが信頼プロバイダーによって検証されたという事実に基づいて、そのクライアントを異なる扱いにできる
- この過程は、Safariを使うAppleデバイスで、FastlyやCloudflareのようにこの機能を使うサービスがリクエストの正当性を疑ったときに、すでに発生している
- Private Access Tokensはorigin、issuer、attesterの流れを分離してプライバシー保護を目指しているが、Web上で受ける扱いがAppleがデバイス・OS・ブラウザ構成を許容可能と判断するかどうかに依存する
SafariとChromiumの拡散力の違い
- Private Access TokensだけでもWebと業界全体にとって負担だが、Safariのシェアのため、Google提案ほど急速に広がるのは難しい
- Safariのブラウザシェアは現在約20%である
- モバイルでは約25%
- デスクトップでは約15%
- Chromeは全領域で60%を超えており、Brave、Edge、Opera、Samsung Internetなどを含むChromium全体ではそれより約10ポイント高い
- Safariだけがこの機能を提供する状況では、一部の提供者が利用することはあっても、アテステーションのないクライアントをブロックしたり異なる扱いをしたりするのは難しい
- Safariが古いOSバージョンやブラウザをアテステーションしなくても、ユーザーへの影響は大きくなりにくく、統計的にはより多くのCAPTCHAを見る可能性がある
- Chromiumを使うWebクライアントが70%以上ある状況でWeb Environment Integrityが導入されれば、Webの主要部分へ急速に広がり得る
- Web Environment IntegrityとPrivate Access Tokensが併存すれば、Webクライアントの約90%が潜在的にアテステーション対象となり、「アテステーションがないなら怪しい扱いにしよう」という圧力が強まる可能性がある
アテステーションがWebの開放性を揺るがす仕組み
- アテステーションは承認済みクライアントだけを使えるようにするため、競争とイノベーションに不利である
- 新しいブラウザやOSを作りにくくなる
- オープンソース、コミュニティ、小規模なインディーの試みは、こうした仕組みから継続的に排除され得る
- IE6時代にアテステーションがあれば、FirefoxやChromeの台頭に大きな障害になっていただろうという比較もある
- この構造は設計上、ユーザーが自分のデバイスをコントロールしにくくする
- 改変されたソフトウェアを使うユーザーを正当なクライアントとしてアテステーションしないことは、中心的な目的の1つである
- root化したAndroidスマートフォンでWebを閲覧するユースケースが排除される可能性がある
- 完全にユーザーが改変可能なOSやハードウェアは、こうした提案が意図する方式ではアテステーションされにくい
- 承認プロバイダーは後からルールをさらに厳しくすることができる
- 「公式サポート2年以内のデバイスのみをアテステーションする」
- 「広告ブロック拡張がインストールされたブラウザはアテステーションしない」
- Web Environment Integrityの支持者は、一部のリクエストでアテステーションを拒否するholdbacksによって、アテステーションベースのブロックを防げると見ている
- しかし、ビジネス上の圧力のためにholdbacksが実際には機能しにくいのではないかという懸念があり、Google既存のAndroid Play Integrityアテステーションはこの方式を使っていない
- Webの成功は、多様なクライアントとサーバーを自由に使えたことに大きく依存しており、アテステーションはこの前提を設計上壊してしまう
Androidですでに現れているリスク
- Androidでは技術的には独自OSを作って実行でき、LineageOSのようなAndroidディストリビューションも正常に機能する
- しかし、アテステーション機能のために、銀行アプリのような重要アプリがユーザーを疑わしいものとして見なし、ブロックするリスクが常に残っている
- Androidバージョン間の競争を妨げることも問題だが、WebでブラウザとOSの両方の競争を妨げることは、はるかに深刻な結果をもたらし得る
- Anti-Fraud Community Groupでは、同系統の潜在的なWeb機能を議論する他の提案もある
- Web上の詐欺やボットは現実の問題であり、防御方法を議論する価値はあるが、競争の阻害、オープンソースとオープンWebの弱体化、ユーザーのデバイス統制権の剥奪は、妥当なトレードオフではない
1件のコメント
Hacker News のコメント
昨日の Google の初期提案には、「会社分割がかなり現実味を帯びてきた」「失せろ Google」「怒りと悲しみを感じる」「関係者の評判は完全に終わった」といった反応が多かった。
今日は、Apple が昨年同じ機能を提案していただけでなく、実際に実装して配布していたことが明らかになったが、「とうの昔に消えた夢をもう一度始める興味深い機会かもしれない」「双方の立場はある程度理解できる」「とりあえず Safari で有効にしたまま1〜2年様子を見る」といったトーンになっている。
全体としては依然として否定的だが、Apple と Google に対するトーンの違いがあまりにもはっきりしていて、現実歪曲フィールドはいまだ健在に見える。
そのうちの1人は Hacker News にも直接投稿しており、だから嫌っている人たちは、十分に嫌がらせすれば当事者たちが諦めるだろうと見て、嫌がらせを助長することになる。
Apple はそういうことに時間を使わず、検討し、計画し、実行する。関係者の正体は分からず、たいていフィードバックも求めず、計画の正当化すらあまり示さない。Web フォーラムで Apple に怒るのは、レンガの壁に怒るのと同じくらい無意味だ。
顔のない企業というクリシェがあるのは伊達ではなく、従業員を守るための意図的なポリシーなのだ。
ところが Apple では逆だ。サードパーティアプリをインストールする自由は危険だと言い、ブラウザで iMessage を使う自由はあり得ないと言い、iOS でサードパーティブラウザを使う自由には大半が関心なさそうに見える。
他社のロックイン効果は悪いが、Apple のロックイン効果はユーザー層が積極的に布教する、という点が印象的だ。
Apple の方式は、Apple デバイス上で人間のユーザーと非人間ユーザーを区別する手段に近く、Google の提案のように、サービスが任意にブラウザや OS をブロックできるようにするものではない。
すでに Apple デバイスを使っているなら、「人間かどうか確認する」CAPTCHA をしなくて済む、という程度だ。
参考: https://developer.apple.com/wwdc22/10077
一方で Google は、少数の声の大きい Google 嫌いが評判を削り続けるのを放置しながら、物語をコントロールするための広報をほとんどしていない。
いまだに「don’t be evil」の一度きりの反響が20年後にも鳴り続けると信じているようだ。
Microsoft が Windows に IE を組み込んだときはひどいことだったが、Apple が Safari を組み込み、競合ブラウザを妨げるのは顧客にとって最善、という扱いになる。
インターネットが本当に分岐する地点かもしれない。90年代からずっと予見されていたことだ。
一方には、全員が過剰に身元確認される「クリーン」な権威承認済みの企業 Webがあり、もう一方にはポルノと分散型コミュニティが集まる、より緩いグレイネットの銀河が生まれる可能性が高い。
すべてのいじり屋たちが企業ネットワークから押し出されるなら、とうの昔に消えた夢をもう一度始める興味深い機会になるかもしれない。
インターネットの上に「社会」を表す泡のような社会的上部構造ができた、と想像してきた。90年代から小さなバージョンはあったが、Myspace、Facebook、Twitter のようなソーシャルメディアの台頭で本格化した。
「キャンセルカルチャー」がほどなく現れたのも偶然ではないと思う。仮想化された公共圏が生まれると、今度は誰が、何が、その中に属するのかを決める問題になるからだ。
「ついに、みんなが長い間からかってきた自分の技術を試せるぞ」という態度だ。
どちらの場合も、新しい秩序の下で苦しむ大多数の人々を無視しているという問題がある。企業の塀に囲まれた庭から抜け出して、自由な情報ハイウェイへ向かう人はごくわずかだろう。
企業 Web のかすかな反響だけがグレイネットを通じて保存され、デジタル考古学者たちが企業 Web に隠された失われた知恵の「秘密」を掘り起こそうと奮闘する物語だ。
すでに誰かが書いていそうだが、よく合っているように思う。
パブリッククラウドと私的利用が交わる家庭環境、たとえば個人用途で使う Cloudflare Access トンネルや MS365 ビジネステナントにも、ある程度は欲しい。
だが、個人の Web ブラウジング体験や個人用ブラウザ環境には絶対に触れてほしくない。
現時点では、これらの欲求は事実上互いに衝突しており、すでに猫は袋から出てしまった技術だ。
90年代のサイバーパンクの夢は格好いいが、「ネット」に接続するには常にインターネットプロバイダーというボトルネックを通らなければならない、という物理的現実を無視しているように見える。
結局、インターネットがどれほど反体制的であり得るかには、解消不可能な障壁がある。
間違っているかもしれないが、Web Attestation は、Android や Chrome OS ではない Linux デバイスがウェブを対等なクライアントとして使うことへの死亡宣告になり得る
Linux はリモート証明が安定して動作するには多様すぎ、ハック可能性も高すぎるプラットフォームなので、最終的には完全に排除されるだろう
いくつかの「祝福された」ディストリビューションだけが例外になるだろうが、そうしたディストリビューションは業界に統制されるようになり、もはや Linux の精神からは遠く離れてしまうだろう
ほぼすべてのウェブサイトのスパム対策分類器に引っかかり、保護された場所にアクセスするには CAPTCHA を3〜5回解かなければならない
Wikipedia も編集をブロックする: https://meta.wikimedia.org/wiki/Talk:Apple_iCloud_Private_Re...
そういうサイトを断つ意志力が自分にはなさそうなので、向こう側でコンテンツの読み込みを止めてくれることが、むしろ必要なのかもしれない
ここで言ってしまったので、もう秘密ではない
https://github.com/jwise/28c3-doctorow/blob/master/transcrip...
それらも、特定のハードウェアを持っていることを証明しなければならない未来には不十分に見えるほど、多様でハック可能なプラットフォームだ
「祝福された」いくつかのディストリビューションが業界の統制下に置かれ、Linux の精神が失われるという話はよく聞くが、具体的にどうそうなるのかはあまり聞かない
業界が統制した UNIX があったから Linux が生まれたのであり、Linux からその精神を奪えば、別のコミュニティプロジェクトにフォークされるだろう
GPL ライセンスを剥がさない限り、Linux は完全に使われなくなるまで「Linux の精神」を保ち続けるだろう
Safari は支配的なブラウザではないので Google の提案ほど危険ではない、という主張には同意しない
実際には Apple がやっても Google がやっても同じくらい悪く、Apple は完全に失望させる選択をした
Google が押し通そうとしても、Apple が拒否していれば実質的に強制するのは難しかっただろう。数字は Chrome ほど高くなくても、すべての iDevice を切り捨てられない程度には十分大きい
本当に重要な会社は Apple、Google、Microsoft の3社だけだ
今回はまた一つの災厄を防いでくれなかったのが残念だ
だから Apple にサイドローディング開放を求める法律も心配している。人々が自分のシステムをコントロールするという考えは好きだが、実際には Google がクライアント末端までウェブを完全に支配することを固める最後の釘になるのではないかと恐れている
彼らが実装した機能が複数のブラウザと互換性がないと指摘するたびに、決まって Firefox から Chrome に乗り換えろと言われる
何かを動かすために Safari に乗り換えろと言われたことは一度もない。それ自体が多くを物語っている
iOS ではこの機能をオフにできるようだ
設定に行き、一番上のユーザーアカウントを選び、「Password & Security」に入り、Advanced まで下へスクロールして「Automatic Verification」をオフにすればよい
https://blog.cloudflare.com/how-to-enable-private-access-tok...
https://support.apple.com/en-us/HT213449
System Settings -> iCloud Settings（ユーザー名）-> Password & Security -> Automatic Verification
Chrome が WEI を配布すれば、複数の Chromium フォークも、Chrome がそうしなくてもオフにできるようにするだろうし、Firefox を使うこともできる
問題は、銀行、税務機関、お気に入りのストリーミングサービスがこの機能を要求し始めたときだ
核心は、一般ユーザーのかなりの数がこの機能を持つこと自体にある
これには実際に気づいていて、ブログに書こうかとも考えたが、問題に見えなかった唯一の理由は、Apple プラットフォームにしか実装されておらず、サービスがこれでユーザーを実際に制限する方法がなかったからだと思う
単に、人々が別のシグナルの一つとして使える追加要素だった
一方で Google の提案は、これを明示的に 常時オンの機能として押し進めることに関心がある
「決定的なプラットフォーム完全性証明」のようなユースケースが現在はクライアントのフィンガープリンティングに依存しているという説明は、結局のところ、制限されたエントロピーの決定的証明が侵襲的なフィンガープリンティングを置き換え、長期的にはよりプライバシーに配慮した慣行を開き得る、という主張だ
Apple が先に実装したという事実が証明しているのは、Apple が私たちを救ってくれると期待する人がナイーブだということだけだ
この領域は本当に興味深く、意見が大きく分かれるだけのものがある
Web上で「信頼できる」ハードウェアとソフトウェアのスタックと通信しているのかを知りたいユースケースは非常に多い
何年もの間、スタックにはほとんど信頼がないという前提で設計・構築してきたが、それは複雑さとコストを大幅に増やし、機能を制限し、信頼できるスタックを前提にできる場合よりもあらゆることをはるかに難しくしている
同時に、いま大きく指摘されているように、大手テック企業の独占が絡むと、信頼という概念は非常に難しくなる
一方では、持続的な脅威アクターに対処できる大規模な技術チームを運用できる企業は世界に数えるほどしかないため、彼らが提示するセキュリティ上の約束を信頼できるなら望ましい、という面もある。その約束が信頼に値するなら、個人が自分のソフトウェアやプラットフォームについてできるどんな約束よりも優れている
他方で、ハッカーというプラトン的な意味から見れば、「信頼済み」とはすなわち「独占企業が保証している」「おそらく現地の政府機関のバックドアがある」と読め、統制とイノベーション不足、そして最後には少数のプレイヤーが支配するファシズム的な技術の未来へ、さらに一歩下ることになる
結局、成功し得る解決策には、登録簿ベースではなく、信頼できるオープンなハードウェア認証技術が含まれていなければならないと思う。強力なローカル証明を作り、独立して検証できる必要がある
シリコンの側でこの問題に取り組む技術企業をいくつか知っているが、非常に難しい問題であり、いま彼らが生き残れるほどの需要があるのかも定かではない
個人的には、ひとまずSafariでこれを有効にしたまま、今後1〜2年を見守るつもりだ
DRM技術もこうした用語で議論されるが、目的はユーザーに信頼を与えることではなく、開発者やコンテンツ所有者に信頼を与えることだ
これが本当に信頼に関する問題ではないかもしれないことは、はっきり見て取れる
国家システムの利益を享受するのか、そのコストを負う価値があるのかを選ばなければならない
こうしたシステムの大半の問題は、例外状況をまったく扱えないことだ
人口の99%にはうまく機能するが、残りの1%は自力でどうにかなれ、という形になる
退勤後にオフィスへ入ろうとして、忘れた車の鍵だけを取りに来た状況でも、ロボットが入室を拒むようなものだ
システムは安全に設計されているので、ロボットを言葉で説得することはできない。相手が人間なら、たいていは会話で説得し、機能する解決策を見つけるほうがずっと簡単だったはずだ
技術者は結局、技術で解決しようとする。「問題があるなら俺が解決する、DJが回している間に俺の技を見ろ」
口がうまく、人間のゲートキーパーを説得できるもっともらしい話を作れるというだけで、銀行口座がハッキングされる事態はそうして生じる
「はい、この人は実在の人間です」と言ってくれる手段なら有用かもしれないが、これは単なるシステム証明なので、悪意ある行為者を防げるのか、またCORSのような他のシステムと同様に誤解され、誤用されるのかを知る方法はない
このシステムの論理的な結論は、「正常なシステムを持っていれば正常なユーザーであり、持っていなければそうではない」となる
両方の立場はある程度理解できる
他者の意図を善意に解釈するなら、識別された人間とその承認済み代理者で満たされたWebは、私たちが見られる中で最も「クリーン」な理想的Web空間である可能性がある
偽アカウントやリンクファームだらけのWebは理想的ではない
この流れの最も明確な終着点は、身元証明にもログインにもなる政府発行のデジタルIDだ
目を細めて見れば、これはそこへ向かう足がかりのように見えるかもしれない
70年代風の理想主義が実現したのか？ そうではない。ただ、ある程度合理的な妥協だと思う
政府を信頼できないなら？ それはどんなインターネットでも解決できない可能性が高い。現実世界の問題だ
私には、より滅菌されたWebのように聞こえる
人間が最終的にはそのシステムも回避する方法を見つけるという事実をひとまず無視して、最も「クリーン」なWeb空間になると仮定しても、消費者がそれを望んでいると前提していることになる
ネイティブアプリの世界にはApp Store、ロックダウンされた統制、アプリの識別性がすでにあるのに、Webはいまだに商取引を支配しており、Figmaのような事例によってむしろさらに強くなっているように見える
では、この「浄化された」Webを求める声はどこにあるのか？ 少なくとも消費者側の需要はまったくそう見えない
なぜこれほどばかげて強い身元証明が必要なのか？ 本当に必要だったなら、インターネットはこれまでどうやって動いてきたのか？
とはいえ現在、実際には誰もそんなものを提案していない。AppleやGoogleの方式はいずれもそこに近づいてすらいない。彼らがやろうとしているのは、プラットフォームの「完全性」を保証することだ
具体的にどんな完全性なのか？ 例では、ユーザーが安全なAndroidデバイス上でWebクライアントを実行していることを示すという
つまり、ユーザーが唯一の人物かどうかを教えてくれるわけでも、個人について使える識別子を与えてくれるわけでもない。この例とAppleの場合に分かるのは、デバイスがroot化や脱獄されていないという事実だけだ
実際、この概念は、より大きないたちごっこの一部としてしか有用ではない。著作権保護と同じく、リモート証明も実際に証明する対象によって限界が決まる
映画館でビデオカメラ録画を防ぐのが難しく、結局のところ映画が連続した写真とPCMサンプルフレームであるという事実を利用した中間段階が多いのと同様に、デバイスが高価でも、誰かが複数台を確保して作業するのを止めることはできない
すでにシステムをだますためにAndroidデバイスを大量に持っている人も多く、場合によっては1台50ドルで買えるので、意味のある障壁ではない
結局はボット運用のコストと複雑さを上げる効果しかなく、損益分岐点を十分に高くできれば理論上は勝ったと言える。だが、スパムや詐欺で得られる利益があまりに大きいため、そうはならないだろう
何年もの対策を経てもまだ近づいてすらおらず、こうしたシステムをだます産業に流れる資金は、そのコストを賄って余りある
政府の身分証を混ぜても変わらない。ほぼすべてのスパム運営の背後には実在の人間がいるので、誰かが市民であるというブラインド証明を受け取っても、その人物について分かることはほとんどない
役に立たせるには、正当な対象であるという証明ではなく、実際に各人の一意なIDを受け取る形でなければならないだろう
そしてそれがインターネットの終着点なら、正直なところ、この実験全体に価値はなかった
偽のマウスやキーボードを差して入力を直接供給することもできる
セキュリティハードウェアには利点がないように見える。ある程度の規模で偽情報を広める人たちにとっては、スピードバンプにすらならない
ごく未熟な、あるいは軽度の悪意ある行為者を少し不便にするだけで、ブラウザを作れる人や、Linuxユーザー、Trusted Bootを切っている人のように信頼されないデバイスを使う人を大きく制限する
AllAdvantageを覚えているかどうか分からない
世紀の変わり目ごろ、デスクトップに広告を表示してお金を支払っていたサービスで、PCを実際に使用中のときだけ支払っていた
人々はマウスを動かす装置でだまし、小さな軍拡競争が起きた
この技術は彼らにとって夢のようなものだろう。リクエストが実際のブラウザから来たのかスクリプトから来たのかを知ることができ、信頼されていないドライバで入力をシミュレートしたり、ブラウザが自動化されたりした場合には証明を無効化することもできる
本当に不愉快な技術だ
これは、非常に人気のあるセキュリティ製品カテゴリをブラウザ自体に緊密に統合することに近い
今日は哲学的立場からreCAPTCHA/hCAPTCHAを使うすべてのWebサイトを拒否できるし、明日はPATを使うすべてのWebサイトを拒否できる