トラッキングに利用できない3rdパーティクッキー「CHIPS」の仕組み (partitioned属性)

3rd パーティクッキーの廃止計画が世間を賑わせています。一方で、3rdパーティクッキーには、トラッキング目的でないユースケースもあります。それらのために、3rdパーティクッキーの制限を緩和する「Cookies Having Independent Partitioned State (CHIPS)」という仕組みが検討されています。

この仕組みに則っていれば、制限のもと3rdパーティクッキーを使えるようになります。
もちろん、これはトラッキングが出来ないようになっています。

仕様: https://github.com/WICG/CHIPS
Chromeの実装計画: 「Intent to Prototype: Cookies Having Independent Partitioned State (CHIPS)」

ユースケースについては、仕様の中で述べられていますのでそちらを参照ください。

CHIPS以前の3rdパーティクッキー

CHIPSがどのようにCookiを制限するか説明する前に、今の3rdパーティクッキーについて軽く説明をします。

次の例では

• https://a.example , https://b.example が https://cookie.example を埋め込んでいます
• https://cookie.exampleはcookieを設定します

クッキーは払い出したドメイン(ホスト名)をキーにブラウザに保存されます。そのため、どのサイトにサブリソースと埋め込まれても共通してCookieが共有されます。ですので、ユーザのトラッキングに使用できました。

CHIPSの緩和

「Cookies Having Independent Partitioned State (CHIPS)」では、払い出したドメインだけでなく、トップレベルのサイトもキーにして保存領域が分割されます。

先の例と同じように、https://a.example と https://b.example に https://cookie.example を埋め込んでいます。https://cookie.exampleから払い出されたCookieは異なる領域に保存されます。そのため、クロスサイトでのトラッキングには使う事はできません。

CHIPSのオプトイン

CHIPSで定義されるように、Cookieを動作させるために、set-cookieする際にpartitioned属性を付与する必要があります。

Set-Cookie: __Host-SID=31d4d96e407aad42; SameSite=None; Secure; HttpOnly; Path=/; Partitioned;

その他にも以下の制約がある

• Cookie Prefixesで定義される __Hostプレフィックスがついている必要がある (Domain属性を上書き設定不可になる)
• SameSite属性はNoneが指定される必要がある
• Secure属性がついている必要がある
• HttpOnly属性がついている必要がある

将来的には、3rdパーティリクエストするさいPartitioned属性のついたCookieのみが送信され、Partitionedの無いCookieは送信されないようになるものと思われます。

標準化に関して

現在、W3CのWICGを中心に議論が進められています。IETFのHTTP WGにもドキュメントの状況は共有されていますが(URL)、具体的な提案仕様はまだ提出されていません。

タイムゾーンを含むタイムスタンプ文字列表現の標準化

「Date and Time on the Internet: Timestamps with additional information」という提案仕様がIETFで提出されているので簡単に紹介する。

この仕様では、下記のようなタイムスタンプの文字列フォーマットの定義を行う

1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]

背景 TC39 Temporal

Temporalという時間を扱う新しいAPIが、TC39でStage 3となっている。
tc39.es

このAPIでは、タイムゾーンを含む文字列を生成できる。

const zonedDateTime = Temporal.ZonedDateTime.from({
  timeZone: 'America/Los_Angeles',
  year: 1995,
  month: 12,
  day: 7,
  hour: 3,
  minute: 24,
  second: 30,
  millisecond: 0,
  microsecond: 3,
  nanosecond: 500
}); // => 1995-12-07T03:24:30.0000035-08:00[America/Los_Angeles]

この文字列表現はTemporalの仕様では次のように示している。

このように、時刻のフォーマットしては RFC3339 を利用しているが、タイムゾーンはTime Zone Extensionとして定義している。

この新しいTime Zone ExtensionをちゃんとRFCとして定義しようというのが「Date and Time on the Internet: Timestamps with additional information」である。IETFへの提案は、Temporalの標準化を行っているUjjwal Sharma氏によって行われている。 (IETF110の発表スライドpdf)。

提案仕様

「Date and Time on the Internet: Timestamps with additional information」の提案仕様では、RFC3339 の定義に加えtime-zone, suffix-tag を付加できるようになっている。

フォーマット定義

