Google Cloud Fraud DefenseはWEIの看板を掛け替えただけにすぎない

 (privatecaptcha.com)
1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • Google Cloud Fraud Defense は2026年に「reCAPTCHAの次なる進化」として発表されたが、その中核は2023年に撤回された Web Environment Integrity と同じデバイス証明インフラにある
  • Fraud DefenseのQRチャレンジは、ユーザーがスマートフォンでコードをスキャンすると Play Integrity API でデバイスを認証し、その結果を元のサイトに返して人間の存在証明として使う
  • 通過可能なハードウェアは、Google Play Servicesがインストールされた最新のAndroid端末、または最新のiPhone/iPadに限定され、GrapheneOS、LineageOS for microG、Firefox for Androidのような選択肢は事実上排除される
  • QRチャレンジは、カメラを画面の前に置く方法で回避でき、互換性のあるAndroid端末も約 $30 で買えるため、専門的なボットファームにとって大きな障壁にはなりにくい
  • チャレンジが成功するたびにGoogleには「認証済みデバイスが特定の時刻に特定のサイトへアクセスした」というシグナルが送られ、これはセッションやブラウザをまたぐ 帰属情報 を生みうる

Google Cloud Fraud DefenseとWEIのつながり

  • 2026年5月、Googleは Google Cloud Fraud Defense を「reCAPTCHAの次なる進化」として発表し、ユーザーがスマートフォンでQRコードをスキャンして人間の存在を証明するチャレンジを紹介した
  • 2023年、Googleのエンジニア Yoav Weiss はChromiumプロジェクトに Web Environment Integrity 提案 を投稿した
    • ブラウザにデバイスハードウェアへの暗号学的証明へ署名させ、ブラウザが改変されておらず、Google認証済みハードウェア上で動作していることを証明する仕組みだった
    • Webサイトはこの署名を検証して、コンテンツを摩擦なく提供するか、追加チャレンジを要求するかを決められた
    • 提案の名目は、ボットや自動スクレイピングに対抗してWebの完全性を守ることだった
  • Mozillaは数日以内に 公式見解 を出し、この提案は「ユーザーの利益に反する」ものであり、「OSとデバイスベンダーが支配するゲート型インターネットを作る」と評価した
  • Electronic Frontier Foundationはこれを 「ChromeのWeb DRM計画」 と呼び、設計上、Androidや認証済みハードウェア上で動くChromeだけが容易に証明を通過でき、トラフィックがGoogleエコシステムへ流れることになると見た
  • Googleは公開から3週間後にWEIを撤回し、ChromiumのGitHubスレッドも閉じられたが、2026年のFraud Defenseでは同じ デバイス証明 インフラが商用製品の基盤として投入された

QRコードチャレンジの実際の仕組み

  • Fraud Defenseチャレンジは、ユーザーがWebサイト上でQRコードを見て、スマートフォンのカメラでスキャンする方式で動作する
  • スマートフォンはGoogleの Play Integrity API を通じて認証され、そのデバイスが認証済みハードウェアであることを確認する
  • この確認結果が元のサイトへ戻され、人間の存在証明として使われる
  • Fraud Defenseの要件ページでは、通過可能なハードウェアを「Google Play Servicesがインストールされた最新のAndroid端末、または最新のiPhone/iPad」と定めている
  • Google Play Servicesは、認証済みAndroid端末で動作するGoogleの非公開ソースのソフトウェア層であり、デバイスが改変されておらずGoogleの承認を受けていることを証明するPlay Integrity APIを提供する
  • Play Servicesのない端末は、Fraud Defenseが要求するレベルのPlay Integrityチェックを満たせず、この条件自体がFraud Defenseの中核メカニズムとして機能する
  • WEIでは標準レビューの過程でGoogleがそのメカニズムを公に擁護する必要があり、反対に直面して撤回されたが、Fraud DefenseはGoogle Cloudの課金アカウントを持つ組織が利用できる商用サービスとして、そのままリリースされた

QRコード回避とフィッシングのリスク

  • QRコードチャレンジは、ボット運営者が画面の前にカメラを置く方法で機械的に回避できる
  • Play Integrity証明が必要な作業でも、互換性のあるAndroid端末は約 $30 で購入可能で、例としてWalmartの $29.88 Motorola Moto g 2025 がある
  • 端末を大量購入する専門ボットファームにとって、このコストは運用を実質的に妨げない固定費に近い
  • HNスレッド では、インシデント対応の専門家が、現実的には「人事部のSusan」に本物のGoogle Captcha QRコードと悪意あるフィッシングQRコードを見分けるよう教えるのは難しいと懸念している
  • QRチャレンジは、Webサイトへアクセスするためにコードをスキャンする行動をユーザーに学習させるものであり、フィッシングキャンペーンはこの行動をそのまま悪用できる

