2023-08-31

個人情報を共有しないように要求する Sec-GPC リクエストヘッダ

HTTP w3c

W3CのPrivacy Community Groupでは、Webのプライバシーについて取り組んでいます。

その取り組みとして「Global Privacy Control (GPC)」というドキュメントが書かれています。このドキュメントでは、ユーザが個人情報を共有しないように要求する Sec-GPC リクエストヘッダが定義されています。

多くのWebサイトでは個人情報の取り扱いについてオプトアウト方法を提供していますが、ユーザが個々にオプトアウトを行うよりか簡単な手段を提供するというモチベーションがあるようです。

また、この仕様は、各国のプライバシー法などの法的枠組みにおけるオプトアウトの意思表示として扱えることを意図しているようです。

Firefoxでも実装が進められています。
Intent to Prototype: Global Privacy Control

Sec-GPC リクエストヘッダ

Sec-GPCに1を指定することで、個人情報を共有しないように要求できます。

GET /something/here HTTP/2
Host: example.com
Sec-GPC: 1

Sec-GPC リクエストヘッダのサポート

サーバ側がSec-GPC リクエストヘッダをサポートしていることを示すのに、well-known path を定義しています

/.well-known/gpc.json

{
  "gpc": true,
  "lastUpdate": "1997-03-10"
}

2023-07-18

逆向きに接続する Reverse HTTP Transport の仕様

HTTP internet-draft

『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。

普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。

Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。

これによりオリジンサーバをインターネットに公開する必要がなくなります。

プロトコルについて

この Reverse HTTP Transport はプロトコルスタック的にはHTTP2/TLS or HTTP/3/QUICという主要な技術は変更無く使用されます。通常の場合との違いは次のとおりです

ALPN IDとして"h2-reverse", "h3-reverse"を使用する
Proxy側はTLS CertificateRequestを送信する必要がある
オリジンサーバは有効な証明書チェーンを応答する必要がある
オリジンサーバはORIGINフレームを送信し、自身がホストするオリジン名を通知する。なお、このオリジン名は送信したクライアント証明書とマッチする必要がある。
Proxy側は、オリジンサーバの送ってきたORIGINフレームとクライアント証明書を照合する

Proxyはオリジンサーバがホストしてるオリジン名を把握できるので、HTTPリクエストをオリジンサーバ宛に中継できるようになる。

2023-07-14

ブラウザにWebサイトの閲覧履歴を残さないようにする Request-OTR ヘッダ

HTTP internet-draft

「The Off-The-Record Response Header Field」という仕様がIETFに提出されています。これは、Webサイトの閲覧履歴をブラウザが保存しないように指示するHTTPレスポンスヘッダです。

このレスポンスヘッダを使うことで、Webサーバ側から自身のサイトの閲覧履歴を残さないようにすることができます。家庭内暴力の相談やセンシティブな医療サイトの閲覧情報がブラウザに残らないようにできます。

Braveブラウザの1.53 (beta)ではflagsで有効にするとすでに使えるようになっています。動作としては、Webサイトを閲覧する際にOTRモードで閲覧するか確認画面が出るようです。

Request-OTR ヘッダ

Request-OTR ヘッダは、RFC 8941 Structured Field Valuesに準じており、ブール値を指定します

Request-OTR: ?1

何が保存されないか？

Braveのサイトの解説「リクエストOff the Record | Brave Browser」によれば、OTRモードでは次のようになります

アクセス履歴が保存されなくなる
キャッシュ、Cookie、権限設定が一時領域に作成され、タブを閉じたりサイトを離れたときに破棄される

2023-07-13

P2P QUICの提案仕様

QUIC internet-draft

「P2P QUIC」という提案仕様がIETFに提出さています。著者はMicrosoftのPeter Thatcher氏になっています。

Peter Thatcher氏らは、W3Cでも「QUIC API for Peer-to-peer Connections」という提案を行っており、ブラウザ上でQUICを用いたP2P メディア・コミュニケーションを行えるようにより組んでいます。

