電話番号なし、アカウントなし: GoogleのQRウォールとGDPR
Googleは新規アカウント作成を電話ベースのQR検証で制限するようになった。スマートフォンがなければアカウントは作れない。これがGDPRのデータ最小化原則とどう衝突するかを解説する。

今日Googleアカウントを作ろうとすると、名前を一文字も入力する前に壁にぶつかるかもしれない。画面には「アカウントを作成する前にいくつかの情報を確認してください」と表示され、QRコードが現れ、スマートフォンのカメラでスキャンするよう求められる。クリックするリンクもなく、メールでの代替手段もなく、「スキップ」する経路もない。動作するカメラ付きのスマートフォンがなければ、アカウントは作れない。それがこのやり取りのすべてであり、立ち止まって見る価値がある。なぜなら、これは電話を静かにウェブ利用の前提条件に変えてしまうからだ。
私はオランダで、EU圏内に住んでいる。あの画面の言い回し(「Googleはあなたのデバイスまたは電話番号に関するいくつかの情報を確認する必要があります」)は、セキュリティ機能というよりも、不正対策を装った強制的な身元情報の収集のように読める。本稿は、その区別がなぜ重要なのか、そしてそれがGDPRとどこで衝突するのかについてだ。
画面が実際に要求していること
このプロンプトを文字どおりに読んでみよう。アカウントを作成するために、あなたは次のことを求められている。
- QRコードをスキャンできるカメラ付きのスマートフォンを所有していること。
- そのフローを電話側に引き渡し、開始したデバイスを離れ、Googleが事前に提示しない手順を完了すること。
- 新しいアカウントを電話番号と結びつけること。EUの大半では、電話番号はSIMレベルで検証済みの政府発行の身元情報と結びついている。
- 同じファネルの後半で、生年月日やその他の個人情報を提供すること。
これらのいずれも、メールアカウントが機能するための技術的な要件ではない。受信箱があなたの誕生日や端末のモデル、通信事業者を知る必要はない。これらは収集に関する判断であって、エンジニアリング上の制約ではない。そして、収集に関する判断として評価されるべきものだ。
「不正対策」がここで多くを担いすぎている
その正当化はボット対策だ。「コンピュータープログラムやボットによる不正利用の防止」。これは現実の問題であり、アカウント作成にレート制限をかけることは正当だ。しかし、この制御の形に注目してほしい。これは、人間なら解けてスクリプトには解けないパズルを解くよう求めているのではない。電話を提示することを求めているのだ。検証されているのは「あなたは人間か」ではなく、「フィンガープリントを取って相関付けできるデバイスと番号を出せるか」だ。
これらは異なる目標だ。前者は不正対策に見合っている。後者は身元の紐付けであり、サインアップ時に電話番号がいったん付与されると、それが収集された目的の範囲内にとどまることはまれだ。「セキュリティのために」追加された番号は、広告ターゲティング、アカウント復旧のソーシャルグラフ、サービス横断の相関付けへと流れていく長い歴史を持つ。セキュリティチームはこれを機能のなし崩し的拡大(function creep)と呼ぶ。GDPRはこれを目的制限の問題と呼ぶ。
これがGDPRとどこで衝突するか
私は、ある裁判所がこの特定のフローを違法と判断したと主張しているわけではない。データ保護当局(DPA)が実際に検討するであろう原則を指し示しているのだ。なぜなら、それらは「これをスキャンするか、立ち去るか」とは相性が悪いからだ。
データ最小化、第5条(1)(c)
個人データは、その目的に対して「十分かつ関連性があり、必要な範囲に限定」されていなければならない。ここでの目的はメールアカウントの作成だ。電話番号と生年月日は受信箱を運用するために必要ではない。つまり、なぜそれらを収集するのかを示す責任は管理者側にあり、拒否を正当化する責任は利用者側にはない。
自由に与えられた同意、第4条(11)および第7条(4)
同意は、自由に与えられた場合にのみ有効だ。規則は明示的に、サービスがそのサービスに必要でない処理への同意を条件としていないかを考慮しなければならないと述べている。「電話番号がなければアカウントはない」は、条件付けの教科書的な定義そのものだ。データ共有以外の唯一の選択肢がサービスから完全に排除されることである場合、その「選択」はほとんど意味を持たない。
比例性と必要性
同意ではなく正当な利益を根拠とする場合でも、その処理は必要性とバランステストを通過しなければならない。サインアップのごく一部を占めるにすぎないボットを排除するために、所有していないかもしれないハードウェアをすべての見込み利用者に強制することは、CAPTCHA、メール確認、行動シグナルがすでに存在し、いずれもカメラを必要としない以上、最も侵襲性の低い選択肢とは言いがたい。
誰も設計で考慮しない排除
プライバシーの問題の下に、もっと静かな問題がある。QRとカメラのゲートは、特定の利用者を前提としている。新しめのスマートフォンを所有し、コードを物理的に見てスキャンでき、アカウント作成フローを端末に移すことに抵抗がない人だ。その前提は、デスクトップだけを使う人、視覚障害のある人、フィーチャーフォンを使う人、意図的にデバイスを最小限に保つ人、そして個人の電話をすべてのログインに組み込みたくないだけの人を排除する。
「電話を使えばいい」は中立的なデフォルトではない。それは、Googleの不正対策のコストを利用者に、スマートフォンを当然のものとして持っていない利用者にも押し付ける設計上の判断だ。アクセシビリティとデータ保護はここで同じ方向を指している。これほど中心的なサービスには、特定のハードウェアの所有を必要としない経路があるべきだ。
EUが実際にできること
これに異議を唱えるためのGDPRの仕組みはすでに存在する。新しい法律は必要なく、必要なのは上記の原則の執行だ。
- サインアップ時の電話番号と生年月日をデフォルトで不要なものとして扱い、管理者が必要性を主張するのではなく証明するよう求めること。
- 第7条(4)の条件付けの論理に基づき、スマートフォンや番号を必要としない真の代替経路をアカウント作成に義務付けること。
- 目的を精査すること: 不正対策のために収集された番号が後に広告や相関付けに使われた場合、それはサインアップ画面の文言がどうであれ、目的制限違反だ。
EDPBの協調した見解、あるいは断固とした一つのDPAだけで、設計のやり直しを迫るには十分だ。私たちはまさにこのパターンをクッキーウォールで見てきた。規制当局は最終的に「同意するか、立ち去るか」は本当の同意ではないと判断した。ハードウェアの壁は、カメラがくっついた同じ議論だ。
今日あなたにできること
上記のどれも、実際にアカウントが必要な5分間の助けにはならない。だから実践的には次のとおりだ。
- 自分が管理するアカウントについては、電話を要求しないプロバイダーを使うこと。複数のEU拠点のメールプロバイダーは、番号を必須ではなく任意として扱っている。
- 身元と利便性を分けておくこと。 どうしてもどこかに番号を付ける必要があるなら、銀行や政府の身元情報を支える番号を使い回さないこと。
- 自分の権利を行使すること。 Subject Access Request(開示請求)、そして適切な場合には自国のDPAへの苦情申し立ては、象徴的なものではない。それらは上記の原則を圧力に変える仕組みだ。
要点
アカウント作成時のQRと電話の壁はセキュリティとして売り込まれているが、それが実際に守るデータはあなたのものであり、参加の代償として差し出される。EUではその代償に法的な枠組みがある。データは最小化されなければならず、同意は自由でなければならず、サービスは機能するために必要としない情報の提供を、自らの条件として静かに設定することはできない。「これをスキャンしろ、さもなければアカウントは持てない」は、その三つすべてに表面上から反している。規制当局がそう声に出して言うかどうかは、この時点では、法律の問題というより意志の問題だ。
次はこれを読む
- AWS Organizationsのマルチパーティ承認。身元と承認の制御が、権力を収集するためではなく抑制するために設計されたとき、どう見えるかについて。
- SSHが量子コンピューターについて警告してくる理由。セキュリティ警告を額面どおり受け取ることと、それが実際に何を守っているのかを読むことについて。
AIアシスタントが、渡された身元と同意のデータをどう扱うかについて考えているなら、ercan.aiのフィールドノートがそれを扱っている。クラウド、セキュリティ、コンプライアンス型のプラットフォーム業務に関するコンサルティングは、ercanermis.comから始めてほしい。
Ercan の他のサイト
同じ著者、別の領域のサイトが2つ。