time-zone-char = ALPHA / "." / "_"
time-zone-part = time-zone-char *13(time-zone-char / DIGIT / "-" / "+") ; but not "." or ".."
time-zone-name = time-zone-part *("/" time-zone-part)
time-zone      = "[" time-zone-name "]"

namespace      = 1*alphanum
namespace-key  = 1*alphanum
suffix-key     = namespace ["-" namespace-key]

suffix-value   = 1*alphanum
suffix-values  = suffix-value *("-" suffix-value)
suffix-tag     = "[" suffix-key "=" suffix-values "]"
suffix         = [time-zone] *suffix-tag

date-time-ext  = date-time suffix

例

実際に使う例

1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]

任意のサフィックスタグもつけられる

1996-12-19T16:39:57-08:00[x-foo=bar][x-baz=bat]

WebでのIPマルチキャストの利用検討 (Multicast Community Group)

W3Cに新しく、Webでのマルチキャストの利用を検討する「Multicast Community Group」が立ち上がるので、そのCharterに目を通しておく。

w3c.github.io

ここまでの関連する動き

まずは、ココまでの動きを簡単に紹介する。

以前、紹介したように、インターネットのトラフィックは日に日に増えている。
その対策として、ブラウザでIPマルチキャストを受け取れるようにし、効率的なデータ配信をするという動きがある。

asnokaze.hatenablog.com

JavaScriptのAPIとしては、blink-devでも議論されている通り「Multicast Receive API」がある。
github.com

プロトコルとしてはIETFで、インターネット上でマルチキャストを配信するための仕組みが検討されている。

• DORMS (Discovery Of Restconf Metadata for Source-specific multicast)
• AMBI (Asymmetric Manifest Based Integrity)
• CBACC (Circuit Breaker Assisted Congestion Control)

最新の情報は、今年4月に発表されたスライド「Multicast for the Web(pdf)」を御覧ください。

Multicast Community Group

Multicast Community Groupは、IPマルチキャストを用いてWebの通信のスケーラブルな効率化を目指す。

ユースケースについて議論し、IPマルチキャスト通信におけるAPIを定義する。パラメータの交換やアプリケーションレイヤのネゴシエーションなどを可能にする。（ネットワーク、プロトコルレイヤはIETFで標準化）

Phase 1

「Multicast Receive API」を出発点にし、WebTransportをマルチキャスト受信可能に拡張する。

Phase 2

その他の配信用APIにマルチキャストを組み込む。例えば次のものなど

• HTML's "download" attribute
• Fetch
• WebRTC

おわりに

CharterのDraftは「Start Date: 2021-06-22」となっているので、本格的にはその日から動き出すのかなと思いつつ

個人的には結構面白そうなので、引き続き動向をウォッチしておきチア。

サーバ証明書の不正発行に対するSCT Auditing

2011年頃、ドメイン所持者が意図せぬ形で、認証局よりサーバ証明書がご発行される事件がありました。この対策として、Certificate Transparency (CT) という仕組みが導入されました。

CTの仕組み

CTの利用の流れは幾つかありますが、一例を示します。

• 1. 認証局が証明書を発行する際に第三者が運営するCTログサーバにプレ証明書を登録します。登録時に、登録の証左となるSigned Certificate Timestamp (SCT)が認証局に渡されます。
• 2. 認証局は、登録時に得られるSigned Certificate Timestamp (SCT)を証明書に付与して発行します。
• 3. ブラウザ(PC版Chrome)がWebサイトにアクセスする際、証明書にSCTがついてない場合は、エラー画面を表示します。

