「The Off-The-Record Response Header Field」という仕様がIETFに提出されています。これは、Webサイトの閲覧履歴をブラウザが保存しないように指示するHTTPレスポンスヘッダです。
このレスポンスヘッダを使うことで、Webサーバ側から自身のサイトの閲覧履歴を残さないようにすることができます。家庭内暴力の相談やセンシティブな医療サイトの閲覧情報がブラウザに残らないようにできます。
Braveブラウザの1.53 (beta)ではflagsで有効にするとすでに使えるようになっています。動作としては、Webサイトを閲覧する際にOTRモードで閲覧するか確認画面が出るようです。
Braveのサイトの解説「リクエストOff the Record | Brave Browser」によれば、OTRモードでは次のようになります
「P2P QUIC」という提案仕様がIETFに提出さています。著者はMicrosoftのPeter Thatcher氏になっています。
Peter Thatcher氏らは、W3Cでも「QUIC API for Peer-to-peer Connections」という提案を行っており、ブラウザ上でQUICを用いたP2P メディア・コミュニケーションを行えるようにより組んでいます。
まだ標準化の議論が盛り上がってるわけではないが、「P2P QUIC」自体はかなり短い仕様ですのでざっくり目を通しておく
P2P QUICではICEを用います。
その中で次の値をネゴシエーションします
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
現状UDPヘッダには、TCPやSCTPにあるようなオプションを指定できません。
新しい「Transport Options for UDP」という仕様では、UDPにおいてオプションを付けられるようになります。
その仕組が面白かったので簡単に紹介します。
どこが面白いかというと、UDPヘッダは下記の通り「送信元ポート」「送信先ポート」「長さ」「チェックサム」からなり、その後に実際のデータが続きます。
固定長のヘッダしかないUDPにおいて、既存の実装に対してもそのままUDPパケットを扱えるようにオプション領域をどう確保したのか、考えてみると面白そうと感じていただけると思います。
「Transport Options for UDP」では、UDPオプションを格納するのにsurplus areaという領域を確保します。それはIPヘッダについても知る必要があります。
IPv4ヘッダとUDPヘッダをくっつけると次のようになります
IPヘッダ領域とUDPヘッダ領域の両方に長さを示す領域があります。IPヘッダで示されたTotal Lengthを全てUDPで使い切る必要はありません。余らせても仕様上は問題ありません。この余らせた領域をUDPオプションを格納する領域 (surplus area) として利用します。
（そのようなことをしてもLinux, MacOS, NATでUDPは正しく扱われるとdraftには記述されています）
図にすると次のように、長さの差からsurplus areaが生まれています。
この仕様に対応していない実装はこの領域をそのまま無視しますので、そのまま通信を継続できます。
surplus areaにはまず、2バイト境界まで0でパディングされます。そのあとにOCS (The Option Checksum)が続きます。OCSはOption領域の整合性を確認できるできるチェックサムです。
UDP Optionは基本的には、Kind・Length/データからなる可変長データです
詳細はを割愛しますが、Kindについては、すでに定義されているものもあります。
0~7は実装が必要なオプションです。Reserved領域はまだ使用されていない領域です。SAFEなオプション(0~191)とは無視されても通信に影響を与えないオプションであり、UNSAFE(192~255)は無視するとパケットを正しく解釈できなくなるオプションです。
『HTTP Cache Groups』という提案仕様がIETFに提出されています。これは、HTTPキャッシュをグループ化し、グループの単位で無効化や再検証を行えるようにする提案です。
Webサイトで利用する複数のJavaScriptやCSSファイルはデプロイすることがあるため、それらのキャッシュの管理をグループで扱うことはメリットがあります。例えばグループ内の一つのキャッシュを再検証(Revalidation)することで、グループ内のほかのリソースも再検証したものとして扱えるようになります。
またCDNのレイヤにおいて、キャッシュの無効化(Invalidation)・パージもグループで行えるのは管理上都合が良いでしょう。
レスポンスにおいて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"
あるリクエストに応じて特定のグループのキャッシュを無効化 (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"
CDNはキャッシュをパージする機能をよく有しています。そのキャッシュの無効化(もしくはパージ)を要求するためのAPIを標準化するための『An HTTP Cache Invalidation API』という提案仕様がIETFに提出されています。
この 提案仕様は、HTTP界隈では著名な Mark Nottingham氏による提案です。まだ最初の提案であり、来月あるIETF会合で紹介があるものと思われる。
この仕様では、次のペイロードを含むPOSTを送ることで、キャッシュの無効化を要求できる
{
"type": "uri",
"selectors": [
"https://example.com/foo/bar",
"https://example.com/foo/bar/baz"
],
"purge": true
}
上記の無効化要求に対して次のステータスコードでの応答がありえます
typeのところで説明した、groupについては追加で記事を書いときました
asnokaze.hatenablog.com
QUIC上でライブメディアなどを扱うプロトコルの標準化が、IETFのMoQ WGで進められています。
WarpやRUSHというプロトコル案が出ていましたが、プロトコルの設計が進み、コアプロトコルになる『Media over QUIC Transport (MOQT)』が登場しています。この仕様は、Twitch、Facebook(Meta)、Cisoco、Googleの方の共著となっています。
MOQTは、QUICプロトコルもしくはWebTransport上に位置するプロトコルです。その上に、Warpのようなメディアフォーマット・ストリームフォーマットを定義する仕様が乗っかります。(WarpとMOQTの役割が分割された感じになります。)
「WARP Streaming Format」は、MOQTのストリームフォーマットを定義する仕様であり、CMAF [CMAF] 準拠のメディア コンテンツを配信します。
MOQTでは、通信の種類として下記の3つの利用を想定しています。
そのうえで、登場人物は次のようになります。
ここで、Client/Serverはプロトコルの通信をどちらか開始するかの観点の用語です。Clientには役割に応じて、メディアを送信するProducerと、メディアを受信するConsumerが居ます。その間に通信を中継するRelayサーバが存在し得ます。
また、上記の図では片方向的な送信でしたが、ビデオカンファレンスのようにRelayサーバを介した双方向メディア通信もありえます。その場合はClientはProducerとしてもConsumerとしても振る舞うことになります。
MOQTはメディアのデータを「Objects」「Groups」「Tracks」という単位で管理します。
TrackはConsumerにより視聴が要求されるため、そのためにFull Track Nameを持ちます。例をみるとわかりやすいかと思います。
Track Namespace = security-camera.example.com/camera1/ Track Name = hd-video Full Track Name = security-camera.example.com/camera1/hd-video
なお、単一のObjectをQUICの単方向ストリームで送信することを想定しています。こうすることでHead of Line Blockingを狙いです。
MOQTではプロトコルのメッセージとして以下のものが定義されています。QUICもしくはWebTransportのコネクションが確立するとストリーム上で送受信されます。
IETFやCAB Forumで有効期限の短い証明書(Short-lived Certificate)について議論があるようなので軽く眺めておく
詳しい人は補足いただけると嬉しいです
Googleでは、Webをより安全にするためにWeb PKIのポリシーについて様々な取り組みを行っています。
www.chromium.org
その取り組みのなかにはCAが証明書の発行ポリシーに関するものもあります。
有効期間の短い Short-lived証明書 の利用を促し、より自動化を促進するために、CA/Browser ForumのBaseline Requirementsに対して提案を行っています。
具体的なProposalでは、OCSPをOptinalにすることと、Short-lived Certificateで失効(Revocation)が不要であるとすることを提案しています。
github.com
Short-lived Certificateの有効期限は次のとおりです
この10日というのは、CRLの"nextUpdate"及びOCSPレスポンスの有効期間の最長と一致しています。
Short-lived Certificateについては、CAは失効処理が不要なようである。
また、Short-lived Certificate自体にもCRL Distribution Points拡張を含めるべきではない。さらに、このProposalはShort-lived Certificateに限らずOCSPをOptionalにすることを提案している。
また、IETFには次の提案が提出されています『No Revocation Available for Short-lived X.509 Certificates』。
これは、失効情報が提供されないShort-lived Certificateに対しては明示的に、noRevAvail拡張をつけようという提案です。
