Reverse HTTP Transport が描く新しい Web サービスデプロイ構成 | blog.jxck.io
Intro IETF の httpbis で、 Reverse HTTP Transport という仕様が提案されている。 Reverse HTTP Transport https://www.ietf.org/archive/id/draft-bt-httpbis-reverse-http-01.html この仕様は、 Origin サーバの前に何かしら Intermediaries (Loadbalancer, Reverse Proxy, CDN etc)があるのが一般的な現代の Web サービス構成において、非常に革新的なアイデアを取り入れたプロトコルと言える。 まだ v01 という初期段階ではあるが、発想が非常に面白かったので、読書メモを残す。 登場人物 ベースとして HTTP の話にはなるが、登場人物が多いため Client/Server という「相対的な役割」で話をすると、紛
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
RFC の URL はどのドメインで貼るのが良いか | blog.jxck.io
Intro IETF の RFC は、いくつかの場所で同じものが公開されている。 どの URL が最適なのか、という話。 結論は www.rfc-editor.org だ。 RFC Hosting Site 例えば RFC 9110 - HTTP Semantics で言うと、以下の 4 つがある。 https://tools.ietf.org/html/rfc9110 https://datatracker.ietf.org/doc/html/rfc9110 https://www.rfc-editor.org/rfc/rfc9110.html https://httpwg.org/specs/rfc9110.html まずは、これらの違いを簡単に解説する。 tools.ietf.org IETF がホストする RFC は、 tools.ietf.org だった。 RFC 2616: H
Apple によるブラウザエンジン規制の緩和 | blog.jxck.io
Intro 以前から騒がれていた Apple によるサイドローディング周りの緩和について、正式な情報公開があった。 Apple announces changes to iOS, Safari, and the App Store in the European Union - Apple https://www.apple.com/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/ ストアやペイメントの緩和もあるが、ここでは WebKit に関する部分だけを抜粋し、どのような条件があるのかをまとめておく。 筆者が公開情報を読んで解釈したものなので、内容は保証しない。 前提 iOS/iPadOS に入れられるブラウザには、 WebKit を用いる必要が
3PCA 最終日: 3rd Party Cookie 亡き後の Web はどうなるか? | blog.jxck.io
Intro このエントリは、 3rd Party Cookie Advent Calendar の最終日である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie ここまで、 3rd Party Cookie との 30 年に渡る戦いと、 ITP 以降それが Deprecation されるに至った流れ、そして Privacy Sandbox の API について解説してきた。 最終日は、ここまでを踏まえて、来年以降の Web がどうなっていくのかを考えていく。 「Web 史上最大の破壊的変更」の意味 筆者はこのアドベントカレンダーの最初に、これを「Web 史上最大の破壊的変更」と言って始めた。 Web で破壊的変更と言え
なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io
Intro 10 年ほど前に同じことを調べたことがある。 なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codes https://jxck.hatenablog.com/entry/why-form-dosent-support-put-delete 当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。 この問題についてあらためて記す。 仕様策定の経緯 表題の通り、 <form> の method には GET と POST しかサポートされていない。 HTTP には他にも PUT や DELETE といったメソッドもあるのに、なぜサポートされていないのかという疑問から始まった。 仕様が決定した経緯は、以下に残っている。 Status: Rejected Change Descriptio
Cookie2 とは何か | blog.jxck.io
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。 Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を
Compression Dictionary Transport (Shared Brotli) によるコンテンツ圧縮の最適化 | blog.jxck.io
Intro Chrome で Compression Dictionary Transport の Experiment が行われている。 Intent to Experiment: Compression dictionary transport with Shared Brotli https://groups.google.com/a/chromium.org/g/blink-dev/c/NgH-BeYO72E この提案の仕様および本サイトへの適用について解説する。 brotli の Dictionary 圧縮方式は、基本的に「同じ値が出てきたら、それらをまとめて小さく表現する」という方式が中心となる。 # 繰り返しを数値で表現する場合 from: aaaabbbbb to: a4b5 この方式は、対象としたデータの中で、如何に効率よく「同じ値」を見つけるかが肝となる。例えば以下の例
URL バーの表示の変遷 | blog.jxck.io
Intro ついに URL バーから EV 証明書の組織表示が消されるアナウンスが、 Chrome から発表された。 思えば、 URL バーの見た目も、だいぶ変わってきたように思う。 URL バーの表示の変遷を一度まとめておく。 URL バーの再現 本当なら古いブラウザのスクショを集めたいところだったが、これは非常に難しい。ネットで色々落ちてるものをかき集めても、ライセンスや解像度や表示されている URL などを考えると、使い勝手は決して良くない。 試しに古い Chromium をビルドしてみたが、一定より古いものはうまく開くことすらできなかった。開くことができたバージョンもあったが、どうやらそれだけでは当時の URL バーの UI までは再現されないようだ。 そこで、実物のスクショはあきらめ「一般的な URL バーのイメージ」を書いた図で、おおまかな変遷を辿る。あくまで架空の図であること
JavaScript のメディアタイプと RFC 9239 | blog.jxck.io
Intro 長いこと作業が行われていた JavaScript の MIME タイプについての作業が完了し、 RFC 9239 として公開された。 これにより、推奨される MIME タイプが text/javascript に統一されることになった。 かつて推奨されていた application/javascript ではなくなった経緯などを踏まえ、解説する。 JavaScript MIME Types HTTP で Response する際に指定する Content-Type は、その内容がなんであるかを Client に Indicate し、適切な処理を促すために使用される。 例えば HTML が text/html であったりするように、 JS も内容はテキストなので text/javascript が自然に思える。 しかし、例えば MS が実装していた JS 互換の JScript
自作 Markdown プロセッサベースの blog.jxck.io v2 リリース | blog.jxck.io
Intro 本サイトは自作の Markdown ビルダを使っていたが、色々と気に食わない部分があったのでフルスクラッチで作り直し、それにともなってサイトの刷新を実施した。 必要だった要件や、意思決定を作業ログとして記す。 Markdown 本サイトは、一般に使われている Markdown -> HTML の変換結果では要件を満たせないため、最も都合の良い AST を吐く Kramdown のパーサから AST だけを取得し、それを Traverser でカスタマイズしてから自前でシリアライズしていた。 その実装を、微修正を繰り返しながら、継ぎ足し継ぎ足しで 5 年くらいイジってきたので、そろそろ自分がブログを書く上での要件も固まっており、記事中の Markdown のスタイルも固定してきた。 一方、 Kramdown の実装が原因でどうしてもワークアラウンドが必要だった部分に、フラストレー
Private Relay と IP Blindness による Fingerprint 対策 | blog.jxck.io
Intro iOS15 がリリースされたため、 Private Relay のベータを試すことができた。 このようなサービスが提供されるようになった背景を踏まえ、挙動を簡単に確認しつつ、解説する。 背景 そもそも、なぜこのようなサービスが出てきたのかを理解するには、現在のインターネットが抱える問題の背景を理解する必要がある。 特に Web において問題になっている「トラッキング」を防ぐために、法的な規制や業界団体の自主規制による対策は長いこと行われてきたが、それでも看過できないインシデントなどが目立ったために、 Apple の ITP を皮切りに 3rd Party Cookie の制限が始まった。 ここで重要なのは、「本来防ぎたいのは 3rd party Cookie という技術ではなく Tracking というユースケースだ」という点だ。 この前提が伝わっていない場合、トラッキングのユ
mouseover 中に表示される DOM のデバッグ | blog.jxck.io
Update 2024-03-30: Chrome 123 から "Emulate a focused page" が追加された。 これを用いれば良いため、以降の全ての方式は古くなった。 Apply other effects: enable automatic dark theme, emulate focus, and more https://developer.chrome.com/docs/devtools/rendering/apply-effects#emulate_a_focused_page マウスが乗ってないと出ない UI も、そこに Tab などでフォーカスを移し、その状態で Dev Tools の "Emulate a focused page" を有効にすれば良い。 Intro 先日、後輩が「mouseover 中にしか表示されない DOM のデバッグ」に手こずっ
Cross Origin iframe からの alert/confirm/prompt 呼び出しの無効化 | blog.jxck.io
しかし、実際に M92 がリリースされてからは、この機能が壊れたことによる影響が多数報告されていたため、実装者が想定していた以上に影響はあったといえるだろう。 他のブラウザの反応 実際にロールアウトしたのが Chrome/Edge であったため、いつものように「また Google が勝手にやっている」と思う人もいるようだが、実際には他のブラウザも Positive を表明している。 Firefox: https://github.com/whatwg/html/issues/5407#issuecomment-606417807 Safari: https://github.com/whatwg/html/issues/5407#issuecomment-760574422 また、この合意が取れているため、既に仕様にもマージされている。 Add early return to JS dia
Public Suffix List の用途と今起こっている問題について | blog.jxck.io
Intro Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。 実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。 最近、このリストへの追加リクエストがあとを絶たず、問題になっている。 そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。 Public Suffix List とは何か PSL を解説するには、まず関連する用語について整理する。 Top Level Domain (TLD) 例えば、このブログのドメインは blog.jxck.io であり、これは筆者が取得したドメイン jxck.io のサブドメインだ。 jxck.io は、 .io という TLD のサブドメインを販売しているレ
Web 技術の調査方法 | blog.jxck.io
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、 Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって
ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
Site Isolation 及び Web のセキュリティモデルの更新 | blog.jxck.io
Intro Origin は Web におけるセキュリティモデルの一つとして、コンテンツ間の Communication に関する境界を定義し、リソースを保護してきた。 しかし、 Spectre の発覚以降、 Communication に関する制限だけではなく Isolation によるメモリレベルでのアクセス制御が必要となった。 そこで現在作業されているのが、 CORB, CORP, COEP, COOP といった仕様群であり、これは Web におけるセキュリティモデルの更新作業と見ることができる。 概要と現状について解説する。 DEMO & Resources 量が多いため、動作する DEMO と関連リソースは、ページ下部にまとめてある。 CORS による Cross Origin Communication の制限 CORS は、平たく言えば、リソース提供元(サーバ)が、クライアン
3rd Party Cookie 調査のための Web 広告導入 | blog.jxck.io
Intro 昨今、特に広告サービスを中心に 3rd Party Cookie を用いたトラッキングについての議論が多く行われている。 Safari による ITP や、 Chrome による Privacy Sandbox への移行など、技術的な変化も著しい。 こうした技術の変遷を観測し、調査検証を行うために、これまで避けていた Web 広告を本サイトに導入することにした。 Motivation 本サイトは、様々な Web に関する技術を調査し、実際に試すためにサイト自体に適用しながらそれを記事にまとめるという目的で運用してきた。 様々な技術を試したり、そのパフォーマンスやセキュリティへの影響を評価する上で、一般的なサイトの構成とかけ離れていれば、あまり意味をなさない。 そのため、本サイトでは以下のように、別に必要はない機能やサービスをあえて導入している。 AMP AMP より Origi
WebBundle によるコンテンツの結合と WebPackaging | blog.jxck.io
Intro 依存コンテンツを 1 つにまとめて配信する WebBundle の仕様策定と実装が進んでいる。 これは Signed HTTP Exchange と合わせて WebPackaging を実現するための仕様であり、組み合わせれば WebBundle に対して署名することでコンテンツの配信を通信と分けて考えることができる。 Signed HTTP Exchange に比べると格段に簡単な仕様なので、現状のフォーマットと挙動について解説する。 draft-yasskin-wpack-bundled-exchanges-latest WebBundle かつて Bundled HTTP Exchanges と呼ばれていた仕様であり、複数のコンテンツを 1 つにまとめ、配信することができる。 例えば index.html とそれが依存する css/js/favicon etc を 1 つ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
