PCの負荷状況に合わせて、Webサイトでの処理を軽量なものに切り替えたい場合があります。 それを可能にする仕組みである「Compute Pressure API 」がChromeで実装が進められています。なお、仕様の方もW3Cで「Compute Pressure Level 1」が公開されています 例 Compute Pressure APIを使うと、PCのCPU負荷が4段階で確認できます。 Nominal: 負荷が低い状態 Fair: システムは正常に動作しており、追加のワークロードを実行できる Serious: 負荷が高い状態。追加のワークロードを実行するとCriticalになりうる Critical: 負荷が限界に近い状態 詳しいCPU情報はプライバシーの観点から公開しない設計になっています。 実行例 Compute Pressure API は現在Chromeの開発版で動作確認でき

Blinkの開発者メーリングリストで「Intent to Prototype: Origin-Bound Cookies」という議論が行われています。 Cookieをより安全にするために、デフォルトでCookieをオリジンに紐づけるようにする提案です。Cookieをset-cookieしたオリジン以外からは、そのCookieにアクセスできないようになります。 詳しい背景や仕組みについては次のページから確認できます。 github.com かんたんに、Origin-Bound Cookiesの動作をみていきましょう。 例 オリジンは、スキーム、ホスト名、ポートの組です。それらのうち一つでも異なれば、オリジンが異なることになります。 例えば、次のようになります。 http://example.comによってセットされたcookieは、http://example.comにのみ送信されます。ht

Webサイトのバグを見つけたとしても、その報告先を知る統一的な方法は現状ありません。 たとえば、脆弱性についてはsecurity.txt があります。https://www.facebook.com/security.txt などで使われています。 asnokaze.hatenablog.com 同様の仕組みで、contributing.txt という形式でバグの報告先を示せるようにする仕組みが提案されています。提案仕様は「a simple way to provide informations for contributors」としてIETFに提出されています。 例 contributing.txtをWebページの最上位階層に配置します (例: https://example.com/contributing.txt ) そのファイルは次の情報を含めることが出来ます。 Admin: Va

HTTPでファイルをアップロードする時、ネットワークの寸断などによりアップロードが中途半端に終わってしまうことがあります。アップロードが途中まで成功したとしても、一度切断するとそこから再開する方法は標準化されていません。 (PUTリクエスト + Rangeヘッダによる再開をサポートしているシステムもありますが標準化されてはいません。 参考URL) そこで、再開可能なアップロードの仕組みを定義した「Resumable Uploads Protocol」という仕様がIETFに提出されています。この仕様は、Transloadit Ltd, Apple Inc, Cloudflare などの方々の共著になっています。 Resumable Uploads Protocol の概要 「Resumable Uploads Protocol」は、一度中断しても再開可能なアップロード方式を定義しています。

「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では、そのような変更を入れる検討が始まっていま

ChromeでCookieのSameParty属性の開発が進められている (コミット)。 現在のところ「SameParty cookie attribute explainer」に説明が書かれている。 今回は、CookieのSameParty属性について簡単にメモしていく。 背景 トラッキング対策、プライバシーの観点でサードパーティクッキーは制限する方向に進んでいる。その制限をSame Partyの場合に緩和する仕組みを提供するのがSameParty属性の話である。 例えば、同一主体により運営されているドメインの異なるサイト (例えば、google.co.jp, google.co.uk) 間においては、いわゆる(cross-site contextsで送られる)サードパーティクッキーを許可しようという話です。 もともとは、First-Party Setsを活用しSameSite属性にFi

ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中

Chromeに、Permissions PolicyとDocument Policyという仕様の実装が進められています。 今回は、ブラウザがwebページを表示する際に制限を与えるこれらの機能について説明していきます。 仕様は下記から参照できます Permissions Policy Document Policy あわせて、blink-devメーリングリストのintentやexplainerを読むと分かりやすいかと思います Intent to Ship: Permissions-Policy header Intent to Ship: Document-Policy header これらはiframe先へのdelegationについて違いがあります (追記予定) Permissions Policy Permissions-PolicyはHTTPレスポンスヘッダで、ブラウザのカメラや位置

[目次] 概要 Secure context restriction for external requests CORS-RFC1918 非セキュアコンテキストなWebサイトからプライベートアドレスへのHTTPリクエストをブロックする「Secure context restriction for external requests」の導入が進められています。 概要 インターネットに公開されているWebサイトから、プライベートアドレスに対するCSRF攻撃が問題になっています。ネットワーク機器やプリンタの管理画面で使われるプライベートアドレスにリクエストを行わせることで、攻撃が行われます。 例えば下記のリンクを埋め込むことで、プライベートネットワークを指すrouter.local にHTTPリクエストを行わせます。 <iframe href="https://admin:admin@rout

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という名