まだ標準化の議論が盛り上がってるわけではないが、「P2P QUIC」自体はかなり短い仕様ですのでざっくり目を通しておく

P2P QUICについて

P2P QUICではICEを用います。

その中で次の値をネゴシエーションします

どちらがactive (client)とpassive (server) の役割を担うか
証明書のフィンガープリント
QUICでgrease bitを使うか
MuliplexingIDを使うか (MuliplexingIDはQUICコネクションに複数の通信を多重化する仕組み)

SDP

SDPの例として次のとおりになります

v=0
o=- 4962303333179871722 1 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-ufrag:7sFv
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=quic-options:grease
a=fingerprint:sha-256
   7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35:
   DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active
a=group:BUNDLE 1 2 3
m=audio 9 UDP/QUIC/RTP/AVPF 99
a=mid:1
a=sendrecv
a=rtpmap:99 OPUS/4800/2
m=video 9 UDP/QUIC/RTP/AVPF 100
a=mid:2
a=sendrecv
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
m=application 9 UDP/QUIC generic
a=mid:3

QUICの機能など

P2P QUICにおいては、QUICの持ってる機能について幾つか言及があります

ALPNでは、"q2q"を使う
各ピアは証明書の検証を行う (クライアント証明書の検証を行う)。なお自己署名証明書を許容してもよい(MAY)
Multipathを使うべきではない (SHOULD NOT)
QUIC Datagramsをサポートするべき (SHOULD)
コネクションマイグレーションはICEを通して行い、コネクションIDを変更すべきでない (SHOUD NOT)

2023-07-01

UDPにオプション領域を追加する仕様

internet-draft

現状UDPヘッダには、TCPやSCTPにあるようなオプションを指定できません。

新しい「Transport Options for UDP」という仕様では、UDPにおいてオプションを付けられるようになります。

その仕組が面白かったので簡単に紹介します。

どこが面白いかというと、UDPヘッダは下記の通り「送信元ポート」「送信先ポート」「長さ」「チェックサム」からなり、その後に実際のデータが続きます。

固定長のヘッダしかないUDPにおいて、既存の実装に対してもそのままUDPパケットを扱えるようにオプション領域をどう確保したのか、考えてみると面白そうと感じていただけると思います。

Transport Options for UDP

「Transport Options for UDP」では、UDPオプションを格納するのにsurplus areaという領域を確保します。それはIPヘッダについても知る必要があります。

surplus area

IPv4ヘッダとUDPヘッダをくっつけると次のようになります

IPヘッダ領域とUDPヘッダ領域の両方に長さを示す領域があります。IPヘッダで示されたTotal Lengthを全てUDPで使い切る必要はありません。余らせても仕様上は問題ありません。この余らせた領域をUDPオプションを格納する領域 (surplus area) として利用します。
（そのようなことをしてもLinux, MacOS, NATでUDPは正しく扱われるとdraftには記述されています）

図にすると次のように、長さの差からsurplus areaが生まれています。

この仕様に対応していない実装はこの領域をそのまま無視しますので、そのまま通信を継続できます。

UDP Options

surplus areaにはまず、2バイト境界まで0でパディングされます。そのあとにOCS (The Option Checksum)が続きます。OCSはOption領域の整合性を確認できるできるチェックサムです。

UDP Optionは基本的には、Kind・Length/データからなる可変長データです

詳細はを割愛しますが、Kindについては、すでに定義されているものもあります。

0 End of Options List (EOL)
1 No operation (NOP)
2 Alternate payload checksum (APC)
3 Fragmentation (FRAG)
4 Maximum datagram size (MDS)
5 Maximum reassembled datagram size (MRDS)
6 Request (REQ)
7 Response (RES)
8 Timestamps (TIME)
9 Authentication (AUTH)
10-126 UNASSIGNED (assignable by IANA)
127 RFC 3692-style experiments (EXP)
128-191 RESERVED
192 Encryption (UENC)
193-253 UNASSIGNED-UNSAFE (assignable by IANA)
254 RFC 3692-style experiments (UEXP)
255 RESERVED-UNSAFE

