Cookie Layeringの動向及び関連仕様

HTTP cookie internet-draft

2022年頃より『Cookie Layering』という議論があります。これは、Cookieに関する仕様を再整理し、ブラウザレイヤで必要な仕様拡張をしやすくするという議論です。

例えば、3rd Party CookieやCHIPS(partitioned cookie)の仕組みづくりをするうえで、RFC 6265 (および、改定作業中の6265bis)を土台にするには苦痛があるという意見もブラウザベンダーから出ています。

Cookie Layeringに向けての構想としては、2022年時点のW3Cでのスライドがわかりやすいと思います。

(TPAC Cookies Breakout Session - Google スライド)

RFC側は

Fetch、HTML(document.cookie)、Cookie Store API、Service Worker などのブラウザ固有の仕様はそれらのRFCを参照するようにするというものです。

このように、HTTPの仕様としてのCookieとWebプラットフォームとしてのCookieの扱いを整理します

現在の仕様策定状況

現在 Cookie Layering の実現のために提出されている仕様変更は以下のものが提案されています。

IETF側に出されているDraftでは、各処理がよりアルゴリズム的に書かれているのが印象的です。“Cookie Store” Conceptなど、まだまだこれから変更がありそうな感じもします。

また、各標準化団体の直近の議論としては

今後

引き続き議論が進められることでしょう。IETFでもこの取り組みについては前向き進んでいきそう。

TPACのスライドを見るに、Cookie Store周りの整理をしながら、『HTML』『Cookie Store AP』『3PC Blocking 』などの仕様側も合わせて変更案の作成を進めていくようです。

