2017-01-01から1年間の記事一覧

2017年 振り返り

2017年を振り返る今年はブログ記事をたくさん書いた。 60記事、そのうち internet-draftタグの付いたものは33にもなる、W3Cは10であった。ブログに加え、登壇や執筆などを行えた。さらに、Mozaic.fmにも出させてもらえた。 mozaic.fm某省庁に呼ばれたり、IET…

DTLSにコネクションIDを導入する提案仕様

追記 20180702 「The DTLS Protocol Version 1.3」で、DTLS1.3の仕様でconnection_id拡張について言及されています DTLSにコネクションIDを導入する「The Datagram Transport Layer Security (DTLS) Connection Identifier」という提案が出ています。DTLS1.3…

将来のQUICをデプロイしやすくするための取り組みと議論 (QUIC GREASE)

MozillaのM. Thomson氏より「More Apparent Randomization for QUIC」というinternet draftが出ています。 ## QUICのここまで QUICはIETFで標準化が進められています。当初は2018年3月が一つのマイルストーンになっていましたが、スコープとマイルストーンの…

ライブコンテンツにおけるHTTP Rangeリクエストを改善する提案仕様 (RFC8673)

追記2019/11/28 RFC8673になりました ライブコンテンツやログデータといった常に大きくなり続けるコンテンツに対するRangeリクエストを改善する提案仕様がIETFのHTTPbisで出ています。その仕様は「HTTP Random Access and Live Content」であり、すでにWGア…

QUIC Invariantsの議論 (RFC 8999)

2021/09/12 追記: このとき議論されていた仕様は RFC8999として標準化されています QUICは現在IETFで標準化が進めれています。QUIC WG出来、本格的に標準化が開始して1年ほど立ったところで、スケジュールとスコープの議論(QUIC - Our schedule and scope)が…

QUICのSpin Bitの議論

20181111追記 IETF103でも意見が割れ議論となりましたが、Humの結果以下のようになりました。Spin Bitの仕様は拡張仕様となり必ずしも実装する必要はなくなりました。QUICのコア仕様ではスピンビット用のビットを確保する(好きな台を入れて良い)だけとなって…

TLS over HTTPの提案仕様

TLS over HTTPである。HTTP over TLSではない。「Application-Layer TLS」という提案仕様がCiscoの方より提出されている。(仕様中ではATLSと記述される)HTTP上でTLSレコードを送受信する仕様である。TLSレイヤの実装変更はなくレコードをHTTPのボディで送受…

HTTPヘッダに構造定義を与える Structured Headers の提案仕様 (draft-00)

2019/12/17追記 draft-14ベースで記事を書き直しました。 (また、最新仕様では 名称が "Structured Field Values for HTTP" に変更されました) asnokaze.hatenablog.com以下は古い記事です。 HTTPヘッダには、リストや辞書といった構造を表現するのに決まっ…

iframe内の転送量を制限する Transfer Size Policy とは

Webページにソーシャルボタンや広告といったiframeを埋め込むことがあります。この時、埋め込んだ側はiframeの中で使用されるリソースを制限する方法はありません。例えば動画を再生すればトラフィックとCPUが消費されますし、最近では実はBitcoinの採掘に利…

Content Security Policy(CSP) レポートのCORSと、Fetchの仕様変更

WHATWG, Fetch詳しくないので間違いがあればご指摘下さい Content Security Policy(CSP)やHPKPやExpect-CTでは、ユーザエージェントはセキュリティの違反を検出した際に、指定したURLにレポートを送信できる。例えば、下記のようにHTTPレスポンスヘッダにrep…

QUICとネットワーク管理/オペレーションの話

あわせて下記記事も参照のこと asnokaze.hatenablog.com ワイヤイメージ 経路上で出来ること QUICトラフィックの識別 バージョンの識別 不正なパケットの拒否 コネクション確立の確認 通信フローの関連付け 通信フローの切断検出(不可) ラウンドトリップタイ…

Mixed Content Level 2の議論 (2017年)

20190905 追記 Draft版の仕様が出てきたので「Mixed Content Level 2の仕様について - ASnoKaze blog」を書きました。 20181010 追記 Chromeが行っている取り組みについて、「Auto Upgrade Mixed Contentとは - ASnoKaze blog」を書きました。 W3CのWeb Appl…

Akamai Edge 2017 に行ってきた

10月11~13日に、ラスベガスで開催されたAkamai Edge 2017に参加してきました。英語を聞きながらのメモなので断片的ではあるが、せっかくですので、面白かった所など紹介する。 オープニング・キーノート マルチソース・ストリーミング Bot Manager パフォー…

Device Memory APIを用いてデバイスのメモリサイズを取得する

背景 Webサービスでは、デバイスの性能毎に軽量版の機能を提供することが有ります。Google Search、Google Map、Facebookなどではローエンドデバイスでは一部軽量版のページを提供することが有ります。または、クライアントサイドで何かしらの処理速度などを…

WebSockets over HTTP2 の提案仕様。再び。(RFC8441)

2018/09/19追記 RFC 8441 として標準化されました2018/03/10追記 WebSockets over HTTP2の更新分について、記事を別途書きました asnokaze.hatenablog.com2018/02/06追記 「Bootstrapping WebSockets with HTTP/2」はWG Draftになり、この方向で標準化が進む…

TLS1.3とDC内での復号に関する熱い議論

各ブラウザや、OpenSSL・BoringSSLといった暗号ライブラリ、ミドルウェアのTLS1.3対応が進んでおり、実際に通信できるところまで来ている。標準化としても大詰めを迎えている。前回のIETFより話題に上がっている、TLS1.3に関するDC内での復号を目的とした議…

パスワードマネージャが適切にパスワードを生成できるようにするポリシーの提案仕様

パスワードの管理に、1PasswordやLastPassといったパスワードマネージャを使うのは一般的になってきています。そのようなパスワードマネージャはランダムなパスワードを生成しますが、Webサービスによって使える文字の種類や、長さというのはマチマチです。…

キャッシュサーバの効率を改善するHTTP Variantsという提案仕様

HTTP Variants IETFのHTTP WGやQUIC WGのチェアをしているmnot氏より、キャッシュの効率が改善する「Variants」というHTTPレスポンスヘッダを定義する「HTTP Variants」という提案仕様が出ています。この機能は、Fastly VCLの機能の標準化のようです。少々想…

HTML要素からHTTP/2優先度を指定する Priority Hints

20180912追記 Chrome71で動作確認しました。 仕様的にも変更が入ってるので、下記記事参照 asnokaze.hatenablog.com HTTP/2ではリクエストは並列的に行われますが、クライアントは各リクエストに優先度を設定できます。サーバはこの優先度によって、レスポン…

DNS Queries over HTTPS の標準化 (RFC8484)

20181020更新 RFC8484として標準化されました 「DNS Queries over HTTPS」の仕様の標準化が始まっている。今までもこのテーマはIETFにおいて何度か議論になってきましたが、今回 DNS Over HTTPS (doh) WGの設立に合わせて(まだProposed)、この「DNS Queries …

セキュリティの報告先を記述する、security.txtの提案仕様 (RFC9116)

Webサイトのセキュリティリスクを発見したものの、連絡先が適切に公開されていないがために、結局報告されず脆弱性が放置されるケースがあるようだ(国内だと、IPA脆弱性関連情報の届出受付もあるが)発見者が脆弱性等の報告を出来るような情報を、Web作成者が…

QUICにおける信頼性のないストリームの提案仕様

20180923追記QUICの信頼性のないデータグラム拡張(MESSAGEフレーム/Datagramフレーム) https://asnokaze.hatenablog.com/entry/2018/09/23/012519別の拡張仕様案が議論されています QUICはUDPを使用しますが、内部的にストリームという信頼性のある通信単位…

TLS record_size_limit 拡張の提案

IoTデバイスなどリソースが制限されている端末でTLS通信を行うのには課題がある。特に送られてきたレコードを復号するのにはそれを計算する十分なメモリが必要になる。リソースが制限されている端末でも問題なく復号処理が出来るように、相手に受信したいレ…

W3CにおけるWeb Lifecycleの議論 (Page Lifecycle API)

20180523 追記Page Lifecycle API等とも呼ばれているようです。 github.com下記内容は古く一部ことなっています W3CでWebPerf Web Performanceで、「Web Lifecycle」というトピックが議論に上っていた。(Agenda URL)これは、iOSアプリやAndroidアプリのActiv…

Chrome62から、http://でのフォームに入力すると警告が出るようになる

2017/10/18更新 Chrome 62がリリースされましたが。徐々に適応されていくようです。The field trial allows us to turn on the feature over time. It will be at 100% soon.— Eric Lawrence (@ericlaw) 2017年10月18日 Chrome 52(今年1月リリース)において…

GoogleのQUICの論文が知見の塊だった

20181107追記 QUICプロトコルについての概要は別途記事を書きました asnokaze.hatenablog.com 概要 ACM SIGCOMM 2017という通信系の学会に、Googleの人 総勢21人によって書かれた「The QUIC Transport Protocol: Design and Internet-Scale Deployment」とい…

ジオロケーションを要求・送信する HTTP Geolocationヘッダの提案仕様

GoogleのLuis Barguno Jane氏より、HTTPヘッダでジオロケーション情報の要求・送信を可能にする「Geolocation Header for HTTP over a Secure Context」という仕様が出ています。 背景 ユーザエージェントにおいてジオロケーションの取得は「Geolocation API…

QUICにおけるヘッダ圧縮の提案仕様 QPACK(旧QCRAM)

20190408追記 最新版について記事を書きました asnokaze.hatenablog.com QUICとヘッダ圧縮 HTTP over QUICの仕様は現状、HTTP/2と同様HPACK(RFC 7541)を利用してHTTPヘッダの圧縮を行う。HPACKはHTTP/2を想定としており、トランスポートはTCPであり順番通り…

minqを弄って memcached over quic を簡単に実装してみる

IETF QUIC QUICの標準化がIETFで進められています。QUICといえば既にChromeとGoogleのサービスで使用されていますが、そちらはGoogle QUICであり、IETFで標準化されているものとは微妙に異なっています。IETF QUICの方は仕様の策定の議論が重ねられるととも…

Chromeがシマンテックの古い証明書を信頼しなくなる今後のスケジュール(2017/09/13更新)

2017/09/13 更新Googleのブログで公式アナウンスが出ました。 一部対応者の表記がDigiCertになりましたが、大きなスケジュール変更はありません security.googleblog.com 今年の上旬より、Chromeが古いシマンテックの証明書を失効扱いするニュースが世間を賑…