既存のQR認証・デバイス証明との違い

  • iOS App Attestationは、アプリがApp Store経由でインストールされ、改変されていないことを検証する
  • iPhoneユーザーが自ら選んだ閉鎖的エコシステムの中でアプリを管理することと、オープンなWeb閲覧においてURLへのアクセスを民間企業が認証したハードウェアに条件付きで結びつけることは性質が異なる
  • オープンインターネットでこのような形で適用された前例はなく、アプリストアは明示的な利用規約のある選択制エコシステムだが、Webはハードウェア条件を前提に設計されていない
  • QRベースの認証自体はすでに存在する
    • Estoniaの Smart ID は、銀行ポータル、政府サービス、医療記録のように境界と同意範囲が定まったリソースで、QRコードを使ってユーザーを検証する
    • ユーザーは認証を選択し、保護されるリソースは事前に定義され、範囲も明確である
  • Google Cloud Fraud Defenseは、運営者がゲート対象に指定した任意のURLに対して、オープンWeb上でデバイス証明を適用できる
  • この方式には同等の同意構造や目的制限がなく、ユーザーは自分のハードウェア上のアイデンティティがアクセス資格情報のように機能していることに気づきにくい可能性がある

プライバシーを重視するユーザーの排除

  • Google Play Integrity証明にはGoogle Play Servicesが必要である
  • GrapheneOS は、標準ではPlay Servicesを含まないセキュリティ強化Androidフォークであり、EFFが推奨し、ジャーナリスト・弁護士・活動家が高リスク環境で利用している
  • GrapheneOSは一部のPlay Services機能を実行するサンドボックス互換レイヤーをサポートしているが、Fraud Defenseが要求する MEETS_DEVICE_INTEGRITY レベルのPlay Integrityは満たせない
  • オープンソース代替を望むユーザー向けに作られたプライバシー志向のAndroidディストリビューション LineageOS for microG も同じ理由で失敗する
  • Play Servicesを除いたすべてのカスタムROMはFraud Defenseの要件を通過できない
  • Firefox for Androidは、Googleが明示したFraud Defenseのブラウザ対応一覧に見当たらない
  • Firefoxは設計上Google Play Integrityを統合しておらず、Mozillaの2023年のデバイス証明への反対姿勢は明確で、現在も維持されている
  • その結果、主要モバイルブラウザの中でプライバシーを重視するFirefoxユーザーは、ボットだからではなく、Googleの認証アーキテクチャへの参加を拒否するソフトウェアを使っているために、デフォルトで検証済みアクセスから除外される

「正当な」追跡の問題

  • Fraud Defenseチャレンジが成功するたびに、Googleには「この認証済みデバイスがこの時刻にこのサイトへアクセスした」というシグナルが送られる
  • デバイス証明はアクセスを拒否または許可する機能だけではなく、帰属情報 を生成する
  • 安定したハードウェアアイデンティティを持つデバイスは、セッション、ブラウザ、プライベートブラウジングモードをまたぐ持続的識別子を生み出しうる
  • どのハードウェアが「正当」かを定義する企業は、オープンWeb上でそのハードウェアがどこへ移動したかについての継続的な記録も蓄積することになる
  • これは詐欺対策の副作用ではなく、検証を認証済みデバイスのアイデンティティに結びつけるという構造的な決定である

代替案として提示されるプルーフ・オブ・ワーク方式

  • Private Captchaや 類似のプルーフ・オブ・ワークシステム は、計算努力を必要とする暗号学的チャレンジを発行する
  • 1人のユーザーが単一のチャレンジを解くコストは無視できるほど小さい
  • 複数の同時セッションを走らせるボットファームは、追加試行ごとに計算コストが増大する
  • GPUサイクルを消費して動くAIエージェントも、推論能力がどれほど高度であっても同じコストペナルティを受ける
  • この方式はハードウェア識別子を送信せず、証明を要求せず、誰が参加できるかを決める認証レイヤーも置かない
  • ユーザーのプライバシーは約束としてではなく、構造的に保全される

関連記事