( https://no-sct.badssl.com/ )

ログサーバにあるドメインの証明書が登録されていることは誰でも確認することが出来ます。そのため、意図せぬ証明書が発行されていれば検知することが出来ます。

Chromiumが認識するCTログサーバは以下より確認出来ます。
github.com

SCT Auditing

SCTは、証明書がCTログサーバに登録されてる証左として扱われてました。つまり、SCTがついているサーバ証明書は、CTログサーバで必ず確認できるはずです。

しかし、CTログサーバが悪意を持って振る舞った場合、認証局にはSCTを払い出すが、登録情報を公開しないという事もできます。これでは、ドメイン所持者はCTログサーバを意図せぬ証明書が発行されているか確認できません。

そこで、ブラウザは、Webサーバを通して得られたSCTが本当にログサーバ上で公開されているか確認するというのが、Google Chromeで実装が進められているSCT Auditingです。この仕組では、疑わしいSCTをGoogleのサーバにレポートすることで実現されます

プライバシーの問題

SCT Auditing では SCTをブラウザからGoogleのサーバにアップロードするため、プライバシーの問題が発生します。つまり、ユーザがどのサーバと接続したのかが分かってしまいます。そこで、フェーズを2段階に分け、試しながらSCT Auditingを有効にしていく模様です。

• phase 1: SCT Auditingをオプトインしたユーザのみ有効
• phase 2: プライバシー保護を行い、その他のユーザも有効 (今の所デスクトップ版のみ)

現在、 phase 2の設計について議論が行われている段階です。
docs.google.com

phase 1

下記の通り、Opt in したユーザ

Webサイトの閲覧の安全性向上のためにGoogleのサーバに情報を送る Enhanced Safe Browsingを利用している場合に、SCT AuditingのレポートをGoogleのサーバに送るようになっています。

phase 2

オプトアウトしていない、より広いユーザでSCT Auditingを有効にし、CTの仕組みを強固にします。また、ユーザのプライバシーを保護する仕組みが入っています。

SCTリストサブセットの取得

ブラウザはサーバから得たSCTがGoogleに認識されているか、まずGoogleからSCTのリストのサブセットを取得します。SCTリストのサブセットの要求にはk匿名性クエリを用います。

SCTの対応するMerkleTreeLeafのハッシュ数バイトをGoogleサーバに送信します。Googleのサーバはマッチするハッシュのセットを返します (10000ドメイン以上のリストとなる)。

こうすることで、ブラウザは、該当のSCTをGoogleがすでに認識しているか確認できます。

SCTレポートの送信

上記のサブセットに該当のSCTがなく、Googleが該当のSCTを認識していな場合、SCTレポートを送信します。このレポートにはドメインやユーザの情報は含まれないようです。

レポートの送信には、ログサーバがSCTを公開するまでの遅延時間 (Maximum Merge Delay)待ったり、ネットワークエラーがあってもリトライするようになっています。

docs.google.com

さいごに

まだ議論の最中で、色々実証実験などを踏まえて細かいところは変わっていきそうです。

詳しい内容は先にも上げた、phase 1およびphase 2の資料を御覧ください

phase 1
docs.google.com

phase 2
docs.google.com

HTTPセマンティクス仕様の改訂版(RFC9110) まとめ

HTTPのGETといったメソッドやヘッダの意味を定義したHTTPセマンティクス仕様の改訂版である「HTTP Semantics」が標準化の大詰めを迎えている。(RFC9110となる予定)

既存の仕様から幾つか大事な変更が含まれているので簡単に紹介する。

目次

セマンティクス仕様の改訂作業

HTTPセマンティクス及び、HTTP/1.1の仕様の改定作業がIETFのHTTP WGで行われている。その背景について簡単に紹介する。

現在、HTTPセマンティクスはHTTP/1.1の仕様の中で定義されている。HTTP/1.1 は、RFC 7230 〜 7235で定義されているが、セマンティクスは主に「RFC 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content」に記述される。

この、RFC 7230 〜 7235の仕様を改訂し、HTTPセマンティクスと、HTTPメッセージの送信方法の定義を下記の通り分離するという事が行われている。

• HTTP Semantics
• HTTP/1.1
• HTTP Caching

こうすることで、HTTP/2(http2bis)やHTTP/3からはHTTP Semanticsの仕様を参照できるようになる。つまり、HTTP/2やHTTP/3はHTTPメッセージの送り方が異なるだけで、HTTPのセマンティクスとは変わらないというのが、仕様の参照関係的にもすっきりする。

ざっくり変更点

セマンティクスとフォーマットの分離以外にも、HTTP/2やHTTP/3に合わせた記述変更など、幾つか重要な変更点あるので紹介したい。

なお、HTTP/3は改訂される「HTTP Semantics」に準拠しているため、用語などを押さえておく必要がある

用語整理 (Field)

新しいセマンティクス仕様では、使い慣れたHTTPの用語の整理がされている。

普段、「HTTPヘッダ」と呼んでいる、キーとバリューからなるHTTPメッセージのメタデータは、「フィールド」と呼ぶことになった。コンテンツ(ボディ)を送った後に送信するフィールド（トレーラ）と区別し、「ヘッダフィールド」「トレーラフィールド」と呼び分けることになる。なお、ヘッダセクションに現れるフィールドのみを簡易的に"ヘッダ"と呼ぶことはできる。

ヘッダやトレーラを区別しない場合は、フィールドと呼ぶ必要がある。例えば、次の例は、ヘッダとトレーラ区別しないので、フィールドという用語を用いている。

• RFC 8941 Structured Field Values for HTTP

以下などを参照
qiita.com
github.com

用語整理 (body)

HTTPボディ、HTTPペイロードと呼ばれていたものは、セマンティクス上はコンテンツ(content)と呼ぶ。このコンテンツは各HTTPバージョンの定義に従って格納される。

このコンテンツは、HTTP/1.1ではHTTP/1.1ボディという形で送られる。

github.com

用語整理 (interim/final レスポンス)

ステータスコード1xx系をinterim responses (non-final response)と呼び、それ以外をfinal responseと呼ぶ

github.com

ステータスコードのレンジを明確化

ステータスコードとして取りうる範囲を、100~599と明示

github.com

ステータスコード418 unused

「418 I'm a teapot」はHyper Text Coffee Pot Control Protocol のステータスコードである。HTTPの仕様上は、418をunusedという形で予約した。

asnokaze.hatenablog.com

Rangeを指定したPUTリクエスト

すでに、再開可能なアップロードのために使用されているが、仕様上もPUTリクエストにRangeを許可した。
asnokaze.hatenablog.com

GET, HEAD, DELETEでコンテンツを含めるのを非推奨 (SHOULD NOT)

GET, HEAD, DELETEリクエストにコンテンツ(ボディ)を含めるのを非推奨とした (SHOULD NOT)。仕様上はそれらのコンテンツのセマンティクスを定義してないため、相互運用上問題になる可能性がある。

プロトコルのマイナーバージョンについて

HTTP/2やHTTP/3は、バージョンにマイナー番号を持たない。あえて記述する場合は、マイナーバージョンは0とすることになった。

更に詳しく知りたい場合

「Appendix B. Changes from previous RFCs」に各RFCからの変更点が記載されている。細かく知りたい場合はそちらを参照
www.ietf.org

おわりに

HTTP Cachingは、どなたかキャッシュ詳しい人が解説して貰いたいところ

BGP over QUICの提案仕様

「BGP Over QUIC (BoQ)」という提案仕様が出ている。まだ、議論の呼び水の段階で、提案仕様の細かい部分はとりえる選択肢が書かれている部分もある。。

なお、僕自身はBGPについて詳しいわけではないが、ざっと目を通す。

QUICを使うメリット

RFC9000 で定義されるQUICはUDP上で動作するトランスポートプロトコルであり、TCP+TLSのような通信の信頼性と暗号化機能を提供します。

QUICを使うアプリケーションプロトコルとしては、すでにRFC間近になっているHTTP/3の他に、DNSやSSHなどででの利用が検討されています。

QUICをトランスポートプロトコルとして使うことで多くのメリットが得られます

• TCP + TLSに比べ早いコネクション確立 (TLS1.3と同等のハンドシェイクを行う)
• IPアドレスが変わってもコネクションが切れない
• 通信管理単位であるストリームを活用する。ストリーム毎の信頼性となっており、パケロス時に回復を待たずに、後続のパケットをアプリケーションで処理できるようになっている
• 再送制御の表現力の向上
• トランスポートプロコル領域も含む暗号化、アンプ攻撃対策、
• その他いろいろ

詳しくは、古いですが、以前書いた記事などを参照してください

• QUICの話 (QUICプロトコルの簡単なまとめ)
• HTTP/3の解説を書いた (2020/06/01)

BGP over QUIC

「BGP Over QUIC」も上記のメリットを享受できます。QUICを利用するために、仕様では以下のことを定義してます。

• QUICストリームにどうマッピングするか
• 1-RTTハンドシェイク及び、0-RTTハンドシェイク時の BGP FSM (ステートマシン)の定義

QUICストリームにどうマッピングするか

トランスポートレイヤのヘッドラインブロッキングを避けるために、QUICのストリームを利用する。
通信をどう、QUICの双方向ストリームにマッピングするかは以下の3つが案として挙げられている。

• アドレスファミリごと
• VRFsごと
• プレフィックス毎

BGP FSM関連

BGPのセッション確立プロセスはBGP FSMで定義されます。トランスポートレイヤでコネクションの確立をしたあとに、BGPセッションが確立されます。

(wikimedia: File:BGP FSM.svg より)

この仕様では、BoQ FSMとして新しく定義してます。

BoQ FSMでは、QUIC 1-RTTハンドシェイクではTCPのものを継承します。クライアントからアプリケーションを最初に送信する0-RTTハンドシェイク用のために、新しいイベントを定義を追加します。

0-RTTハンドシェイクでは、クライアントはQUIC InitialパケットともにBGP Open Dataメッセージを送信し、BGP OpenSent 状態になります。それを受け取ったサーバーは QUIC Handshakeパケットを送信後に、BGP Open を送信し、ステータスを BGP OpenConfirmedに変更します。その後、クライアントもBGP OpenConfirmedになります。

このようにBoQ FSMで0-RTTを利用すると、BGP Connect とBGP Active がスキップされます。

その他

なお、BGP over QUICではUDPの179番ポートを使用します。ポート番号でアプリケーションプロトコルを区別するため、この仕様では、ALPN識別子は不要としています。

また、QUICではアプリケーションのエラーでコネクションを切る際に、エラーコードを通知します。そのため、BoQではエラーコードを、新しく定義しています。

• BOQ_NO_ERROR (0x00)
• BOQ_INTERNAL_ERROR (0x01)

感想

• QUICではTLSハンドシェイクを行うのでサーバ証明書が必須。そこを運用でどうするか。BGPSecと似たような感じ？（詳しくない
• BGPで、QUICのメリットがどれくらい嬉しいのか、実感がない
• ALPN識別子必須でないけど、一旦定義してもいいのかなとおもったり
• BGP FSM全然わからない...

WebTransport over HTTP/2 の方向性 (2021年5月の中間会議をうけて)

5月21日に行われた WebTransport WGの中間会議で、WebTransport over HTTP/2の方向性が見えてきたのでメモとして残しておく

WebTransportの動向

WebTransportと呼ばれる新しい双方向通信の仕組みが議論されています。

WebSocketの次世代版とも呼ばれており、HTTP/3上で動作します。現在、Chrome で実装が進められていたりします。

さて、このWebTransportの標準化は、IETFでプロトコルを、W3Cでインターフェースの仕様が議論されています。

W3C

• WebTransport

IETF

• WebTransport over HTTP/3
• WebTransport using HTTP/2

1月にあったIETF WebTransport WGの中間会議では、QUICとHTTP/3を使うもののうち、HTTP/3を使うWebTransport over HTTP/3の標準化に注力していくことが決まりました。
asnokaze.hatenablog.com

5月の中間会議

5月の中間会議では以下のトピックなどが発表されました

• W3C WebTransport WGのアップデート
• WebTransport over HTTP/3について
• 仕様のアップデート状況
• ChromeのOrigin Trials及びサポートスケジュール
• 既存Issueの議論
• WebTransport over HTTP/2の仕様説明
• フォールバック先についてのコンセンサス形成

WebTransport over HTTP/3についても、結構おもしろい議論がありました。しかし、やはりフォールバック先のプロトコルをどうするかの議論が気になる方も多いと思うのでピックアップして書きます。

フォールバック先のプロトコル

UDPがブロックされている環境において、フォールバック先としてTCPベースのWebTransportを検討する必要がありました。今回の会議では、その方向性について参加者の中でコンセンサスが取られました。

議長が投げかけた質問と、ミーティング参加者のコンセンサスは次のとおりです。質問は、前提から順番に合意していく形で進められていきます。

• 質問1: TCPベースのフォールバック先を用意すべきか => YES
• 質問2: それはHTTP/2上で動作するものか => YES
• 質問3: draft-kinnear-webtransport-http2 を採用するか => YES

ミーティング内では、フォールバック先として、以前本ブログでも紹介した仕様を出発点として採用するコンセンサスが得られました。もちろん、作業の出発点ですので、今後変更されることもあります。
asnokaze.hatenablog.com

引き続きメーリングリストで意見が募集されますが、特になにもなければこの方向で進むものと思われます。

資料

• スライドのリンク
• 議事録のリンク