[追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP

W3C Web Performance Workingの議事録に「JS Self-Profiling API」についての議論があったので簡単に眺めておく。 ミーティングの「発表スライドはこちら」 JS Self-Profiling API いわゆるRUM(Real user monitoring)などと同様、実際のユーザ側でJavaScriptのプロファイルを取得可能にするというのが「JS Self-Profiling API」のようだ。 ユーザにより端末やネットワーク環境が違うため、実際のユーザ側でJavaScriptのプロファイルを取りたい。timerを使うことで擬似的に測定はできるが、コード量やオーバヘッドが増える。この提案を行っている、Facebookの人らはJavaScriptとSharedArrayBuffersでサンプリングプロファイラを実装したが正確性とパフォーマンスの欠点

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

@flano_yukiがHTTP/3について書きました。(無料です。 2020年6月時点の内容となっています。概ねQUICやHTTP/3の大枠は固まっており、2021年の内容と照らし合わせても、大きな変更はありません。PDFを下に貼ってあります。 , (宣伝) また、2021年6月にアップデートも含め、WEB+DB PRESS Vol.123に記事を書かせていただいております（有料） gihyo.jp http3-note https://github.com/flano-yuki/http3-note にPDFを置きました 1. はじめに(HTTP/3と概要) 2. QUICについて 3. HTTP/3について 4. HTTP/3 拡張仕様と応用 5. (執筆予定) 実装、ツール紹介 公開形式は、そのうちなんとかするかも 内容 1. はじめに(HTTP/3と概要) 1.1 はじめのはじめ

目次 Origin Policy 有効にさせる方法 試してみる Chromeがオリジン全体にポリシーを適応する「Origin Policy」という仕様をサポートしてるようなので、簡単に試してみる。(現在は Chrome Canaryのみの模様) おそらく仕様及び実装も変わりうるので注意が必要です（極力仕様の変更があったら、記事を更新するようにします） Origin Policy Content-Security-PolicyやFeature-Policyといった、ブラウザがページを表示する際に機能を制限したりセキュリティ上の制限を与える機能があります。これらの機能はレスポンスヘッダに該当のヘッダを付けることでポリシーを適応させることができます。 そのため、これらの機能をもれなく適応するにはレスポンスの都度きちんとこれらのヘッダーを付加しなければなりません。 また、CSPやFeature-P

ブラウザがリソースをFetchするさいに、そのFetchに関するメタ情報をリクエストヘッダに付与するというのがFetch Metadataという仕様です。 この情報を用いれば、画像の読み込みのFetchで銀行用のAPIが叩かれるはずがないといった、明らかな不正なリクエストを検知することができるようになる。 毎度おなじみGoogleのMike West氏によって仕様「Fetch Metadata Request Headers」が書かれている。 以前「Sec-Metadataヘッダについて」で紹介したSec-Metadataをより改良したものです。 ヘッダを分けることでヘッダ圧縮の仕組みとも相性が良くなっています。 Example 以下のような、そのフェッチに関する情報を示すSec-Fetch-*ヘッダが付与される。 Sec-Fetch-Dest: image Sec-Fetch-Mode:

追記20180606 Chrome独自と書いていましたが、「Fetch Standard」に取り込まれていることを確認しました すでに、Chromeで「Cross-Origin Read Blocking (CORB) blocked cross-origin response」というエラーが出るようになっております。imgタグからクロスオリジンでhtmlファイルを取得したり、タグとレスポンスのcontent-typeが一致してない場合に出ます。 もともと、このChromeにCross-Origin Read Blocking (CORB)という機能を実装するという議論が、blink-devのメーリングリストに投稿されています。 「Cross-Origin Read Blocking (CORB)」 に詳しい説明があるので、CORB とはなんぞやと簡単に説明を読んで見る。 CORBはまだC

QUIC, HTTP/3 関連記事 QUICのAckとロスリカバリについて - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP3について) *2019年9月更新 - ASnoKaze blog QUICの話 (QUICプロトコルの簡単なまとめ) - ASnoKaze blog HTTP/3というかQUICの通信がどのように暗号化されているのか勉強がてら軽くまとめる。(執筆時点でQUIC-TLS Draft 19) QUICでは、通信の多くが暗号化されています。アプリケーションデータはもちろんのこ

この記事では、HTTP/3で導入されるHTTPヘッダ圧縮の仕組みである「QPACK 」について説明します。（執筆時 draft 07） 2020/06/01追記 まるっと解説記事を書き直しました asnokaze.hatenablog.com HTTP/2の場合 ハフマン符号 静的テーブル、動的テーブル HTTP/3とQPACKの導入背景 QPACKの概要 Encoder Instructions Decoder Instructions Header Block Instructions 相対インデックス Compressed Headers エラーハンドリング その他 QPACKという名称について HTTP/2の場合 簡単に、HTTP/2で導入されたヘッダ圧縮の仕組みである「RFC7541 HPACK」について補足します。飛ばしていただいても大丈夫です。 HTTP/2の元となったSPD

Cross-Origin-Resource-PolicyヘッダというのがSafari 12でサポートされるらしい。 もともとは、W3C側でFrom-Originと呼ばれていた仕組みらしいが、Fetch Starndardに入れる議論がされているようだ。 github.com このCross-Origin-Resource-Policyヘッダを用いることで、自分サイトでホストしている画像やJavaScriptなどのリソースをクロスオリジンで他所のサイトで表示・利用されることを防ぐことができる。 https://example.com/img.jpg を<img>タグで呼び出せるのはexample.comのサイトだけで、https://asnokaze.comから<img>タグで画像を埋め込んでも表示することができなくなる。 「Cross-Origin Read Blocking (CORB)