(https://www.w3.org/2024/Talks/TPAC/breakouts/future-of-cookies.pdf)

QUICでマルチキャスト通信を行うFlexicast QUICの提案仕様

QUIC 雑 internet-draft

この記事は『QUIC Advent Calendar 2024』 12/2の記事です。

インターネットで動画像の大規模配信が行われるようになって、トラフィックの増大が課題となっています。

そのような中で、QUICでマルチキャスト配信を行う議論は定期的に話題になります。マルチキャスト配信では、ルータ上で複製され必要な受信者に配送されるため、総トラフィック量を抑えることができます。

以前もマルチキャストQUICの提案仕様を紹介しました
asnokaze.hatenablog.com

今回は、Flexicast QUICという別の提案仕様が提出されているため簡単に紹介します

Flexicast QUIC

Flexicast QUICは『Flexicast QUIC: combining unicast and multicast in a single QUIC connection』としてIETFに提出されています。

アイディアとしては、QUICでマルチキャスト通信を行うというものですが、MultiPath-QUICをベースにしている点が新しいところです。

　
(引用: IETF 121スライド)

Flexicast QUICでは、各受信者とコネクションを張りながら別PATHとしてマルチキャスト通信を行います。このとき、マルチキャスト通信では共通の鍵を使えるようにしています。

通信の流れ

Flexicast QUICは以下の通信フローで、マルチキャスト通信の受信が行われる。
（なおIPレイヤの部分については、この仕様ではスコープ外である。つまり、マルチキャスト受信は行えるものとしてQUICレイヤが設計されている）


  • 通常のQUICハンドシェイクを行う。このときトランスポートパラメータとしてflexicast_supportを送信することで、本仕様のサポートを示す
  • サーバからFC_ANNOUNCEを送信し、マルチキャストの受信に必要なSource IP、Group IP、UDP Portなどを通知する
  • 受信者は、FC_STATE(JOIN)を送信し、マルチキャストフローの受信をサーバに通知する
  • サーバは、FC_KEYでマルチキャストフローを復号するためのマスターシークレットを送信する。
  • 受信者は、FC_STATE(LISTEN)で受信状態に入る

なお、再送制御などは、最初に確立したパスで補完することになる。

マルチキャストを受け取れない場合

Flexicast QUICではマルチキャストで送信数データは共通の鍵で暗号化する。仮に受信者がマルチキャストを受信できなかったとしても、同一のパケットをそのまま複数名に投げることでサーバ側の負荷を低減することが出来る。

ビットレート制限をQUIC通信者に通知するSCONEの仕組み

QUIC internet-draft

特定のネットワーク環境においては、通信レートが制限される環境があります。この制限は通信してる両者には通知されることなく行われるため、レート推定または輻輳制御アルゴリズムで校了することができません。

この問題に対して、IETFでは『Standard Communication with Network Elements (scone)』WGが設立されました。UDPのフローに対して、ネットワーク上の要素からビットレート制限について通知する仕組みを検討しています。QUICへの適応を最初のとりくみとしています。

今月行われたIETF 121で初めてWGミーティングが行われました。

現在は以下のように幾つかの提案仕様がだされており、まだアイディアをもんでる最中になります

TRAINプロトコル

具体例を見るとイメージが湧くと思いますので、まだアイディアのひとつではありますが、TRAINプロトコルの仕組みを見ておきます。

TRAINを使うことに同意したQUIC通信者は、UDPパケットにTRAINを付けてQUICのデータを送信します。

このTRAIN部分は以下のデータを持ちます。RFC 8999 QUIC INVARIANTSと同じ形式をしています。この『Rate Signal』に転送レート情報が組み込まれます(詳細はこれから標準化)。

DKIM次世代バージョン、DKIM2の標準化動向メモ

internet-draft 雑

『DKIM2 Why DKIM needs replacing, and what a replacement would look like』という提案がIETFに提出されている。Author陣はFastmail, Yahoo, Google となっている。

この提案自体は、これから議論を行うためのたたき台という感じだが簡単に目を通しておく。
なお、分かりやすさのため、現行のDKIMをDKIM1と呼ぶ。

概要

まずDKIM2の議論が出た背景として、DKIM1の課題については以下の点が上げられている

  • MLなどにおいて、中間者がメール(ヘッダやボディ)を変更した場合に署名検証が正しく行えない
  • 悪意のある人物が、不正な電子メールをリプレイすることで署名者のレピュテーションを損なうことが出来る
  • フィードバックループといった、complaint(苦情)をフィードバックする正式な仕様がない


そこでDKIM2では既存の DKIM1 標準とほぼ同じ方法で、送信者によって DKIM2 署名されますが
課題を解決するために、以下の機能が掲げられている。

  • メッセージが到達するまでの経路を検証する。各ホップで変更点をヘッダに追記していく
  • メッセージが次にどこに送信されるか、署名を追加しながら（自身の署名の保護下で）宣言する
  • 制御メッセージ（バウンス、不正使用報告、配信通知を含む）を、妥当な時間で前のホップに返す
互換性について

DKIM2 で署名された電子メールは DKIM1 で署名することもできるため、DKIM2 に対応していないシステムでも現在と同じように動作できます。

標準化動向

今月行われた IETF 121 でDKIM2の発表が行われました(スライドURL)。会合後に投稿されたメール(Link)からにも、好意的な反応があったことが綴られています。

メーリングリストでは活発な議論が引き続き行われていますが、DKIM2の標準化に向けて DKIM WGのChartaring作業が行われています。
datatracker.ietf.org

まだ議論は始まったばかりですが、DKIM2の標準化に向けて前向きに進んでいる感じがします

技術書典17(11/03)にサークル参加します。プロトコル標準化『ゆるIETF』本を頒布予定

宣伝 雑

宣伝です

技術書典17 11/03 (日)にて、ASnoKaze 個人サークル(か06)として プロトコル標準化本『ゆるIETF』を頒布します。

techbookfest.org

普段ブログでの技術的なトピックは、主観的な意見は書かず、事実に基づいて書くことを心がけていました。ただ『ゆるIETF』本では、ゆるく標準化の現場について文章を一回まとめたいなと思い、だらだらっと筆を取ってみました。

内容は、標準化としてミーティングの様子や、技術トピックも小ネタ的な面白いなと思ったものを中心に書いています。
詳細の目次は上記リンクで参照できますので、ご笑覧いただければとおもいます。

もし来場される方がおりましたら、お会いできる事を楽しみにしております。

（期限ドリブンで最後の方、やや散文になってしまいましたが... ご容赦くださいorz）

eBPF 命令セットアーキテクチャ(ISA)がRFC 9669になった

雑 internet-draft

『RFC 9669 BPF Instruction Set Architecture (ISA)』として、命令セットアーキテクチャ(ISA)がRFCになりました。eBPF (which is no longer an acronym for anything) と書かれているのが印象的です。

このRFC発行作業は、2023年6月に結成された IETF の bpf WGで行われました。
eBPF Foudationからの相談を元に、Linux Kernelのソースツリーに書かれていたbpf関連ドキュメントを、RFCとして発行していくという形になっています。


(2023年12月 IETF117 bpf WG スライドより)

今後

bpf WGは引き続き活動を続けています。

IETF bpf WGの憲章を読むと、作業スコープとして次のドキュメント発行作業をスコープとしてあげています。

  • the BPF instruction set architecture (ISA) that defines the instructions and low-level virtual machine for BPF programs,
  • verifier expectations and building blocks for allowing safe execution of untrusted BPF programs,
  • the BPF Type Format (BTF) that defines debug information and introspection capabilities for BPF programs,
  • one or more documents that recommend conventions and guidelines for producing portable BPF program binaries,
  • cross-platform map types allowing native data structure access from BPF programs,
  • cross-platform helper functions, e.g., for manipulation of maps,
  • cross-platform BPF program types that define the higher level execution environment for BPF programs, andan architecture and framework document.

IETF120のスライドを見ると、その中でも、次の取組の候補として次のものが上げられてそうです

  • verifier expectations
  • BTF
  • Platform-specific ABI (psABI)
  • ELF profile for BPF

来週行われる IETF 121 でまた動きがあるかなと思います


## (2024/11/05追記)
メーリングリストにこの記事に書いたような内容が詳しく説明されています

mailarchive.ietf.org

  • なぜIETFで標準化しているのか
  • 標準化のプロセス
  • 今後について

WebサイトのAI学習利用を拒否するrobots.txt拡張の議論

雑 internet-draft

WebページがAIにより学習されないように、拒否できるようにしようという議論があります。

具体的には、ai.txtやrobots.txtなどを使って拒否する提案が出ています。

ai.txt (spawing)

https://spawning.ai/ai-txt で 定義されている。
ai.txtの形で配置する

例: 

User-Agent: *
Disallow: *.txt
Disallow: *.pdf
Disallow: *.doc
Disallow: *.docx
Disallow: *.odt
(略)

robots.txt のAI向け拡張 (Microsoft)

Microsoftの方らが『Robots Exclusion Protocol Extension to manage AI content use』という提案をIETFに提出している

という目的ベースで許可・拒否が出来る

  • AllowAITraining
  • DisallowAITraining

また、meta タグでの指定も規定している

<meta name="robots" content="DisallowAITraining">
<meta name="examplebot" content="AllowAITraining">

robots.txt の目的指定拡張 (Google)

Googleの方が『Robots Exclusion Protocol User Agent Purpose Extension』という提案をIETFに提出している。

User-Agent-Purposeとして目的毎に許可・拒否できる

# robots.txt with purpose
# FooBot and all bots that are crawling for EXAMPLE-PURPOSE-1 are disallowed.
User-Agent: FooBot
User-Agent-Purpose: EXAMPLE-PURPOSE-1
Disallow: /
# EXAMPLE-PURPOSE-2 crawlers are allowed.
User-Agent-Purpose: EXAMPLE-PURPOSE-2

ベンダー定義

もちろん、各ベンダーが定義している UA を指定して拒否することも出来る。
たとえば、OpenAIは User-Agentを公開しており拒否できるようにしている。
platform.openai.com

Appleも同様にUser-Agentを記載している他、"Applebot-Extended"というUAで生成AIについて言及しています

Applebot-Extended を許可すると、時間の経過とともに Apple の生成 AI モデルの機能と品質が向上します。

support.apple.com

おまけ: IETF動向

IETFにrobots.txtの拡張案が提出されているように、なにかしらの仕組みづくりについて議論しています (ML)。

CloudflareやGihutbやIBMからもポジションペーパーも出されている。
IAB Workshop on AI-CONTROL (aicontrolws)


来月行われる IETF 121 でも、サイドミーティングという形でオフライン議論が行われる予定です。
https://mailarchive.ietf.org/arch/msg/ai-control/LNFeTDhm5GbxbbroZXSTR3RWTf8/