ChromeのPartition Network Stateについて

Chrome 89で「Partition Network State」という機能の導入が検討されています。

chromestatus.com

Client-Side Storage Partitioning 」のいち部であり、w3cのPrivacy CGで議論されています。

これは、DNSキャッシュやHTTP/2のセッションといったネットワーク状態を、クロスサイトで共有できなくする機能です。

情報は多くないようですが、眺めていきます。

背景

ブラウザ内全体でキャッシュ情報を共有していると、サイトAで読み込んだキャッシュを、サイトBを表示する際にも使用できます。

この時サイトBではそのリソースの読み込みスピードを計測することで、キャッシュしてたかそうでないかが分かってしまいます。(読み込み速度はonloadイベント等で取得)

例えば、https://a.example/js/hoge.js といったサイトAに固有なリソースがキャッシュされていれば、ユーザがAにアクセス済みということがわかります。その他にも、特定ページのみ表示される画像なども利用できるでしょう。

こういった問題は以前紹介した「Double-keyed HTTP cache」で対策されています。
Double-keyed HTTP cache に関するメモ - ASnoKaze blog

サイトAで読み込んだキャッシュは、サイトBでは利用できないようになっています。

「Double-keyed HTTP cache」はHTTPのキャッシュを共有しないという対策でしたが、「Partition Network State」はネットワーク状態のキャッシュ共有範囲を制限します。

Partition Network State

Partition Network Stateでは、Double-keyed HTTP cache と同様、top-level siteとiframe siteをキャッシュ共有範囲のキーとして使います。

そのため、クロスサイトではネットワーク状態が共有されません。現在、対象となるネットワーク状態の候補は下記が検討されています。

  • DNSキャッシュ
  • HTTP/1.xのソケット
  • HTTP/2とHTTP/3のセッション (WebSocketを含む)
  • TLSとHTTP/3のセッション再開(session resumption)情報
  • ALT-Svcの情報
  • PAC scriptsからのDNSルックアップ
  • Expect-CT の情報

その他下記についても、Partition Network Stateを尊重するためにさらなる説明(仕様)が必要と述べています

  • HTTP auth cache
  • Client certs
  • Clear-Site-Data header

パフォーマンス

cross-siteのiframe、top-level sitesでネットワーク情報が共有されなくなることによるパフォーマンス影響についても言及されています。

DNSキャッシュの利用率や、TLS/QUICセッション再開の可能性が減ります。また、ALT-Svcの情報も使えないのでHTTP/3で最初から接続できないかもしれません。

小規模な実験では、誤差レベルのパフォーマンス変化しか無いとのことです。改めて規模を大きくしたときの数値については公開するとのことです。