Chrome がまた Google だけ site data を消さない — 152 系の除外挙動

Chrome が「閉じたら消す」設定から Google だけ除外していた

Chrome 152.0.7977.83 は、「すべてのウィンドウを閉じたときに、サイトがデバイスに保存したデータを削除する」設定を有効にしても、Google 系ドメインの site data だけを消さずに残します。他のサイトは設定どおり消えるのに、www.google.com のデータだけが例外扱いになる、という挙動です。

報告したのは macOS ツールを長く作っている Jeff Johnson さんで、lapcatsoftware の記事に再現手順が載っています。設定の場所は chrome://settings/content/siteData の「すべてのウィンドウを閉じたときにデータを削除する」トグルです。ここを ON にしてブラウザを閉じれば、普通は次に開いたとき site data はゼロになっているはずでした。

私も最初は「サインインしているからでしょう」と思って読み始めました。ところが記事の前提を読むと、その線は冒頭で潰されています。

再現手順 — 未サインイン・DuckDuckGo 既定でも 1.2MB 残る

この挙動は、Chrome にサインインしていなくても、既定の検索エンジンを Google 以外にしていても再現します。つまり「Google アカウントに紐づいた同期」では説明がつきません。

Johnson さんの条件は徹底しています。既定検索エンジンは DuckDuckGo、Chrome へのサインインは無効、chrome://settings/content/all を開いた時点で site data はゼロ。そこで一度だけ Google 検索を実行し、Chrome を完全に終了します。再起動して同じ画面を見ると、www.google.com の site data が約 1.2MB 残っている。中身は cookie・local storage・session storage です。他のドメインは一切残っていないため、「Google だけが on-close 削除の対象外になっている」と言い切れる、という筋道でした。

この 1.2MB という実測値が地味に効きます。「気のせいでは」と言わせないための数字で、再現条件と数値がそろっているぶん、反論しづらい報告になっています。私が同じことを社内で報告するなら、まさにこの粒度で書きたい。

なぜ Google だけ残るのか — storage partitioning とは別の話

先に切り分けておくと、これは Chrome 115 以降の storage partitioning（サードパーティ文脈のストレージをトップレベルサイトごとに分離する仕組み）とは別の問題です。パーティショニングは「どこに保存するか」の話で、今回は「閉じたときに消すか」の話だからです。

storage partitioning は、Chrome の解説によれば、cookie や localStorage を「同一オリジン かつ 同一トップレベルサイト」でキー付けして、埋め込みコンテンツによる横断トラッキングを防ぐ仕組みです。これはこれで前進なのですが、今回のバグはそのレイヤーの外側にあります。on-close の削除処理が、対象ドメインの集合から Google 系だけをスキップしている、という格好です。実装をこちらで確認したわけではないので断定はしませんが、挙動としては「削除ループの除外リストに Google が入っている」ように見えます。

意図的な優遇なのか、単なる実装ミスなのか。ここは慎重に扱うべきところです。

2020 年にも同じことがあった

同じ現象は 2020 年にも報告され、そのときは Google が修正しています。今回は「再発」だという点が、単発のバグより重く受け止められている理由です。

Johnson さん自身は Hanlon's razor（「悪意で説明できることに、まず無能を疑え」という格言）を引いて、意図的な優遇と決めつけるのは避けています。私もこの姿勢に賛成です。除外リストの再混入やテストの抜けで同じ穴が開くことは、コードを書く人間なら想像がつきます。とはいえ「よりによって Google だけ」「6 年ぶりの再発」という組み合わせは、QA とユニットテストで防げたはずのもので、そこは Google の宿題でしょう。

余談ですが、除外リスト系のバグは、追加した本人が半年後に理由を忘れるのが定番です。私も昔、自分で書いた feature flag の分岐を「これ何のためだっけ」と眺めて夜を溶かしたことがあります。除外の一行は、書いた瞬間だけ意味が明確で、あとは負債になりやすい。

運用者・プライバシー観点の自衛策

現実的な自衛策は、「Chrome の on-close 削除だけに頼らない」ことです。設定が期待どおり動かない可能性がある以上、消えたことを前提に運用してはいけません。

具体的には、いくつかを組み合わせます。まず、機微なブラウジングは通常プロファイルではなくゲストモードやシークレットウィンドウで行う。これらはウィンドウを閉じれば site data ごと破棄されるので、on-close トグルの実装に依存しません。次に、検索エンジンを変えるだけでは足りない点に注意します。私は普段の検索を DuckDuckGo に寄せていますが、Johnson さんの条件が示すとおり、Chrome で一度でも Google を開けば site data は残ります。既定検索の変更は入口を減らすだけで、削除の保証にはならない、というのが今回の教訓です。

運用でチェックするなら、chrome://settings/content/all を定期的に開いて、閉じたはずのドメインが残っていないかを目視する。地味ですが、設定を信じ込むより確実です。企業で管理しているなら、ポリシーで cookie の一括削除を強制する（ClearBrowsingDataOnExitList などの enterprise policy）方が、UI トグルより挙動が読めます。トグル 1 個の実装より、下のレイヤーで保証を取りにいくのが定石です。

まとめ

Chrome 152 系で、on-close の site data 削除から Google ドメインだけが外れている。2020 年に一度直った穴が再発した形で、サインインの有無や既定検索エンジンとは無関係に、Google 検索を一度でも開けば約 1.2MB が残ります。

意図か事故かの断定は避けますが、運用者としての結論は変わりません。UI トグル 1 個の挙動を信頼の土台にしないこと。消えていることを前提にせず、ゲスト / シークレットや enterprise policy のように、より下のレイヤーで保証を取りにいく。設定画面の文言と実際の挙動がずれることはある、というのを久しぶりに思い出させてくれた一件でした。