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 CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
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 Ladybird は、他のブラウザエンジンをフォークせず、企業との取引に頼らず、寄付だけで作ることを宣言した新しいブラウザエンジンだ。 Ladybird https://ladybird.org/ これがいかに価値のある取り組みなのか、 Web を漫然と眺めてきた筆者による N=1 の妄言を書いてみる。 ブラウザエンジンとは ブラウザは、「ブラウザ UI」と「ブラウザエンジン」と、大きく二つの構成要素に分けて考えることができる。 ブラウザエンジンとは、いわゆる Web 標準の技術を片っ端から実装した、ブラウザの土台となるものだ。 ビルドすれば、入力した URL からネットワーク経由でリソースを取得し、パースしてレンダリングして表示できる。そのための IETF RFC や WHATWG HTML や ECMAScript が実装されている、標準技術の結集だ。 その上に、例えばタブ
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 を用いる必要が
Cookie2 とは何か | blog.jxck.io
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。 Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を
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
Intro Chromium にコントリビュートするためには、ソースコードを理解する以外にも、もろもろ必要な周辺知識がある。 ドキュメントはかなり整備されている方ではあるが、そのドキュメントにたどり着くのが難しい場合もある。 レビュアーなどが親切に教えてくれるものをローカルにメモしているが、それも散らばってきたため、ここにまとめることにする。 まずは初期状態で公開するが、どんどん更新していき、長くなっても分割しないで追記を繰り返そうと考えている。 関連サイト 始めて取り組もうとすると、まずどこを見ればわからないところから始まる。 似たようないくつかのサイトがあり、使い分けがされているからだ。 code search https://source.chromium.org/chromium/chromium/src コードをインタラクティブに検索するためのサイト Workspace 風の U
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 という「相対的な役割」で話をすると、紛
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 で破壊的変更と言え
Intro Chrome 126 で筆者が実装した URL.parse が Ship された。 Chromium にコントリビュートしたことは何回かあったが、単体機能を Ship したのは初めてだった。 invalid URL の処理 new URL() によって、文字列の URL をパースすることができるようになって久しいが、この API は invalid な場合に例外を投げる。 例外処理をするよりも、先に URL としてパース可能かどうかを知るための URL.canParse() が提案され、先に実装が進んだ。 URL.canParse(str) // boolean しかし、これでは二回パースが必要になるため無駄が多い。 if (URL.canParse(str)) { // 1 回目のパース return new URL(str) // 2 回目のパース } そこで、失敗したら
Intro 2023 年の Web 技術を振り返る試験として、「Web 技術年末試験 2023」を実施した。 その問題と想定解答、平均点などを公開する。 Web 技術年末試験 この試験は、「去年の Web にはどんな変化があったか」「どんな新しい技術が出てきたか」などを、試験形式で振り返るコンテンツを作ってみたことに端を発している。 2022 年はこれを狭い範囲で実施したが、思った以上に評判が良かったため、 2023 は受験者を一般募集してみることにした。 試験形式であるため点数は出るが、目的は「今年はこんなことがあった」を振り返ることや、「こんなことがあったのは知らなかった」という取りこぼしに気づく機会になることである。 解答用紙/想定回答 [解答用紙]: Web 技術年末試験 2023 https://docs.google.com/document/d/1jdN0NsM-PAnYRl
CFP CFP の募集には fortee を使ってみようと思います。まだ慣れてないので色々と失敗すると思いますが、多めにみてください。(参加募集は fortee ではなく、慣れてる connpass を使う予定です) また、採択は fortee のプロポーサルのスターを第一基準にするので、聞きたいのはスターしてください。(なので、多分応募は早い方が有利です) プロポーザル | Web Developer Conference 2024 - fortee.jp https://fortee.jp/web-dev-conf-2024/proposal/all 募集は Session と LT の 2 枠です。 Session 40 分枠 x 12 Web 開発に関わることならなんでも可 終わったら感想戦会場に移動、そこで QA CFP を Fortee で募集 基本は Fortee のスター数
Intro Referrer-Policy は、送信される Referer の値を制御することが可能だ。 このヘッダの副次的な効果をよく理解していないと、「no-referrer にして送らないのが最も安全だ」という誤解を生むことになる。 では、複数あるポリシーの中でどのような観点で、どのディレクティブを採用するのが良いのだろうか? 前提として前回の記事の「リクエストの出自をチェックすることは現代の実装のベースプラクティスである」という点を踏まえて考えてみる。 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io https://blog.jxck.io/entries/2024-04-26/csrf.html Referer とアナリティクス Referer は、リクエストに対してその前のページの URL を送るところから始まった。 GET / H
Intro TC39 の Stage 2 と Stage 3 の間に、新たに Stage 2.7 が追加された。 これはなんだろうと思った人が、検索で辿りつけるよう、その経緯と目的をまとめる。 TC39 Stages TC39 は、 ECMAScript (つまりまあ JS) の新機能を議論する Task Group だ。 ここでは、比較的自由に新機能の提案がなされ、定期的に行われるミーティングでの議論や、実装からのフィードバックを経て、 Stage が上がっていく仕組みをとっている。 旧来の Stage は 0~4 まであった。ざっくり言うと以下のようなものだ。
3PCA 1 日目: 3rd Party Cookie Advent Calendar Agenda | blog.jxck.io
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 が使えないなら、代わりに何か別の
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 この方式は、対象としたデータの中で、如何に効率よく「同じ値」を見つけるかが肝となる。例えば以下の例
「1 分 de Web 標準」のやり方 at Web Developer Conference 2024 #wdc2024 | blog.jxck.io
Intro 9/7 開催予定の Web Developer Conference 2024 では、 「1 分 de Web 標準」という LT 大会を予定しています。 CFP も募集中ですが、(筆者の周り以外では)聞き馴染みのないやり方だと思うので、この LT のやり方を解説します。 プロポーザル | Web Developer Conference 2024 - fortee.jp https://fortee.jp/web-dev-conf-2024/proposal/all 1 分 de Web 標準 「Web 標準」な何らかのトピックについて、 1 人 1 ページ 1 分で LT するというものです。 Slide スライドはこちらで用意する Google Slides を共有し、そこに割り当てられた 1 ページのみを使えます。 その 1 ページは、マスターで振るページ番号以外は、ど
Intro 「議論だけ」のカンファレンスを、長いこと開催してきた。 個人的には好きなので、他にもあったらいいと思っているが、そういうカンファレンスは他に見ない。 カンファレンス自体を、筆者のような個人が手弁当でやれるのは、もう最後かもしれないと今回ひしひしと感じたので、これまでどうやってきたのかを残しておくことにする。 「議論」だけ 特に日本では、勉強会やカンファレンスは、「スライドの発表会」形式として定着している。 これは、絞られたテーマについて、まとまった形で聴くことができ、資料も後で共有できる点でメリットはある。 しかし、全部がそうである必要はないのでは? とずっと思っていた。 特に懇親会では、雑に集まって、雑に議論が始まり、雑に盛り上がって、勉強になる上に単純に楽しいという経験をした人も少なくないと思う。 スライドで発表する場合は、スライドに収まる話しか出てこない。 30 分しか枠
3PCA 8 日目: P3P | blog.jxck.io
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 の 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 の 19 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今日は Super Cookie の解説をする。迂回手段ゾーンとしては、最後に紹介する手法だ。 Super Cookie Super Cookie は、最初筆者も非常に驚いた、トラッカーの執念を感じる手法だ。 まず前提として、ブラウザのどこかに情報を保存でき、それがある程度の期間永続化され、かつ自動的に取得できるようなものであれば、トラッキングに応用が効く。 そこで目がつけられたのが HSTS (HTTP Strict Transport Securit
Intro 2014 年 3 月に開始した mozaic.fm が、気づいたら 10 周年を迎えた。 これを機に、 10 周年記念イベントとして、初のオフラインイベントをゲンロンカフェで開催した。 Podcast でのみ告知し、当日まで情報制限をかけていたにもかかわらず、チケットもグッズも無事完売することができた。 イベントを振り返りつつログを残す。 10 周年記念イベント mozaic.fm は 2014 年 3 月に配信を開始したが、これまで一度もイベントのようなことをやってこなかった。 2022 年 8 月の ep100 を記念して、一度くらいはオフラインイベントをやってみるかという計画があったが、コロナ禍であったためキャンセルになった。 今回は、そのリベンジも兼ね、リスナーのみに向けたイベントとして開催した。 当日の模様は録音し、一部を mozaic.fm で公開している。 ep1
Intro このエントリは、 3rd Party Cookie Advent Calendar の 21 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie Google が 3rd Party Cookie を Deprecate していく方針を発表してから、最初に始めたのが SameSite Lax by Default だった。 これが何のために行われたのかを解説する。 eTLD+1 とは SameSite とは「eTLD+1 が同じ」という説明になる。これを理解するには eTLD を理解する必要がある。 例として example.com ドメインを持ち、そこに以下のような Cookie を付与するとこ
Intro Promise.withResolvers() は、 Stage 4 であり ES2024 の候補となった。 すでにブラウザでの実装も進んでいるため、その活用方法を解説する。 イベントの Promise 化 JS では、非同期処理 API は長らくイベントリスナベースで定義され、それを組み合わせるフロー制御で処理されてきた。 しかし、 Promise が定義されて以降は、標準 API も Promise を返すようになり、 async/await によって処理されるのが一般的になってきた。 結果、イベントリスナベースの API を Promise 化するような場面も増えた。 例えば以下のようなものだ。 async function request() { return new Promise((resolve, reject) => { document.querySelect
Intro このエントリは、 3rd Party Cookie Advent Calendar の 22 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今日からいよいよ Privacy Sandbox の話に入っていく。 単に塞げば良いのか? 各ブラウザが「3rd Party Cookie をブロックしよう」と合意した。しかし、単に使えなくすればそれでいいのか? というと、実はそんなに簡単ではない。 まず、何度も言っているように、「認証連携」やトラッキング問題とは関係のないポジティブなユースケースまで使えなくなることで、多くのサイトが壊れてしまう懸念がある。 ITP によって壊れたサイトは多く存在したが
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 の 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 の 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 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 このエントリは、 3rd Party Cookie Advent Calendar の 26 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今日からは、 Privacy Sandbox の「広告」以外の API を解説していく。 同一組織の別ドメイン グローバル企業であれば、各国の ccTLD でローカライズされたサービスを提供するのは一般的な運用だ。 google.co.jp google.co.uk google.de google.fr etc 他にも、例えば用途毎にドメインを分ける運用も一般的だろう。 google.com googleusercontent.com fonts.gs
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 の 14 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今日は Safari, Firefox で導入され、その後 Chrome によって標準化されつつある、 Partitioning という概念を解説する。 Partitioning 3rd Party Cookie を塞ぐ上で、「消す」以外にもう 1 つ「分割する」という手法がある。 たとえば、 ads.example の広告を a.example と b.example が <iframe> で埋め込む時、 ads.example の 3rd Party
Intro このエントリは、 3rd Party Cookie Advent Calendar の 20 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie ここまで ITP について見てきたが、これはあくまで Safari が独断で行っていたことだ。 それに対して、他が追従するかどうかはブラウザ次第だっただろう。 では、他のブラウザはどのような反応をしたか。この反応には、その時の情勢も鑑みる必要がある。 プライバシー事件の多発 2018 年、ITP で広告業界が騒然となっているのと同時期に、「ケンブリッジ・アナリティカ事件」が発生する。 これは、 2018 年にケンブリッジ・アナリティカという選挙コンサルの
2023 年を振り返る | blog.jxck.io
Intro 例年通り 2023 年を振り返る。 blog 今年書いたのは全部で 43 本。今年はアドベントカレンダーを一人でやったため、過去最高のエントリ数になった。 Entry ブログは 15 本書いた。 2023-01-07: 次世代 CSS 仕様が与えるコンポーネント時代の Web への影響 2023-02-28: 誇りを被った仕様の針に意図を通す 2023-03-24: OpenAI API を用いた文書校正(誤字脱字検出) 2023-05-02: 技術書籍をシンタックスハイライトする話 2023-05-17: IETF RFC における ABNF と Parsing Algorithm の関係 2023-05-28: URL バーの表示の変遷 2023-06-01: AbortSignal.any(), AbortSignal.timeout(), そして addEvnetLis
3PCA 9 日目: DNT | blog.jxck.io
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 の 18 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今日は、 ITP の迂回で注目された Cloaking について解説する。 Cloaking これが今、トラッカーが最も期待している 3rd Party Cookie の迂回技術だろう。 例えば、広告やアナリティクスなどなんらかのトラッカーを 3rd Party として利用している場合は、今後 3rd Party Cookie での連携ができなくなる。 そこで、そのトラッカーサービス自体を自分のサブドメインで運用してしまえば、 eTLD+1 が同じになり
Intro このエントリは、 3rd Party Cookie Advent Calendar の 16 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今日は 3rd Party Cookie の迂回としてトラッキングに用いられた、 Bounce Tracking について解説する。 Bounce Tracking 例として、 X でポスト中のリンクをクリックすると、 t.co というドメインに一旦遷移し、そこでリダイレクトしてから目的の URL に遷移する作りになってる。 このように、「一旦リダイレクトを挟む」のは、X からすれば、 t.co のログを見ることで、誰がどのポストを見て、どのサイトに離脱
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 の 23 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今回からは、 Privacy Sandbox の API を、ジャンルごとに分けて概要を解説していく。 個々の API は非常に複雑であり、また今後も細かい点が変わっていくだろう。 どうせガッツリ使うのであれば、仕様を読む必要があるため、ここでは「何がしたいのか」「何ができるのか」に絞って解説する。 Interest Based Advertising FLoC 広告表示時に「このユーザは何に興味があるのか」というインタレストを知ることは、表示する広告を
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ブラウザでリロードしながらキャッシュの挙動を確認してる全ての開発者へ | blog.jxck.io
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io
なぜブラウザエンジンは 1 つではダメなのか? または Ladybird への期待 | blog.jxck.io
Apple によるブラウザエンジン規制の緩和 | blog.jxck.io
RFC の URL はどのドメインで貼るのが良いか | blog.jxck.io
Chromium にコントリビュートするための周辺知識 | blog.jxck.io
Reverse HTTP Transport が描く新しい Web サービスデプロイ構成 | blog.jxck.io
3PCA 最終日: 3rd Party Cookie 亡き後の Web はどうなるか? | blog.jxck.io
URL.parse を Chromium で Ship するまで | blog.jxck.io
Web 技術年末試験 2023 講評 #web_exam2023 | blog.jxck.io
Web Developer Conference 2024 開催告知 #wdc2024 | blog.jxck.io
Referrer-Policy の制限を強めると安全になるという誤解 | blog.jxck.io
TC39 に新設された Stage 2.7 について | blog.jxck.io
「議論だけ」のカンファレンスの作り方 | blog.jxck.io
3PCA 3 日目: 自動で送られる Cookie | blog.jxck.io
3PCA 19 日目: Super Cookie | blog.jxck.io
mozaic.fm 10 周年記念イベント開催後記 | blog.jxck.io
3PCA 21 日目: SameSite Cookie | blog.jxck.io
Promise.withResolvers によるイベントの Promise 化 | blog.jxck.io
3PCA 22 日目: Privacy Sandbox | blog.jxck.io
3PCA 11 日目: Cookie Banner | blog.jxck.io
3PCA 4 日目: 3rd Party Cookie の正体 | blog.jxck.io
3PCA 6 日目: トラッキングの問題 | blog.jxck.io
次世代 Web カンファレンス 2023 開催告知 | blog.jxck.io
3PCA 26 日目: Related Website Sets | blog.jxck.io
3PCA 7 日目: Cookie2 | blog.jxck.io
3PCA 14 日目: Partitioning | blog.jxck.io
3PCA 20 日目: 3rd Party Cookie Deprecation | blog.jxck.io
3PCA 18 日目: Cloaking | blog.jxck.io
3PCA 16 日目: Bounce Tracking | blog.jxck.io
3PCA 2 日目: Cookie による区別と識別 | blog.jxck.io
3PCA 23 日目: Interest Based Advertising | blog.jxck.io