Summary

  • W3Cの2015年の初公開草案は、サイトの情報がブラウザー内の複数の場所に残り、ページのスクリプトだけでは片付けきれない問題を扱った。
  • 2017年の作業草案はClear-Site-Data応答ヘッダーで、cache、cookies、storage、executionContextsを選んで消す仕組みを記した。*は既知の項目をまとめて指定する。

画面が「ログアウトしました」と告げても、ブラウザーの棚卸しは終わっていない。サーバー上のセッションが切れたあと、端末には以前の画像が残り、保存領域にはオフライン用のデータが残る。別のタブではページが動き続ける。小さな退出ボタンに、建物全体の戸締まりを期待していた。

2015年8月のW3C初公開草案は、その戸締まりの難しさを説明した。JavaScriptで消せる情報はある。しかしHttpOnlyのCookieには触れない。それはスクリプトからCookieを守るための仕組みだからだ。HTTP応答を使って失効させるには、サイトが発行済みのCookieを把握し、それぞれに適切な指示を送る必要がある。キャッシュやローカルの保存領域には、また別の掃除道具がいる。

草案は掃除を依頼する場所を変えた。サイトはHTTP応答で消したいものを指定し、引き出しを持つブラウザーが処理する。いつ片付けたいかはサイトが知っている。どこに何をしまったかはブラウザーが知っている。鍵の持ち主に頼むほうが話が早い。

2017年11月の作業草案では、依頼書に名前が付いた。Clear-Site-Dataの値には引用符付きで"cookies"、"storage"、"cache"、"executionContexts"を並べられる。"*"はそのヘッダーが扱うすべての種類を指し、後から増える種類も含む。短い一行だが、ただの「全部よろしく」よりずっと具体的だ。

普通のログアウトならCookieと保存領域を消す依頼が考えられる。ログインの手掛かりと端末に残したデータを一緒に片付ける。もっと深刻な場面も草案にある。サイトが侵害を受け、利用者のブラウザーに悪意ある状態が残った恐れがあるとき、キャッシュや動いている画面まで対象にする「緊急停止」の例だ。同じヘッダーでも、指定する引き出しで掃除の規模が変わる。

引き出しの区画線はそろっていない。保存領域は応答のオリジンに結び付く。Cookieはサブドメインをまたぐため、草案の手順は登録ドメイン全体を扱う。ネットワークキャッシュの項目はホストで選ぶ。処理の起点になる応答にも、安全で認証された接続という条件を置く。ブラウザーはサイトの依頼を受け取るが、そのサイトに他人の棚を開ける鍵を渡すわけではない。

"executionContexts"は掃除中にまだ働いている人々のことだ。Cookieを消した直後でも、開いたタブやワーカーが古い状態で動き続ければ、片付けたデータをまた書き戻しかねない。2017年草案は対象の実行環境を準備し、指定されたデータを消し、必要なページを再読み込みする流れを記した。床を磨いたそばから靴跡を付ける人を、先に廊下へ案内する。

大掃除には費用がかかる。キャッシュを消せば次の訪問で再取得が増える。Cookieを消せば同じ登録ドメインの別のサービスからも退出する。保存領域を消せばオフライン作業の材料が失われる。項目ごとに依頼できる意味はそこにある。通常の退出に必要な範囲と、事故後の全面清掃は同じではない。

W3Cの公開履歴には2015年、2016年、2017年の作業草案が並ぶ。ブラウザーが一時的な閲覧窓から、記憶を抱える作業場へ変わった時代の記録だ。ログアウトの一押しにも、片付ける部屋の見取り図が要るようになった。