「Private Access Tokens」という提案仕様が、Google, Apple, Fastly, Cloudflareの方々らの共著でIETFに提出されています。なお、すでに実装が進められているそうです。 この「Private Access Tokens」の一つのモチベーションに次のようなものがあります。 昨今、プライバシー保護の要求は高まっており、ユーザのIPアドレスを秘匿する、iCloud Private RelayやOblivious HTTPといった技術が出てきています。いままではIPアドレスベースでアクセスレートリミットを行っていましたが、 そのような環境でも、アクセスのレートリミットを設けたいというというのが一つの目的です。 それを、追加のユーザインタラクション無しに、かつユーザをトラッキングできないような匿名なトークンで行うというのがPrivate Access

はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする

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

2020/01/14: 実際に動くのを確認しました asnokaze.hatenablog.com (2020/09/17 注釈: Raw SocketsからDirect Socketsに名称が変更されました) ブラウザでTCP, DUPソケットを操作可能にする「Direct Sockets API」という仕様がW3CのWICGで議論されている。 また、blink-devでも「Intent to Prototype: Raw Sockets API」とプロトタイプの議論が行われている。 多くの方がセキュリティ上の懸念を抱くと思うが、ドキュメントでも慎重に検討すると書かれている。GithubでIssueを立てることも可能なので、思うことがある方は、まだまだ議論は始まったばかりでもあるので是非フィードバックされると良いと思う。(割と普通に聞いてもらえます) なお、Raw Socketsという名

Cross-Origin-Opener-Policy (COOP)は現在、ChromeやFirefoxで実装が進められている機能です。 Chrome: Implement Cross-Origin-Opener-Policy firefox: Implement Cross-Origin-Opener-Policy 仕様としては、whatwgで長らく議論がされており、おそらく仕様に入るでしょう Restricting cross-origin WindowProxy access (Cross-Origin-Opener-Policy) · Issue #3740 · whatwg/html · GitHub Cross-Origin-Opener-Policy: provide a clearer spec. · Issue #4580 · whatwg/html · GitHub 面白

2021/01/30 追記:RFC8959で標準化されました https://www.rfc-editor.org/rfc/rfc8959.html セキュリティートークンを間違えて公開してしまうセキュリティインシデントが増えています。例えば、シークレットやトークンをソースコードに埋め込んだままコミット・公開してしまったりなどです。 機械的にセキュリティトークンを識別できるようになれば、意図せずそのようなセキュリティトークンがコミットされたり公開されるのを機械的に防げるようになります。 先日IETFに提出された「The secret-token URI Scheme」という仕様ではsecret-token URI Schemeを定義し、セキュリティトークンを識別できるようにします。 例 トークンにsecret-token:を付けます secret-token:E92FB7EB-D882-4

20181107追記 QUICプロトコルについての概要は別途記事を書きました asnokaze.hatenablog.com 概要 ACM SIGCOMM 2017という通信系の学会に、Googleの人 総勢21人によって書かれた「The QUIC Transport Protocol: Design and Internet-Scale Deployment」という論文が提出され、学会ホームページより閲覧出来る。 この論文は、QUICの設計仕様と実際にGoogleのサービスにデプロイした結果について書かれている。 すでにGoogler SearchやYoutubeでQUICは有効になっており、一日あたり数十億の接続を処理し、Googleのegress trafficのうち30%がQUICになっており、インターネットのトラフィックの内7%がQUICだと推定されるという説明から論文は始まる。

[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを

20180824追記 Loading Signed Exchangesについて記事を書きました Loading Signed Exchangesの仕様 (WebPackaging) - ASnoKaze blog 20180208追記 Bundled HTTP Exchangesについて記事を書きました Bundled HTTP Exchanges とは (WebPackagingの議論より) - ASnoKaze blog 20180121追記 署名の仕組みとして Origin-Signed HTTP Exchanges を利用する方向のようです HTTP/2 クロスオリジン サーバプッシュを可能にする提案仕様 - ASnoKaze blog 20171001追記 IETF99にてユースケースについてまずまとめるべき気というフィードバックが有り、それをうけて「Use Cases and