Chromeがまた google.com だけを残した — バグか、構造か
Chromeがまた google.com だけを残した — バグか、構造か
ブラウザが自社サイトだけをデータ削除設定から取りこぼした。これはQAの失敗か、それともQAが見る理由を持たない構造の産物か?
導入
2026年9月5日、開発者のJeff Johnsonが短い記事を公開した。タイトルは「Chromeがまたユーザーのサイトデータ設定からGoogleを除外している」。Hacker Newsで618ポイントを集めた。
内容自体は複雑ではない。Chromeには chrome://settings/content/siteData で有効にできる設定がある。「すべてのウィンドウを閉じたら、サイトがデバイスに保存したデータを削除する」というオプションだ。Johnsonはこれを既定の動作として有効にし、Chromeにサインインせず、サインイン自体を禁止していた。混乱を避けるため既定の検索エンジンもGoogleからDuckDuckGoに変更した。その状態でGoogle検索を一度行い、唯一のウィンドウを閉じ、再び設定画面を開いた。
google.com のサイトデータが残っていた。Cookieとローカルストレージ、セッションストレージである。Chromeを完全に終了して再起動しても残った。削除して同じ手順を繰り返すと、また生成された。Johnsonが確認した範囲で除外されていたサイトは www.google.com ただ一つだった。
この記事が618ポイントを集めた理由は、発見そのものの技術的難度ではない。Johnsonは6年前に事実上同じ記事を書いており、そのときGoogleはバグを修正した。修正されたものが戻ってきたという事実こそが核心である。
再現されたものと、再現されなかったもの
まず事実関係を整理しておこう。Johnsonが実際に確認したと記しているのは次の通りだ。
Chromeのバージョンは 152.0.7977.83 で、異なる2台のMacで再現した。設定画面 chrome://settings/content/all で事前に保存済みサイトデータがないことを確認し、事後に google.com の項目が生成されたことを確認した。保存場所は ~/Library/Application Support/Google/Chrome/Default フォルダで、残ったデータの種類はCookie・ローカルストレージ・セッションストレージだった。
6年前の事件との対照も原文に書かれている。Johnsonは当時「Chromeがユーザーのサイトデータ設定からGoogleサイトを除外している」という記事を書き、それがかなりの注目を集めたと述べている。彼自身が列挙した反響は Michael Tsai、Hacker News、The Register、The Verge、Gizmodo である。そしてその報告に促されて、最終的にGoogleはバグを修正したと記している。つまり今回の記事の見出しに付いた「また」は修辞ではなく記録だ。同じ人物が、同じ設定で、同じ方向の除外を二度発見している。
違いもある。6年前はGoogle所有のサイト群がまとめて除外されていたが、今回Johnsonが確認した範囲では www.google.com ただ一つだった。範囲が狭まったことが修正の残滓なのか、新しい経路の副作用なのかは外部からは判別できない。ただ狭まったという事実自体が、この現象が無作為ではないことを示唆する。無作為な欠陥が6年の間隔をおいて二度とも同じドメイン系列だけに当たる確率は高くない。
一方でJohnsonが確認していないと自ら明記したこともある。この問題がいつ混入したのかは分からないという。彼の既定ブラウザはSafariで、Chromeはテスト用途で頻繁に使うだけだからだ。そして意図についても断定していない。「私は陰謀論を唱えるよりハンロンの剃刀を引用する側に近い」と明記している。悪意で説明できるものを無能で十分説明できるなら、無能の側を取るという原則である。
この区別は重要だ。この種の発見はすぐに「Googleが密かに追跡している」という結論へ翻訳されやすいが、原文の著者本人がその翻訳を拒んでいるからである。代わりに彼は別の点を突いた。この会社とこの会社のエンジニアが稼ぐ金額の規模を考えれば、無能も言い訳にはならないということだ。彼が提案した対応策は陰謀論的ではない。この機能にユニットテストを付けろということ、そして「速く動いて何かを壊す」のではなく、ゆっくり動いて壊すなということだった。
Hacker Newsの議論では技術的な反論も出た。ある利用者は、テストの間にすべてのChromeプロセスが実際に終了したかをまず確認すべきだと指摘した。ゾンビプロセスが残っていればデータが生き残るのは当然だという(@mgiampapa)。合理的な疑いである。ただしこれに対する反駁も即座に出た。ならばなぜ他でもなくGoogleのデータだけがセッションをまたいで保存されるのか、と。どこかでGoogleが自社データを特権化しており、ブラウザがすべて削除するよう設定された状態でそれだけが削除されていない、という反論だ(@freeAgent)。
もう一つ挙げるに値する指摘は、ChromeとChromiumの分離である。ChromeはChromiumと違ってGoogleの非公開ソースソフトウェアだというものだ(@thinker34)。つまりこの除外処理がオープンソース側のコードにあるかどうかを、外部から読んで確認する方法がない。再現はできるが、原因のコードは監査されない。
なぜこのバグだけが繰り返されるのか
核心の問いに進もう。無能だとしよう。ではなぜ無能は毎回同じ方向へ傾くのか。
ソフトウェアにはバグがある。それ自体はニュースではない。ニュースになるのはバグの分布だ。もしサイトデータ削除機能に無作為な欠陥があるなら、例外として残るサイトも無作為であるはずだ。ある日はWikipediaが残り、ある日はどこかのブログが残らなければならない。ところがJohnsonが確認した範囲で残ったのは www.google.com 一つであり、6年前の同系統のバグでも残ったのはGoogle所有のサイト群だった。
ここで必要なのは意図についての推測ではなく、構造についての観察である。大規模ブラウザのコードベースには、自社サービスのための特殊処理経路が実際に存在する。ログイン状態の同期、同意管理、検索機能の統合、セーフブラウジングといった機能は、特定のオリジンを異なる扱いにする正当な理由を持つ。問題は、こうした経路が増えるほど「すべてのサイトデータを削除する」という単純なユーザーへの約束と衝突する表面積も一緒に増える点だ。そしてその衝突は一方向にしか傾かない。特殊処理は常に自社オリジンに付くのであって、サードパーティのオリジンには付かないからである。
テストの観点でも非対称が生じる。この種の欠陥を捕まえるには「設定を有効にした後、Googleにサインインしていない状態で検索してウィンドウを閉じたとき、残留データが0でなければならない」という形の検査が要る。ところがこの検査を書くには、まずそのシナリオを疑わなければならない。社内の開発者の大半はサインインした状態で、Googleを既定の検索エンジンにして使う。Johnsonがわざわざ既定の検索エンジンをDuckDuckGoに変え、サインインを禁止してまでテストした条件は、社内では誰も毎日踏まない経路だ。検査されない経路は、欠陥が蓄積する経路になる。
だからハンロンの剃刀を受け入れても結論は大きく変わらない。意図がなくとも結果は偏る。利害が懸かっている側のコード経路がより多く、その経路を踏むテストがより少ないからだ。これを個人の悪意で説明する必要はない。ただし「だから問題ない」という結論も導かれない。ユーザーが受け取った約束は「我々に悪意はありません」ではなく「すべてのウィンドウを閉じたらデータを削除します」だった。
Hacker Newsの議論のかなりの部分が米国の政治的な陣営論争へ流れたことも、この構造を示している。ある利用者は判決と規制の限界を指摘し、どちらが政権を取っても大手事業者の利害が代表される点が問題だと書いた(@shevy-java)。別の利用者は、監視資本主義を糾弾する人々が、実はその基盤を作り維持しているのはこの掲示板を読むエンジニアたちだと指摘した(@usr1106)。規制がゆっくり動く間、実際の既定値を決めているのはコードを書く人間だという話である。
検証可能性だけが残された防衛線だ
この件から実務者が持ち帰るべきは「Chromeを使うな」という勧告ではない。もっと手前の教訓である。
第一に、設定UIは動作の証拠ではない。Johnsonの手順で決定的だったのは、設定画面が「削除する」と表示していた事実ではなく、ディスク上のプロファイルフォルダと chrome://settings/content/all の一覧を直接開いて残留物を数えた事実だ。プライバシー設定を扱う製品を作る、あるいは導入審査をするなら、トグルの存在ではなく、トグルを入れた後に残るバイトを検査対象にすべきである。有効にしたという陳述と、消えたという観測は、別種の証拠だ。
第二に、この種の検査は陰性対照を伴って初めて意味を持つ。「残留データが0件である」という検査は、検査自体が壊れていても通過する。一覧を読めないスクリプトは常に0件を報告する。必ず残らなければならない条件、たとえば削除設定を切った状態で同じ手順を回し、実際にデータが検出されるかをまず確認して初めて、0件という結果が意味を得る。Johnsonがデータを削除して手順を繰り返し、再発を確認したことが事実上この役割を果たした。
第三に、監査可能性の格差を記録しておく必要がある。Chromiumは読めるがChromeは読めないという指摘は、この案件の限界を正確に突いている。外部の観察者にできるのはブラックボックス再現だけだ。だからJohnsonのような個人開発者の再現報告が、実質的な監査機能を代替している。6年前の彼の記事が修正につながったという事実は、この経路が機能している証拠であると同時に、この経路以外にほとんど何もないという証拠でもある。
第四に、この件を「プライバシーのニュース」ではなく「契約違反の有無」として読む方が実務に近い。企業環境ではブラウザ設定がしばしばポリシーで強制され、そのポリシーは監査対象になる。「セッション終了時にサイトデータを削除」を組織ポリシーとして配布しておきながら特定のオリジンが例外なら、それは好みの問題ではなく遵守項目の失敗だ。そしてその失敗は設定画面をいくら眺めても現れない。ポリシー配布後に実際のプロファイルディレクトリを標本検査する手順がなければ、組織は有効にしたことだけを知り、消えたかどうかは知らないまま運用することになる。
見通しは楽観と悲観に分かれる。楽観的に見れば、今回も報道が広がったので修正される可能性は高い。悲観的に見れば、6年ぶりに同じ欠陥が戻ってきたということは、修正が回帰テストとして固定されなかったという意味だ。現実的なシナリオはこの二つの組み合わせである。今回の件は直り、数年後に似たものがまた現れる。修正は個別の欠陥に入り、構造はそのままだからだ。
結論
この件で最も重要な一文は、発見者本人が書いたものである。彼は陰謀論ではなくハンロンの剃刀を選び、同時にこの会社には無能という言い訳も許されないと書いた。二つの文は矛盾しない。意図を問う代わりに結果の責任を問う方法である。
ブラウザはユーザーに代わってウェブと交渉する代理人だ。その代理人が特定サイトの所有者と同じ会社であるとき、利益相反は例外的な事件ではなく常時の条件になる。常時の条件を個別のバグ修正で管理することには限界がある。必要なのは「今回は直した」ではなく「次も検出される」を保証する回帰検査であり、それが公開されないのなら、せめて外部から再現可能な手順だけでも残らなければならない。
あなたが使うブラウザで同じ手順を踏めば、何が残るだろうか。設定を有効にし、サインインせず、検索を一度して、ウィンドウを閉じた後にプロファイルフォルダを開いてみてほしい。確認していない設定は、有効になっているという陳述にすぎず、消えたという証拠ではない。
出典: