Summary

  • 10月27日付の個人草案は、クライアントがサーバーの観測記録を保管し、後の接続で返す用例を追加した。
  • 記録は発行元の認証済みIDと結び付ける。ユーザーがCookieを消す際に保存統計も捨てるという従来の推奨は、別のキャッシュまで届く削除経路を必要とする。

サーバーが覚えておきたいことを、利用者の端末が代わりに覚える。QUICの輻輳データ交換に関する新稿は、その仕組みに具体的な用例を加えた。サーバーは過去のネットワーク観測を端末に渡し、次の接続で返してもらう。各クライアントの測定履歴を丸ごと自分で保持する負担を減らせる。

新しい付録B.1では、クライアントが記録を発行元サーバーの認証済みIDと接続先エンドポイントに関連付ける。別のサーバーが過去データを受け取れると宣言しても、前のサーバーの記録を渡してはならない。HTTPSのオリジンにIPアドレスとポートを組み合わせる範囲が例示される。IPだけでは、記録を発行したサーバーの身元を確認できない。必要な関連を確立できなければ、クライアントは記録の返送を省く。

多くのサービスを訪れる端末にとって、これは保管庫の宛名確認になる。アドレスはパケットの行き先を示せても、保存した書類の持ち主を単独で示せるわけではない。宛先を確かめる判断は、記録を送信する前に端末側が行う。

提案には三つの信号がある。CONSUMEは現在の接続で統計を使いたいという意思、CACHEは受け取った統計を後で返す可能性を含む意思、CONSIDERは以前自分が出した統計を受け取りたいという意思を表す。既定値はゼロだ。動画の画質選択など現在の用途には、付録の例のようにCONSUMEを使い、将来の保存と返送を約束しない選択もある。

安全性の節は追跡に使われる可能性を認め、QUICに既にあるアドレス検証トークンと能力を比較する。統計はクライアントが読めるため、内容を調べたり、理解できない値の返送を拒んだりできる。ユーザーがCookieなどを消す際には、保存統計も破棄することを推奨する。この削除の記述は前版にもあった。今回の例が明確にしたのは、端末が何を預かり、誰へ返すかである。

端点同士の信号が決まっても、削除操作の実装は残る。設定画面のボタンと伝送ライブラリの保存領域が別々なら、そこをつなぐ必要がある。利用者が知っている操作を、利用者が知らない引き出しまで届かせる仕事だ。

Datatrackerでの位置付けは個人のInternet-Draftで、10月27日の告知が新版を案内している。IETFの承認はない。特定のブラウザー版で削除が成功したという試験結果は資料にない。その結果が、既知の操作と新しい保存場所がつながった証拠になる。