サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ニコニコ動画
blog.jxck.io
Intro このエントリは、 3rd Party Cookie Advent Calendar の 12 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie ふりかえり さて、ここまでの話を一旦振り返ろう。 Cookie は保存されたら次から自動で送られる。 ログインしてユーザの「識別」に使えるが、認証しない「区別」にも使える。 3rd Party にも送られ、トラッキングや認証連携などに使える。 プライバシー保護の観点から、長い間トラッキングが問題になっていた。 問題の本質は「Cookie という機能」ではなく、その「ユースケース」にある。 ユースケースを絞るための Cookie2、P3P、DNT などはこ
Intro このエントリは、 3rd Party Cookie Advent Calendar の 11 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 前回は、各国で法律が整備されていった流れや、主な法律の特徴を解説した。 しかし、法律はあくまで法律であり仕様ではないため、「どう実装するべきか」は各サービスに委ねられている(ガイドラインなどはあるが)。 多くの場合これを Web の実装に落とし込むと、いわゆる「Cookie バナー」相当になるわけだ。 今回は、実世界でどのようなバナーが提供されているのかを見ていく。 Cookie Banner "Cookie Banner", "Cookie Notic
Intro このエントリは、 3rd Party Cookie Advent Calendar の 9 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今回は、 P3P の後に提案され、非常に似たコンセプトかつ最近まで使われていた DNT について解説する。 Do Not Track List 6 日目に、トラッキングからのオプトアウト方法は、基本的に三種類あるという話をした。 オプトアウトを示す Cookie を保存し、それを送られた広告ネットワークはトラッキングしない トラッキングしている業者のリストを作り、それをブラウザなどに読み込んで設定する ユーザの意図をなんらかの方法で表明する(ブラウザからオ
Intro このエントリは、3rd Party Cookie Advent Calendar の 8 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今回は、Cookie2 が失敗した後に、別のアプローチでこの課題に挑んだ P3P を解説する。 P3P (Platform for Privacy Preferences) P3P は W3C では 1997 年頃から作業が始まり、2002 年に 1.0 が Recommendation になっている。 The Platform for Privacy Preferences 1.0 (P3P1.0) Specification (w3.org) https
Intro このエントリは、 3rd Party Cookie Advent Calendar の 7 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie ここからは第二幕、人類と 3rd Party Cookie の闘いの歴史を見ていく。 「歴史の話はいらない、早くコードを見せろ」と思っている読者の気持ちもわかるが、残念ながら背景がわかってないとまともな闘いはできないだろう。 Cookie2 この話は、すでに別のエントリで詳細に書いたが、このアドベントカレンダーに併せて要点のみを抜粋する。 Cookie2 とは何か | blog.jxck.io https://blog.jxck.io/entries/20
Intro このエントリは、 3rd Party Cookie Advent Calendar の 6 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 前回は、3rd Party Cookie にはネガティブ/ポジティブ含め、さまざまなユースケースがあるという解説をした。 では、なぜ 3rd Party Cookie は今「問題」になっているのだろうか? トラッキング 前述したリターゲティングの例を思い出してみよう。 例えば媒体主(前述の例で言う Yahoo)に表示された広告主(前述でいう楽天)の広告をクリックし、実際にユーザがミネラルウォーターを購入したら、楽天から Yahoo に成果報酬が入ることにな
Intro このエントリは、 3rd Party Cookie Advent Calendar の 5 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 前回は、 3rd Party Cookie を使った広告のリターゲティングの仕組みを解説した。 「あの気持ち悪い広告の正体は 3rd Party Cookie だったのか」と思った人もいるかもしれない。 そんな諸悪の根源である 3rd Party Cookie など「さっさと無効にしてしまえばいいのでは?」と思うかもしれないが、それは簡単なことではない。なぜなら、3rd Party Cookie のユースケースは、ネガティブなものだけではないからだ。 その
Intro このエントリは、 3rd Party Cookie Advent Calendar の 4 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 前回は「サブリソースにまで Cookie が送られて何が嬉しいのか」という話だった。 今回はそのユースケースについて考えていく。 「さっき見てた商品が出る」のからくり 例えば、 EC サイトで色々な商品を探した後に、全然関係のないサイトで、なぜかさっきまで見ていた商品がそのサイト内でおすすめされている、という経験があるだろう。 今回はリアルワールドの例として、楽天の実装を引用する。 まず、楽天市場のサイトでミネラルウォーターを物色する。 その後、 Yaho
Intro このエントリは、 3rd Party Cookie Advent Calendar の 3 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 前回は 「Cookie は 区別 と 識別 の用途があり、 区別 だけのユースケースもある」という解説をした。 今回も、もう少し Cookie の性質を振り返っていく。 保存したドメインに自動で送り返す ブラウザは Set-Cookie してきたサイトを覚えておき、そのサイトにアクセスするたびに Cookie ヘッダで自動で送り返すという話だった。 例として、EC サイトにログインし Cookie が振られた場面を考える。 POST /login HTTP
Intro このエントリは、 3rd Party Cookie Advent Calendar の 2 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie Cookie とは 例として、 https://example.com が以下のようなレスポンスを返すとする。 HTTP/1.1 200 OK Content-Type: text/html Content-Length: 1024 Set-Cookie: deadbeef <!doctype html> ... ブラウザは次に https://example.com にアクセスするときは、必ずこの Set-Cookie の値を Cookie に載せて返す
Intro このエントリは、 3rd Party Cookie Advent Calendar の 1 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie Agenda 2024 年は、いよいよ 3rd Party Cookie の Deprecation が本格的に開始される。 これは端的に言えば「Web の歴史上最大の破壊的変更」と思って差し支えない。 一方、そのインパクトに対してエコシステム側に万全の準備が整っているかというと、決してそうとは言えない。 そもそも事態を認識していない人もいれば、大した影響を想定していない人もいるだろう。 「3rd Party Cookie が使えないなら、代わりに何か別の
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
Intro 2023/12/16(土) に、 3 回目となる「次世代 Web カンファレンス」を開催します。 次世代 Web カンファレンス 2023 - connpass 名称: 次世代 Web カンファレンス 2023 日時: 2023/12/16(土) 11:00-20:00 場所: サイボウズ 参加費: 無料 配信: なし アーカイブ: 未定 懇親会: なし 入場規制: あり ハッシュタグ(全体): #nwc_all Schedule [x] 10/23: 日程告知 [x] 11/01: 詳細公開 [x] 11/16: 募集開始 [ ] 11/30: 抽選終了 [ ] 12/16: 本番当日 Motivation 「Web について話す場」 というか「Web そのものをテーマにした場」というのが、意外と少ないなとずっと思っていました。 (もちろん、結果として Web について話して
Intro こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。 「ブラウザでキャッシュがヒットしない」 以下は、 Web における Caching の FAQ だ。 サーバで Cache-Control を付与したのにキャッシュがヒットしない サーバで ETag を付与したのに If-None-Match が送られない サーバで Last-Modified-Since を付与したのに If-Modified-Since が送られない 先日も、筆者が書いた MDN の Cache セクションで「記述が間違っているのでは?」と同様の質問を受けた。 Issue about the Age response header and the term "Reload" · Issue #29294 · mdn/content https://github.com/mdn/cont
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。 Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を
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 この方式は、対象としたデータの中で、如何に効率よく「同じ値」を見つけるかが肝となる。例えば以下の例
Intro JS から Cookie を操作する document.cookie の改善を目的とした Cookie Store API についてまとめる。 document.cookie document.cookie は、ブラウザの API における代表的な技術的負債の一つと言える。 HTML Standard https://html.spec.whatwg.org/multipage/dom.html#dom-document-cookie 基本的な使い方は以下だ。 document.cookie = "a=b" console.log(document.cookie) // a=b まず、この API の問題を振り返る。 同期 API 最も深刻なのは、 I/O を伴いながら、同期 API として定義されているところだ。 この API は古くから実装されているため、I/O は非同期
Intro 最近 AbortSignal.any() が提案され、急速に実装が進んでいる。 すでに定義されている AbortSignal.timeout() や addEventListener() への Signal なども含め、非同期処理の中断を実装する際の API はかなり整備されてきた。 これら API のモチベーションと設計を中心にまとめる。 Abort 後のリソース解放 AbortSignal によって、非同期処理のキャンセルが可能になった。例として、 Server 上での Fetch のタイムアウトの例を考えよう。 app.get("/entries", async (req, res) => { const perRequestController = new AbortController() const perRequestSignal = perRequestCont
Intro ついに URL バーから EV 証明書の組織表示が消されるアナウンスが、 Chrome から発表された。 思えば、 URL バーの見た目も、だいぶ変わってきたように思う。 URL バーの表示の変遷を一度まとめておく。 URL バーの再現 本当なら古いブラウザのスクショを集めたいところだったが、これは非常に難しい。ネットで色々落ちてるものをかき集めても、ライセンスや解像度や表示されている URL などを考えると、使い勝手は決して良くない。 試しに古い Chromium をビルドしてみたが、一定より古いものはうまく開くことすらできなかった。開くことができたバージョンもあったが、どうやらそれだけでは当時の URL バーの UI までは再現されないようだ。 そこで、実物のスクショはあきらめ「一般的な URL バーのイメージ」を書いた図で、おおまかな変遷を辿る。あくまで架空の図であること
Intro HTTPBis では、 RFC 8941: Structured Field Values (以下 SFV) の更新作業が行われている。 RFC 8941: Structured Field Values for HTTP https://www.rfc-editor.org/rfc/rfc8941.html 機能面では Date 型が追加されるという点が大きいが、個人的にはその裏で行われるもっと興味深い議論に注目したい。 それは、「RFC における ABNF の立ち位置」に関するものだ。 ABNF と Parsing Algorithm SFV は、簡単に言えば HTTP Field Value のための構造化フォーマットで、 JSON がそのまま使えなかったことに対する代替仕様だ。よって、基本的には目的となる構造体と文字列フォーマット間の Encode / Decode が
Intro 「連載するけど、代わりにコードはハイライトさせてほしい」 それが Web+DB Press 編集長に俺が出した条件だった。 技術書籍のシンタックスハイライト エンジニアは普段から、エディタ上でも、リポジトリ上でも、ブログ上でも、何かしらハイライトされたコードを見ている。 そんなエンジニアに向けて書かれた技術書籍でありながら、書籍のコードがハイライトされているのはみたことがない。 「技術書籍がシンタックスハイライトされてないのは、出版社の怠慢だ」 と、割と本気で思っていた。そして、今でも思っている。 特にページを跨ぐような長いサンプルコードを、単色で印刷されても、正直読む気になれない。 白黒だからしょうがないと思われているかもしれないが、白黒だとしても、文字の太さ、濃淡、フォントの微妙な使いわけなどで、かなり見やすくすることができる。 今はやっていないが、このブログでも、印刷用の
Intro OpenAI の API を用いて、長年の課題だった文書校正を VSCode 上で実現するプラグインを修作したところ、思った以上の成果だった。 文章校正と誤字脱字検出 執筆を補助するツールは多々開発されているが、基本は形態素解析を用いた品詞分析の延長で行うものが多かった。 よくある「助詞の連続」、「漢字の開き閉じ」、「一文の長さ」などは、ある程度の精度で検出可能ではあるが、結局執筆時に一番検出して欲しいのは「誤字脱字」だ。 文体をどんなに揃えたところで、誤字脱字があるとやはりクオリティが低く感じるし、そこさえ抑えられていれば、他のスタイル統一は訓練である程度なんとかなる。 英語のスペルチェックはかなり進んでいるが、日本語においてはそこまで革新的なものが見当たらない。あらゆるツールを試したが、結局満足のいく精度が出る誤字脱字検出は「Word の校正機能」しかなかった。 そこで筆者
Intro Interop 2022 の目覚ましい成果の一つとして :has() の存在がある。 これまでの CSS の限界を突破する、革新的な仕様であり、多くの開発者が期待を寄せる機能の一つだろう。 こうした仕様策定の裏には、必ずと言って良いほど互換性の問題がつきまとい、時にそれはそこまでの作業の蓄積を無に帰すレベルで影響を与える場合がある。 一方それらは Web 開発者が使う時点では解決されており、基本的に気にされることはない。 だからといって、気にする必要がないわけではない。ということを象徴する事件が、今回も裏で起こっていた。 jQuery と :has() :has() は、従来の CSS Selector の常識を変え、子の状態を元に親をクエリすることが可能となった。親から子を見る場合と比べて探索範囲が爆発的に増えるため、非常に実装が難しいとされていた。 Igalia の詳細な調
Intro SPA の隆盛で進化したフロントエンドライブラリによって生み出された「コンポーネント」という資産は、それを View 層の最小単位として扱うエコシステムにその重心をずらした。 近年の Web 開発は、虫食いのテンプレートエンジンにデータをはめ込む方式から、デザインシステムにカタログされたコンポーネント群に、 API から取得したステートを流し込み、それらを「いつ、どこで、どう」レンダリングするかという課題への最適解を、各位が模索するフェーズとなっている。 コンポーネントを敷き詰めるコンテナ側の設計は、 Flexbox および Grid の登場によるレイアウトの進化が手助けしたところも多いにある。しかし、「ページ」を前提に設計された CSS は、「コンポーネント」を前提にした設計に移行するうえで、ミッシングピースが多かった。 現在、提案/実装が進んでいる CSS の新機能群には、
Intro 例年通り 2022 年を振り返る。 blog 今年は 10 本書いた。 CORB から ORB へ XMLHttpRequest とはなんだったのか HPKE とは何か HTTP 関連 RFC が大量に出た話と 3 行まとめ JavaScript のメディアタイプと RFC 9239 Navigation API による「JS での画面遷移」と SPA の改善 Markdown の Table 記法を CSS で実現する サイトの HTTP3 化と DNS HTTPS RR および Alt-Svc Header によるアドバタイズ 画像最適化戦略 AVIF 編 少し Blog を書く時間を取れてなかったところがある。 今年は mozaic.fm の収録が倍に増えたこともあるので、多少はそれに甘えた気がするが、来年からは目標の月一本のペースに戻したい。 また、今年はあまりこのサイ
Intro CORB (Cross Origin Read Blocking) が Fetch の仕様から消え、後継の ORB (Opaque Response Blocking) が策定作業中である。 ここでどのような変更が起こっているのかを調査し、記録する。 CORB CORB はもともと、 Spectre に端を発する Site Isolation の走りとして始まった。 Spectre のサイドチャネル対策のためには、本来アクセスできてはならない Cross Origin のリソースが、同一のプロセスに展開されることを防ぐ必要がある。 CORS で行われるなら良いが、 no-cors な読み込みが可能なリソースでは、その読み込みが安全かどうかは別途確認する必要がある。 そこで、リソースをメモリ上に展開するためだけの、攻撃用途くらいしかあり得ないようなリソース読み込みをブロックする対
Intro Fetch API の実装が広まり、 IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命
Intro HPKE (Hybrid Public Key Encryption) が RFC 9180 として公開された。 RFC 9180: Hybrid Public Key Encryption https://www.rfc-editor.org/rfc/rfc9180.html HPKE は、公開鍵暗号方式と共通鍵暗号方式を組み合わせて(ハイブリッド)任意の平文を暗号化するための、汎用的な枠組みとして標準化されている。 この仕様は、多くのユースケースが想定されており、 RFC になる前から ECH (Encrypted Client Hello), MLS (Message Layer Security), OHTTP (Oblivious HTTP) など、さまざまな仕様から採用を検討されている。 本サイトで書く予定の他の記事でも HPKE は頻出する予定であり、今後より多く
Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field
次のページ
このページを最初にブックマークしてみませんか?
『Index | blog.jxck.io』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く