0~7は実装が必要なオプションです。Reserved領域はまだ使用されていない領域です。SAFEなオプション(0~191)とは無視されても通信に影響を与えないオプションであり、UNSAFE(192~255)は無視するとパケットを正しく解釈できなくなるオプションです。

2023-06-27

HTTPのキャッシュをグループ化する HTTP Cache Groups の仕様

HTTP internet-draft

『HTTP Cache Groups』という提案仕様がIETFに提出されています。これは、HTTPキャッシュをグループ化し、グループの単位で無効化や再検証を行えるようにする提案です。

Webサイトで利用する複数のJavaScriptやCSSファイルはデプロイすることがあるため、それらのキャッシュの管理をグループで扱うことはメリットがあります。例えばグループ内の一つのキャッシュを再検証(Revalidation)することで、グループ内のほかのリソースも再検証したものとして扱えるようになります。

またCDNのレイヤにおいて、キャッシュの無効化(Invalidation)・パージもグループで行えるのは管理上都合が良いでしょう。

Cache-Groups レスポンスヘッダ

レスポンスにおいてCache-Groupsヘッダでグループを指定できます。
Cache-GroupsヘッダはStructured Field Values 形式のリストです。下記は"ExampleJS", "scripts"グループに所属しています。

また、ExampleJSグループはrevalidateを共有することを示しています。

HTTP/1.1 200 OK
Content-Type: application/javascript
Cache-Control: max-age=3600
Cache-Groups: "ExampleJS";revalidate, "scripts"

Cache-Group-Invalidation レスポンスヘッダ

あるリクエストに応じて特定のグループのキャッシュを無効化 (Invalidation)を指示するのに、Cache-Group-Invalidation レスポンスヘッダが使えます。

下記はCache-Group-Invalidationヘッダで、"eurovision-results", "kylie-minogue"グループのキャッシュを無効化します

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Group-Invalidation: "eurovision-results", "kylie-minogue"

2023-06-26

HTTPのキャッシュを無効化するAPIの標準化する提案仕様

HTTP internet-draft 雑

CDNはキャッシュをパージする機能をよく有しています。そのキャッシュの無効化(もしくはパージ)を要求するためのAPIを標準化するための『An HTTP Cache Invalidation API』という提案仕様がIETFに提出されています。

この提案仕様は、HTTP界隈では著名な Mark Nottingham氏による提案です。まだ最初の提案であり、来月あるIETF会合で紹介があるものと思われる。

An HTTP Cache Invalidation API

この仕様では、次のペイロードを含むPOSTを送ることで、キャッシュの無効化を要求できる

{
    "type": "uri",
    "selectors": [
      "https://example.com/foo/bar",
      "https://example.com/foo/bar/baz"
    ],
    "purge": true
}

type: uri, uri-prefix, origin, group が指定できる
- uri: 一致したURI
- uri-prefix: 前方一致したURI
- origin: 一致したオリジン
- group: キャッシュに指定されたグループ (別の仕様でgroupの仕組みが定義されるHTTP Cache Groups)
selectors: typeに合わせたキャッシュをパージするリソースの指定
purge: trueの場合無効化するだけでなくキャッシュが削除される

レスポンス

上記の無効化要求に対して次のステータスコードでの応答がありえます

200 OK: キャッシュの無効化(パージ)が完了した
202 Accepted: 要求を受け付けた。直にキャッシュの無効化(パージ)が完了する
501 Not Implemented: 要求された指示 (typeやpurgeの指定)をサポートしてない

おまけ

typeのところで説明した、groupについては追加で記事を書いときました
asnokaze.hatenablog.com