個人情報を共有しないように要求する Sec-GPC リクエストヘッダ - ASnoKaze blog
W3CのPrivacy Community Groupでは、Webのプライバシーについて取り組んでいます。 その取り組みとして「Global Privacy Control (GPC)」というドキュメントが書かれています。このドキュメントでは、ユーザが個人情報を共有しないように要求する Sec-GPC リクエストヘッダが定義されています。 多くのWebサイトでは個人情報の取り扱いについてオプトアウト方法を提供していますが、ユーザが個々にオプトアウトを行うよりか簡単な手段を提供するというモチベーションがあるようです。 また、この仕様は、各国のプライバシー法などの法的枠組みにおけるオプトアウトの意思表示として扱えることを意図しているようです。 Firefoxでも実装が進められています。 Intent to Prototype: Global Privacy Control Sec-GPC リク
ブラウザからPCの負荷状況を取得する Compute Pressure API - ASnoKaze blog
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の開発版で動作確認でき
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
クエリパラメータ付きURLのキャッシュを改善する No-Vary-Search ヘッダ - ASnoKaze blog
キャッシュのキーとしてURLが使われます。このときURLのクエリパラメータも含めて考慮されます。 特定のクエリパラメータは、分析や別様とでアクセスログに残すために使われたりしますが、提供するリソースが変わらない場合があります。そのケースであれば、クエリパラメータが付いてたとしても、キャッシュがあればキャッシュを使ってもらいたいものです (ここでキャッシュは、HTTPキャッシュ及び、prefetchやprerenderを指します)。 そのため、クエリパラメータが付いている場合の扱いを改善する No-Vary-Search レスポンスヘッダ が、Chromeの方中心に議論されています。 github.com 例 No-Vary-Search レスポンスヘッダの例として次のものが上げられている クエリパラメータのキーの順序を考慮しない No-Vary-Search: key-order特定のクエ
Webサイトを離れたときにデータを送る Page Unload Beacon (Pending Beacon API) - ASnoKaze blog
Webサイトを離れたときにサーバにデータを送れるようにする「Page Unload Beacon」という仕組みが、W3CのWICGで議論されています。 既存のページのライフサイクル(unloadイベントやbeforeunload)で、サーバにデータを送ろうとしても処理されないことがあります。そのため、ページのunload時にビーコンを送るように登録できるようにするのが「Page Unload Beacon」です。 最新のChrome Canaryでとりあえず動くっぽいので、触ってみる (まだ動作するだけで、一部仕様と異なります) Page Unload Beacon デベロッパーツールから次の通り実行して、Beaconを登録しておきます。今回はGETリクエストとPOSTリクエストのビーコンをそれぞれ登録。 getbeacon = new PendingGetBeacon("http://e
デフォルトでCookieをオリジンに紐づける、ChromeのOrigin-Bound Cookies - ASnoKaze blog
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
一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
セキュリティの報告先を記述する、security.txtの提案仕様 (RFC9116) - ASnoKaze blog
Webサイトのセキュリティリスクを発見したものの、連絡先が適切に公開されていないがために、結局報告されず脆弱性が放置されるケースがあるようだ(国内だと、IPA脆弱性関連情報の届出受付もあるが) 発見者が脆弱性等の報告を出来るような情報を、Web作成者が提供できるようにする仕様がIETFに提出されている。 この「A Method for Web Security Policies」という提案仕様では、security.txtをドメイン直下のURLに配置し、連絡先などを記述するようになっている。 security.txt security.txtは例えば以下のとおりである # Our security address Contact: security@example.com Contact: +1-201-555-0123 Contact: https://example.com/secur
Webサイトのバグの報告先を示す contributing.txt - ASnoKaze blog
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
CSPの仕様に report-sample が追加された - ASnoKaze blog
まだ、WIPではあるもののCSPの仕様に "report-sample" と言う機能が追加されました(URL)。 これは、違反したインラインのScriptやStyleの最初の40文字がレポートに追加されます。外部ファイルの場合はレポートされません。昨年から議論がされていましたが、もともとはFirefoxに以前実装されていたscript-sampleプロパティと同等の機能ですが、Styleも対象になります。 これにより、今までレポートは送られてくるもの攻撃なのかそうじゃないのか分からなかったというケースが、多少なりとも少なくなるのではないだろうか。 すでに、Chromeへの実装が進められています(URL) report-sample 普通のCSPと同様に、HTTPヘッダもしくはmetaタグで report-sampleを指定します。 Content-Security-Policy: scri
QUICのマルチキャスト拡張 - ASnoKaze blog
QUICを使ってマルチキャスト配信を可能にする「Multicast Extension for QUIC」という仕様が、AkamaiのJake Holland氏らによって提案されています。 マルチキャストでデータを配信することで、よりネットワーク帯域を効率用使うことが出来ます。 まだ最初の提案であり、まだTBDとなってるところもあり、これから変わりそうだが一旦目を通しておく。 背景/関連動向 まず、この「Multicast Extension for QUIC」登場と、関連状況について簡単に説明します。 AkamaiのJake Holland氏はWebでマルチキャストを使うために幅広く活動されています。今回の「Multicast Extension for QUIC」もWebでコンテンツを配信するための流れでの提案となっています。（もちろんただのQUIC拡張ですので、用途はそれに限りません
新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等
大体の位置情報を示す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
HTTPレスポンスボディを送ったあとに、Cache-Controlを変更可能にする仕様 - ASnoKaze blog
HTTPでキャッシュは、サーバがHTTPレスポンスを返す際、Cache-Controlヘッダをつけることで、どのようにキャッシュするか指示することができます。ヘッダ自体はレスポンスボディより前に送る必要があります。 Mark Nottingham氏らによって提案された「Updating HTTP Caching Policy in Trailers」という仕様では、HTTPレスポンスボディを送り終わってから、Cache-Controlを変更可能にします。 具体的には、Trailer FieldでCache-Controlを送った際の挙動について定義を与えています。 HTTP Trailer Field まずは、Trailer Fieldについて説明します。 HTTPのセマンティクスの仕様(URL)では、HTTPボディを送ったあとにあとからヘッダ(正確にはFieldと呼ぶ)を送ることができま
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
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がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中
JS Self-Profiling API とは - ASnoKaze blog
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でサンプリングプロファイラを実装したが正確性とパフォーマンスの欠点
Double-keyed HTTP cache に関するメモ - ASnoKaze blog
201909027追記 Fetchの仕様にプルリクが出されています HTTP cache partitioning by shivanigithub · Pull Request #943 · whatwg/fetch · GitHub whatwgでfetchに関して「Double-keyed HTTP cache」という議論がされています。 github.com ブラウザ側でも動きがあり、下記で議論がされています Chromeでは「Intent to Implement: Partition the HTTP Cache」 Firefoxでは「Intent to Implement- Double-keyed HTTP cache」 背景 HTTPのキャッシュは、そのリソースがどのページ(ドメイン)で読み込まれたかに関わらずに共有で使用されます。しかし、そのキャッシュ状況をサイドチャネ
ブラウザのネットワークエラーをレポートさせるNetwork Error Loggingが来た - ASnoKaze blog
20180727追記 CORS対応が必要になりました asnokaze.hatenablog.com 20180703追記 ドキュメントはhttps://w3c.github.io/network-error-logging/ にが移されました 20180608追記 仕様上は、jsonの各値はハイフンではなく、アンダースコアを使用するようになります report-to => report_to max-age => max_age ... etc https://github.com/WICG/network-error-logging/commit/86c4d1c0fa4c5d5ca1d8bdcd9fa931e7e4ab65c2 こんな感じ nel: {"report_to": "network-errors", "max_age": 2592000, "include_subdomai
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
