RFC 9458 Oblivious HTTP の仕組みについて - ASnoKaze blog
『Oblivious HTTP』はユーザのプライバシを向上するための技術であり、各ブラウザベンダーおよびCDNベンダーが実装を行っています。 取り組みについては、幾つかの記事があがっています 『Google、Chrome ユーザーのオンラインプライバシー保護を強化するプライバシーサンドボックスのイニシアチブに Fastly Oblivious HTTP リレーを採用』 『Built for privacy: Partnering to deploy Oblivious HTTP and Prio in Firefox』 今回は仕様の観点で、プロトコルの中身に触れていく 背景と目的 通信観点のプライバシーについては、通信の暗号化によりほとんどが保護されています。しかし、幾つか懸念が残っています。 IPアドレスは、短期的に同一ユーザを識別するのに使用できる コネクションは、一連の通信が同一ユー
IETF116 Yokohamaをもっと楽しむために (その2) ~当日編~ - ASnoKaze blog
ついに、IETF 116 Yokohamaが始まりましたね！！横浜で僕と握手！！ WGのミーティングは月曜日からですので、ちょうど直前ということになります。 パシフィコ横浜ノース 3Fで受付を済ませたあとは、アジェンダ(URL)のページを参考に会議室に行くだけです。 WGのミーティングでは、前回議論した提案仕様のIssueが議論されます。できれば、WGミーティングのAgendaは抑えて予習はしておいた方が良いかと思います。とはいえ、会議中にちんぷんかんぷんでも情報を追うコツを幾つか書いておこうと思います。 心得 英語は分からない、、、みんな分からない大丈夫！！ せっかくなので色々な人に話しかけよう (議論とかは詳しい人に聞こう！) 無理して全部のミーティングに出る必要はない！ WG ミーティング materials 各WGのアジェンダ及び発表資料は マテリアルページ(URL)に記載されます
CookieのPartitioned属性 (CHIPS) の標準化はじまる - ASnoKaze blog
サードパーティCookieをトラッキングに使用できないようにする「Cookies Having Independent Partitioned State (CHIPS)」という仕組みが議論されています。 現在は、その仕組はW3CのPrivacy CGで議論されています。細かい仕組みは以前書いたとおりです。 ( トラッキングに利用できない3rdパーティクッキー「CHIPS」の仕組み (partitioned属性) - ASnoKaze blog ) このCHIPSは、Cookieに新しいPartitioned属性を利用します。Cookie自体の仕様は、IETFが発行するRFC 6265で定義されており、そこにPartitioned属性を追加してやる必要があります。 そのためIETF側にも「Cookies Having Independent Partitioned State specif
一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
2021年 HTTPやQUICの最新動向振り返り - ASnoKaze blog
2021年について、プロトコル周りの動向を振り返っていきたいと思います。 今年は、個人的には次の2点がホットトピックと挙げられると思います。 QUICやHTTP/3を活用した応用系プロトコルの作業が進む プライバシー系の取り組みが活発化 それでは、個別に補足していきます。（IETFの動向がメインです。なお、個人的にキャッチアップできてないトピックもあります...） HTTP関連 まずは、HTTPです。HTTP/3の標準化が注目を浴びていますが、HTTP/1.1やHTTP/2なども改定作業が行われております。あわせて、HTTPセマンティクスは各バージョンから独立し、各バージョンから参照される形となりました。それぞれRFC出版の最終段階となっています。 書いた記事はここらへん HTTPのバージョンについて、現在のまとめ HTTPセマンティクス仕様の改訂版 まとめ HTTP/2の改定版仕様の変更
新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等
匿名かつ検証可能なPrivate Access Tokensの提案仕様 (プライベートアクセストークン) - ASnoKaze blog
「Private Access Tokens」という提案仕様が、Google, Apple, Fastly, Cloudflareの方々らの共著でIETFに提出されています。なお、すでに実装が進められているそうです。 この「Private Access Tokens」の一つのモチベーションに次のようなものがあります。 昨今、プライバシー保護の要求は高まっており、ユーザのIPアドレスを秘匿する、iCloud Private RelayやOblivious HTTPといった技術が出てきています。いままではIPアドレスベースでアクセスレートリミットを行っていましたが、 そのような環境でも、アクセスのレートリミットを設けたいというというのが一つの目的です。 それを、追加のユーザインタラクション無しに、かつユーザをトラッキングできないような匿名なトークンで行うというのがPrivate Access
大体の位置情報を示すSec-CH-Geohashヘッダ - ASnoKaze blog
Private Relayをはじめ、Proxyを通してクライアントのIPアドレスをサーバに対して隠す技術が登場しています。 ところで、Webサービスはクライアントの位置情報によって出力する情報を変えたり、最適化を行う場合があります。JavaScriptのGeolocation APIから取得することもあるでしょうが、APIアクセスなどJavaScriptが利用できない場合もあるでしょう。その場合、IPアドレスから位置情報を類推する手段(GeoIPなど)があります。 IPアドレスから位置情報をある程度推測する手法は、IPアドレスが隠されると機能しなくなります。 Private Relayではユーザが望む場合は、Webサーバに対して大体の位置情報を提供するという観点について、IETF 111の発表で触れています。 (https://datatracker.ietf.org/meeting/11
ホスト名の最後が数字なURLの扱いについて - ASnoKaze blog
「WHATWG URL」の仕様で、ブラウザにおいて、ホスト名がIPv4でないが、数値で終わるURLは拒否されるように変更された。 github.com 例えば次のようなものです foo.0 bar.0.09 1.2.3.4.5 今まで、これらのホスト名は、その他のドメインと同じように、通常通り名前解決されます。Issueの起案者は、すでに具体的な攻撃があるわけではないとしつつも、紛らわしさや、eTLD+1 (same-site)の扱いの問題があるとのことです。 なお、次のようなものはIPv4アドレスにマッピングされアクセスできます。 http://127.1 http://1.65793 Deprecate support for URLs with non-IPv4 hostnames ending in numbers 実際に、Chromeでは、そのような変更を入れる検討が始まっていま
FacebookのQUICを活用したライブ動画用プロトコルRUSHについて - ASnoKaze blog
Facebookの方々から「RUSH - Reliable (unreliable) streaming protocol」というプロトコル仕様が、IETFに提出されています。 簡単に眺めていきます。 Facebookとライブ動画 このRUSHはRTMP代替として、クライアント(配信者)のアプリからライブ動画を取り込むためのプロトコルのようです。Facebookではすでに使っているようです。 2018年頃のFacebookのエンジニアブログを見ると、Facebook Liveではクライアント(配信者)からの動画の取り込みに RTMPSを使っていることが紹介されています。おそらく、ココの部分を代替するのでしょう。視聴者へはCDNを通してMPEG-DASHで配信されるようです。 また、IETFの投稿をみると、Facebookではアプリ及びインフラでこのプロトコルを使用していると述べています (
タイムゾーンを含むタイムスタンプ文字列表現の標準化 - ASnoKaze blog
「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:
時間順にソート可能なUUIDv6, UUIDv7, UUIDv8の提案仕様 - ASnoKaze blog
IETFに「New UUID Formats」という提案仕様が提出されています。 これは、時系列順にソート可能なUUID version 6, UUID version 7, UUID version 8を新しく定義するものです。 詳しい背景は提案仕様にゆずりますが、ULIDを始めとして、時系列順にソート可能な一意な識別子を利用したいというユースケースがあります。例えば、データベースのキーとして使えば、ソートせずとも順番に並びますし、書き込む際も順々に書き込めるのでデータアクセスが局所的になります。 今回は簡単に、それぞれのUUIDのフォーマットを眺めていきます。なお、フォーマットは異なりますが、バージョンを示す値は同じ位置にあります。 UUIDv6 UUIDv6は128bit長で、UUIDv1と似てるフォーマットを取ります。 1582年10月15日(グレゴリオ暦)からの100ナノ秒単位で
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
CDNのキャッシュを制御する CDN-Cache-Control ヘッダ - ASnoKaze blog
CDNのキャッシュを制御する「CDN-Cache-Control」を新しく定義する提案仕様「The CDN-Cache-Control HTTP Response Header Field」が出ているので、簡単に紹介する。 2021/10/16 追記: 最新仕様では「Targeted HTTP Response Header Fields for Cache Control」と呼ばれる はじめに HTTPではキャッシュを制御するのにCache-Controlヘッダを使用しますが、クライアントとは別にCDNに対して個別にキャッシュの制御を行いたい場合もあります。 その用途のために使用する「CDN-Cache-Control」を新しく定義しようというのが「The CDN-Cache-Control HTTP Response Header Field」です。 この仕様は、Akamai, Fas
ChromeのHTTP/2サーバプッシュサポート廃止検討と、103 Early Hintsについて - ASnoKaze blog
ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中
CookieのSameSite属性にFirstPartyLaxを追加する提案仕様 - ASnoKaze blog
2020/11/02 追記 First-Party Sets自体はChromeへの実装が進められる一方、FirstPartyLaxについては廃止されたようです https://bugs.chromium.org/p/chromium/issues/detail?id=989171 https://chromium.googlesource.com/chromium/src/+/04aa50c66dcf995a654c1ee5fd605c6d6738fa1e Cookieのセキュリティ改善を推し進めているGoogleのMike West氏から「First-Party Sets and SameSite Cookies」という提案仕様がIETFで提出されています。 この提案仕様では、CookieのSameSite属性に下記の2つを指定できるようにします。 FirstPartyLax First
「Advisory Content-Length for HTTP」と自転車置場の話し - ASnoKaze blog
プロトコルの標準化の場では、自転車置き場(Bikeshed)の話がたまに出てきます。そのやり取りが面白かったので、今回新しく出た提案仕様自体の解説にあわせて紹介します。 Advisory Content-Length for HTTP IETFでHTTP WGの議長も務める Mark Nottingham氏から「Advisory Content-Length for HTTP」という提案仕様が提出されています。 ここで背景としている問題は次のとおりである。HTTPにおけるContent-Lengthヘッダーは、2つの意味で使用されています。1つめは、HTTP/1.1におけるメッセージの終端を示すため。2つめは、メッセージボディ(内容)の長さを示すために使用されます。 HTTP/1.1に置いてメッセージの終端を示すのに使用されていますが、Transfer-Encodingヘッダと合わせて使用
UUID version 6の提案仕様 - ASnoKaze blog
[2021/04/28追記] 新しく提案仕様が出たので、新しく記事を書きました asnokaze.hatenablog.com 先日IETFに提出された「UUID Format Update」という提案仕様の中でUUID version 6のフォーマットが言及されている。このDraftはUUIDを定義しているRFC4122を更新するものです。 ただ、まだIndividual Draftのdraft 00であり、この提案自体どうなるかは全くわからない点に注意が必要。 なお、UUIDv6自体はこの提案を行っているBrad G. Peabody氏が以前から取り組んでいた模様で、4年以上まえから案は存在していたようだ(URL)。またそのタイミングでサンプル実装も公開している。 UUIDv6 この提案仕様の中で、UUIDをデータベースのプライマリキーとして使用する際の課題をあげている。時系列順に並び
Mixed Content Level 2の仕様について - ASnoKaze blog
2年前ほど前に「Mixed Content Level 2の議論」に書いたとおり、Mixed Content Level 2についての議論は以前から行われていました。 2019/08/22の日付で、w3cのリポジトリにEditor’s Draftとして「Mixed Content Level 2」のページが加わっております。 w3c.github.io まだ、TODOのものもありますがアルゴリズム部分については書かれています。 Mixed Content Level 1では表示できていた Mixed Content な画像,音声,動画もブロックされる可能性があります。 Mixed Content Level 2 http://~なoptionally-blockable content(画像,音声,動画)は、自動でhttpsのURLとしてアクセスされます httpsでアクセスに失敗した場合
Cookie の SameSite=Lax をデフォルトにする提案仕様 - ASnoKaze blog
20191226 追記 SameSite属性のついたCookie自体を拒否する古いクライアントにご注意ください https://sites.google.com/a/chromium.org/dev/updates/same-site/incompatible-clients 20190823 追記 suidenOTI さまよりご指摘いただきました 不具合があったためChrome80でのリリースに延期になったようです。 https://www.chromestatus.com/feature/5088147346030592 https://www.chromestatus.com/feature/5633521622188032 20190523 追記 Firefoxでも同様の動きがあります https://groups.google.com/forum/#!msg/mozilla.de
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