1件のコメント

 
GN⁺ 1 시간 전
Hacker Newsの意見

  • これはずっと前から予想されていたこと。コンピュータは人間よりCAPTCHA解読が得意だし、人間は金をもらったり説得されたりしてボットネットに組み込まれうるので、IP許可リストも通用しない
    今ではフィンガープリンティングや行動分析が大量にあるが、政府はその方面を規制している。YouTubeでも埋め込み動画で広告がバックグラウンド再生される大規模な広告詐欺問題があったので、検知は十分ではなかったということになる
    ボットではないことを証明する良い方法は多くなく、本人確認のようなものを含まない方法はなおさら少ない。このオプトイン方式は当面、責任を個々のウェブストアに振るのに役立つだろうが、長期的には開かれた人間中心のインターネットが消えるか、このような証明ベースの検証の背後に閉じ込められることになりそうだ
    Appleは数年前にCloudflareとともにSafariへリモート認証を入れており、Googleは今それを一歩先に進めている。Apple方式は、スクリプト自動化ツールではなくブラウザを実際に操作するボットにはあまり効かないからだ
    幸い、現在の方式は主に店舗のような場所だけを狙っているので、別の店で買えば回避できる。しかし店舗側が、クリックファームにリモートコンテンツをタップするだけの携帯電話が何百台もあると知れば、導入は限定的になるかもしれない
    これが全面的に広がるまでには数年かかるだろうが、AIが突然広く使われなくならない限り、結局は避けにくそうだ

    • CAPTCHAが当初は逆チューリングテストとして普及したのに、今では事実上、作業証明（Proof of Work）の変種のようになっている点が興味深い
      当時GoogleがそれをOCRモデル改善に活用したのは賢かったし実際そうだったが、今日の証明された「作業」からどんな効用が生まれるのかは疑問だ
    • 人にQRコードをスキャンさせる対価を払い、位置情報を偽装する形で、これも回避されないと考えるのは難しい
    • 人を買収するというのが具体的にどんな形なのか気になる。どれくらい稼げて、何をすればいいのか、ネットワークに小さな箱を差して放置すればいいのか気になる
      次の支払い前に抜いておけば交渉になるのかも気になる。生活のために血漿売却を避けたい友人の代わりに聞いている
    • 個人的には、LLMが操るブラウザセッションを検知するほうが簡単だと思う。そういうものを配布する人たちは、従来のスクレイパーやクローラー界隈よりずっとナイーブで経験不足だ
      「学校に40ペタバイトのZip Bombを持っていかないよね？」というミームを入れたくなる
    • コスト構造次第だが、Googleはゲームのアンチチートのように最終的には負ける可能性が高い。画面画像を解析し、入力をUSBデバイスのように送るツールがあれば、検知できるものは実質的にない
      ウェブページでこれをやるのは、ビデオゲームよりずっと簡単に見える

  • 「Don’t be evil」から、世界最大かつ最も侵襲的な監視システムを作る企業へと変わった
    この件以前からそうだったが、今回の件はGoogleにとって追跡はどれだけあっても足りないことを示している。Googleは皆のオンライン活動をさらに追跡しようとし、可能なあらゆる道具を使うだろう

    • Googleという抽象的存在ではなく、このアイデアを考え出して押し進める具体的な人間がいる
      企業を抽象的な実体としてだけ見るのではなく、こうした決定を下す病んだ人々の集団として見るべきだ

  • 連続でクリックしたHNリンク3つが全部LLM生成記事につながった気がする。AI自体に反対しているわけではないが、人間の思考や表現が静かに置き換えられていくのを見るのに疲れた

    • 「これは明らかにAI生成だ」という態度をよく見るが、なぜそう見えるのか気になる。何がLLM生成で、どうやって分かるのか？
      むしろ明らかなのは、私たちの信頼システムがすでに壊れているという点だ。コメント投稿者同士が互いをAI呼ばわりするのもその一例だ

  • AMPだろうがManifest V3だろうがAndroidソースいじりだろうが、CookieをFLoCのようなたわごとに置き換えようとした試みだろうが、今回の件だろうが、Googleはオープンインターネットに対して急速に悪意ある勢力になりつつある

    • 結局RMSはいつも正しかったわけだ。驚くべきことだ
    • AMPは4〜5年前、マーケティング中心のウェブ開発会社で働いていたとき本当に厄介な代物だった
      「Googleは、ユーザーの時間を少し節約できるという理由で、あなたの記事を自分たちのイケてないUIに押し込むのが大好きだ」という感じだった
      一方ではサイトを差別化しろと複雑なデザインを求められ、他方ではウェブデザイン全体をすっ飛ばして、あらかじめ決められたUIにコンテンツを流し込みたがる巨大企業に屈する形だった
      消えてくれて本当に良かった。Googleの全体的な前歴を見れば、数年で死ぬと分かっているべきだった
    • 前回のWEIの時も、Google社員たちは影響は小さい、たいしたことではない、人々はヒステリーだと矮小化していた。今確認したら、それを擁護していた人たちは皆会社を去っていた
      上層部に気に入られたいGoogle管理職の新しい波が、まもなくこの新計画を守りに来るだろう
    • 周囲が閉じていくのが見えないのか？ Googleだけの話ではない。世界中の政府と企業が同時に動いている。締め縄は徐々に締まり、ある時点で一気に締め上がり、私たち全員を狙うことになる
      https://community.qbix.com/t/increasing-state-of-surveillanc...
      脅威は設計上、あるいは収斂的にかみ合っている。身元レイヤー（1〜5）は他の前提条件を作り、SIM/アカウント/デバイスレベルで身元が確立されると、政治的に監視を可能にする例外が生まれる。権力ある利用者は免除され、一般利用者は監視される
      デバイスレイヤー（10〜12、16〜19）は監視エンドポイントを作る。暗号化前にデバイス上でコンテンツをスキャンされれば、通信レイヤーの暗号保護は無意味になる
      通信レイヤー（6〜9）は最もよく防御されてきており、大規模スキャンは繰り返し阻止されてきた。抵抗の実績が最も良いレイヤーだ
      通報レイヤー（13〜15）は初期段階だ。OSから政府へ直接通報するフックはまだ大規模には作られておらず、英国の2025年12月提案がその最前線にある
      プラットフォーム統制（20〜24）は代替手段が存在できるかを決める。ブラウザ多様性、アプリ配布多様性、エンジン多様性が構造的な保護装置だが、3つとも狭まっている
      5つのレイヤーがすべて完成した社会は、エリート向けの例外条項つき全面監視インフラを持つことになる。私たちはおよそ40%地点に来ている。そのインフラがディストピアになるかどうかは技術ではなく政治的選択にかかっている
      HN全体が締め縄が締まっていくことに驚くほど鈍感なのは、トークンが少しでも絡む分散型の脱中央集権的な代替案に強く反対する人が多いからでもある。不平を言うことはできても、集団思考のせいで脱中央集権的な代替案を埋もれさせてダウンボートするのは、プライバシーと自由の侵食にある程度加担することになる。プロジェクトに同意しなくても、そこに注がれた作業自体はアップボートする理由になりうる。そうした作業がなければ、実質的に終わりだ
    • 「急速に変わっている」のではなく、もともとそうだった
      Googleは文字通り数十年前から、「Open Handset Alliance」のようなカルテルを作っていた
      独占状態のChromeとSearchを支配することで、Googleはウェブサイトがどうレンダリングされ、どう発見されるかについて絶対的な権限を握っている

  • Chromeから離れることを強く勧める。Googleは敬意を完全に失った
    小さな動きではあるが、Chromeが最初に登場した時のように他のプレイヤーへ機会を開けるかもしれない

    • 広告ブロッカーを壊した時にChromeを離れようと本当に努力し、数か月間代替を使ってみたが、他のブラウザは気に入らなかった
      Macでは主にSafariを使うが、Windowsではその選択肢がなく、大手プレイヤーは気に入らず、小さなプレイヤーは信頼しにくい
      「大きい」小さなプレイヤーでさえ、セキュリティ面ではそれほど信頼できない。Arcブラウザの「Boosts」機能のように、リモートコード実行を可能にした例もあった
      それで結局Chromeに戻った

  • Googleが何をしようと嫌いだが、この記事には問題がある
    「Play Integrity証明が必要な作業の場合、規格を満たすAndroid端末は現在の市場価格で約30ドル」という部分は、Google側のロジックが if(attestationResult == "success") allow() のようなものだと仮定している。しかし、端末タイプがある不正スコアに反映されると考えるのは難しくない。たとえば高価な端末は安価な端末より不正スコアが低いかもしれず、安価な端末の大量購入を抑制できる。特定サイトの端末の組み合わせも分析できるので、中国製携帯電話が何千台も突然Anne's Muffin Shopに登録し始めれば、より高い不正スコアを受けるはずだ
    「Firefox for AndroidがGoogleのFraud Defenseブラウザ対応リストにない」という部分も、ブラウザはQRコードを表示するだけでよいので、Firefoxモバイルなら携帯電話のGoogle Play Servicesでディープリンクを開くか、QRコードを表示すれば済む
    作業証明ベースのボット防御がほとんど定着しなかったのは、JavaScriptの性能が低く、人の時間はコンピュータ時間より高いからだ。攻撃者はサーバーが作業証明問題を解くのに10秒待つことを気にしないが、人間は気にする。Hetznerでは8コアサーバーが1時間10セントだ。皆が8コアのデスクトップ級CPUを使うと仮定しても、6分チャレンジは攻撃者にとって1セントのコストにすぎない。では普通の人は、自分の6分をいくらと評価するだろう？

  • これは本当に不快で、公の議論もなくこんなふうにこっそり押し込もうとするのは不誠実だ。前回のように阻止されてほしい。少なくとも反トラスト問題は明らかにありそうだ

    • 反トラスト問題には同意するが、今どきそれが深刻な障壁とみなされるのかはよく分からない
    • 前回もGoogleは自社と距離を置こうとして、社員個人のGitHub経由でこれをロンダリングし、あたかもユーザーが望んでいるかのように最大限不誠実に提案を包装していた
      実際にはGoogleが支配権を行使するためのもう一つの仕組みだった

  • 間抜けな質問かもしれないが、これがiPhoneユーザーにはどう動くのか分からない。Google Playがなく、ここではAndroid/Google Playが必要なように見える
    市場のそんな大きな部分を切り捨てるはずはないだろう

  • この記事は誤った前提だらけだ
    たとえば「ボット運営者は既製ハードウェアで画面にカメラを向けるという些細な自動化を行う。Play Integrity証明が必要な作業には30ドルの対応Android端末が要る」という部分がある
    ボットファームは30ドルの携帯電話で長く回避し続けることはできない。Googleが同じハードウェア識別子が1日に何千回も現れるのを見ても不正利用だと思わないと本気で考えているのか？
    ウェブが終わりなきAIゴミになるのを避けるためにGoogleが実際の提案を出した点は評価する。この記事はより良い代替案を出しておらず、そういう代替案を見てみたい

    • 携帯電話は、特に整備済み品なら非常に安い。実生活のような睡眠/起床サイクルを真似て、ときどき休ませればいい。稼働時間の損失を見込んで端末を25%多めに使えばよい
      しかも実際に、一日中、夜通し携帯だけをスクロールする人たちもいる。失業者、障害者、睡眠障害や躁状態の人かもしれない。だから、より大きな反発を生まずにこれを良いシグナルとして使うのは難しい。無限の自由時間を持つ苦しい立場の人々からの反発は本当に避けたいはずだ
    • 特に滑稽なのは、これが計算ベースの作業証明「CAPTCHA」を売るコンテンツマーケティングだという点だ
      そういう方式は純然たる詐欺的技術であり、経済性ではこの証明方式より悪用者に少なくとも4桁有利である可能性が高い
    • AIが30ドルという数字を私のHNコメントから盗んだようだ。ただし米国では事実だ。 https://www.walmart.com/ip/Straight-Talk-Motorola-Moto-g-202...
      通信会社ロックはこの用途では関係ない。EUで固有の端末識別子を保存するのが合法かどうかは分からない
    • 誰かがこれを製品化しそうだ。クラウド携帯依存はすでにあり、CAPTCHA解読サービスが需要も証明しているので、クラウドサービス化すればまた振り出しに戻る
    • ボットファームが30ドルの携帯電話で長く回避し続けられないというのは、すでに間違っている。彼らはすでにそうしており、端末1台あたり30ドルではなく、5ドル未満に近い
      中古市場で最悪中の最悪だけを買えばいいからだ
      デバイス認証に賭けるというのは、スマートフォンが今より普及しなくなり、所有コストがもっと高くなることに賭けるのと同じだ。そうはならなそうだ

  • Googleがなぜこれをやりたいのかは理解できるし、人々がなぜこの特定の解決策に反対するのかも理解できる
    この記事の著者が、この問題に対する作業証明による解決策を売っている点も見る必要がある
    作業証明がここで正しい方向なのかについてはかなり懐疑的だ。ウェブ利用者の中には古いハードウェアを使っている人が多い。計算通行料を追加しても、人々が使える計算資源が互いに異なる世界では問題は解決しない
    一方でボットネットは数千台のコンピュータにアクセスでき、10秒余計に待つことを気にしないかもしれない。さらに悪いことに、ASICベースの専用解決策を作って、おばあちゃんのノートPCより数千倍速く作業証明パズルを解けるかもしれない