Chromeのサイトデータ管理をめぐって、Googleのサイトだけが設定どおりに消えない問題が再び見つかった。しかも今回は、以前いったん直ったはずの話が、別の形で戻ってきたというのが厄介だ。ブラウザのプライバシー設定は、ユーザーが自分の履歴やCookieをどう扱うかを決める土台なので、こうした挙動のズレは見過ごしにくい。この記事では、何が起きたのかを整理したうえで、これをどう受け止めるべきかを考えたい。
記事を書いたJeff Johnson氏は、6年前に「Chrome exempts Google sites from user site data settings」という投稿を公開し、ChromeがGoogle所有のサイトだけを、ユーザーの「自動でサイトデータを削除する」設定から除外していたと報告した。彼によれば、そのときの問題はGoogleに届き、最終的には修正されたという。
今回彼が再び書いたのは、Chromeで似た現象を確認したからだ。Johnson氏はこの問題を2台のMacで再現できたとしており、使ったChromeのバージョンは 152.0.7977.83 だった。検証のため、Chromeのデフォルト検索エンジンはGoogleではなくDuckDuckGoに変更している。こうすることで、検索設定そのものが原因ではないと確認したかったからだ。
Chromeの on-device site data settings、つまり chrome://settings/content/siteData を見ると、デフォルトの動作は「ブラウザを閉じたときに、サイトが端末に保存したデータを削除する」になっていた。さらに彼はChromeにサインインしておらず、Chromeへのサインインも許可していない。別の確認画面 chrome://settings/content/all でも、その時点ではサイトデータは保存されていない状態だった。
ところが、その状態でGoogle検索を1回実行し、Chromeの唯一のウィンドウを閉じると、chrome://settings/content/all に google.com のサイトデータが現れた。しかもこれは、Chromeを終了して再起動しても残り続けたという。いったんGoogleのサイトデータを削除して、同じ手順を繰り返しても、同じことが起きた。Johnson氏が見る限り、Chromeが例外扱いしているのは www.google.com だけだった。
Chromeの保存先フォルダ ~/Library/Application Support/Google/Chrome/Default をのぞくと、残っていたデータは Cookies、Local Storage、Session Storage だったという。つまり、ただの表示上の残りではなく、実体のある site data が保存されていたわけだ。
彼は、この問題がいつ入り込んだのかは分からないと書いている。普段の既定ブラウザはSafariで、Chromeは常用していない。ただし、テストのためにChromeやFirefoxを頻繁に使っているという。そして今回の件について、意図的な悪意を疑うよりは、まずはHanlon’s razorで考えるのが自然だろうとしつつも、Googleの規模と収益を考えれば、こんな不具合は「不注意でした」では済ませにくい、とかなり強い口調で批判している。彼は、品質保証を改善してこの種の不具合を防ぐべきだし、単体テストのような仕組みも必要ではないかと述べた。
最後には、政府にはGoogle Searchの独占を素早く分割してほしいとも書いている。さらに、未ログイン時のGoogle検索結果が、昔のようなサイトURLの羅列ではなく、www.google.com/goto?url= という形の見えにくいリンクになってしまっている点にも不満を示していた。
この件が気になるのは、単に「Chromeにバグがあった」という話では終わらないからだと思う。ユーザーが「閉じたら消える」と明示的に選んだデータが、特定のドメインだけ残る。しかもその例外がGoogle検索を使った瞬間に出るとなると、どうしても「ブラウザが自分の設定をどこまで本気で守っているのか」という話になる。設定画面は安心感を与えるが、実際の挙動がそれと一致しなければ、プライバシー機能そのものの信頼が崩れる。
興味深いのは、Johnson氏が以前の件で「Google所有サイトだけが例外になっていた」と書いている点だ。今回も見え方はほぼ同じで、www.google.com が残る。もちろん、これだけで意図的な扱いだと断定はできない。実装のどこかで、Googleの各種機能やログイン周り、検索の補助処理が絡んでいるのかもしれない。ただ、ユーザーから見れば理由は重要ではない。消えるはずのものが消えなかった、その一点が問題になる。ブラウザは細かな仕様を知る人だけの道具ではないので、挙動の一貫性はかなり重い。
この記事で地味に嫌な感じがするのは、再現条件が派手ではないことだ。特別な拡張機能も、サインイン状態も、複雑な操作も要らない。既定検索をDuckDuckGoに変えていても、Google検索を1回行うだけで site data が残る。こういう不具合は、ユーザーが原因を特定しにくい。設定は正しい。ウィンドウも閉じた。ブラウザも再起動した。それでも残る。だからこそ、発見されるまでに時間がかかることもあるし、見つかった後でも「自分の環境だけでは」と片づけられやすい。
ここから見えるのは、プライバシー設定が「あるかないか」ではなく、「どこまで例外なく効くか」が大事だということだ。CookieやLocal Storage、Session Storageは、それぞれ使いみちが違うが、まとめて site data として消えることに意味がある。ユーザーは細かい保存種別まで管理したいわけではなく、閉じたら残したくないからそういう設定を選ぶ。そこをブラウザ側が勝手に崩すと、設定の意味が薄くなる。まして、対象が世界最大級のサービスの一つであるGoogleなら、なおさら神経質に見られるのは当然だと思う。
Jeff Johnson氏は陰謀論に寄りかかるより、まずは不注意として見るべきだと言っている。私はこの姿勢自体は妥当だと思う。巨大企業の製品では、複雑な条件が重なって、開発者も気づきにくいまま変な例外が入ることはある。だが、そこで終わらせてはいけないのも事実だ。Googleほどの規模と収益があるなら、「起きてもおかしくない」で済ませず、そもそも起きないように検証を強化する責任がある。
ここで効いてくるのは、単体テストや回帰テストの発想だ。ユーザーのサイトデータ削除設定が、特定ドメインで破られていないか。ブラウザを終了して再起動しても残留しないか。こうした確認は、手作業の見落としだけに頼ると抜けやすい。Chromeは世界中で使われるブラウザだから、1つの不具合が「一部のユーザーの不便」ではなく「設定への不信」に直結する。品質管理の甘さが、製品の評価を越えて、会社そのものへの印象まで悪くする。
記事の最後にあるGoogle Search結果への不満も、単なるついで話ではないと思う。未ログイン時の検索結果が、サイトのURLではなく www.google.com/goto?url= 形式の見えにくいリンクになるという指摘は、検索体験の透明性に関わる。ユーザーはリンク先を見て判断したいのに、途中にGoogleのラッパーが入ることで、どこへ飛ぶのかが分かりにくくなる。Chromeの site data の件と合わせると、Googleはユーザーの見え方や制御感を少しずつ削っているようにも映る。
もちろん、これらを全部ひとつの意図で結びつけるのは早計だ。だが、少なくとも結果としては、ChromeでもGoogle Searchでも、ユーザーが期待する「自分で決めた設定」「自分で見て確認できる情報」が弱くなっている。そこがこの話の不気味さだと思う。個別の不具合報告に見えて、実は製品全体の信頼の問題に近い。ブラウザと検索は、毎日触れる道具だからこそ、少しのズレが大きく見える。今回の報告は、そのズレを見逃すべきではないと突きつけている。
参考: Chrome again exempts Google from user site data settings
