ITP おさらい

• Third-party cookie を実質ほぼ block
• First-party cookie も条件付きで制限
• 詳しくは前回の ep.16 参照

ITP 2.3 差分

• localStorage への制限が追加
  • 7日間操作がないと全て削除
• document.referrer がダウングレード（ドメインのみが参照できるように）

https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/

Storage Access API (W3C標準)

iframe を使ったユースケースを想定

• SNS の埋め込みタグ
• Third-party サービスによる決済
• 月額課金制の動画視聴サービス サードパーティクッキーで出来ていたことをカバーするためのものではなくあくまでいくつかのユースケースに対するサポート。

https://github.com/privacycg/storage-access

プライバシー観点以外でもサードパーティクッキーがなくなると良い点

クロスサイトリクエストフォージェリ（CSRF）おさらい

1. ウェブサイトにログインした状態で認証情報が cookie に焼かれる その認証情報を使ってユーザーの秘密の情報を取得できる状態とする
2. 攻撃者が用意した全く別ドメインのページからECサイトに対して購入履歴を取得するリクエストを行う

この時サードパーティクッキーが有効で何の備えもない場合第三者に秘密の情報が渡ってしまう 横浜市のサイトに過去脆弱性があり、ウェブサイトを踏んだだけで襲撃や殺人などの犯行予告を「させられる」事件があった。 これまでは開発者が気を使わなければいけなかったところが、ブラウザによっても保護されるようになっていく。

Chrome も2年以内をめどに追従

• 最近の対応としては SameSite Cookie の仕様変更
• サードパーティのCookieをブロックすればビジネスに影響を与える
• 何も対策せず禁止してしまえば fingerprinting などの技術の利用を逆に推進してしまう

Privacy Sandbox

広告向けのソリューション。まだ始まったばかり。 広告主は何をしたいんだろう？色々あるけれど…

• 特定の行動をした(商品を買うなど)ユーザーに役立つ商品を紹介したい（リターゲティング）
• 特定の属性を持つユーザー（20代男性など）に興味のありそうなコンテンツを紹介したい（属性ターゲティング） そのために…
• 「購入した」「閲覧した」という情報をユーザーの識別子(cookie id)付きでサーバーに送る
• 識別子を使ってどんな広告を表示すべきかリクエストする これからは？
• 「購入した」「閲覧した」という情報をサーバーに送らずにブラウザの中に蓄積する
• 識別子ではなくlocalに蓄積されたデータからセグメントを抽出し広告サーバーにリクエストする
• 「どんなユーザーか」というセグメントを抽出するための元データはいつでもユーザーの管理下（ローカル）にある

フロントエンドエンジニア観点で

• 無料で便利なものが提供される世界
  • 広告とプライバシーの共存が必要
• 沢山のデータをクライアントサイドで扱うようになるかもしれない
  • Webアプリケーションの開発以外でもブラウザやWeb標準技術に詳しいフロントエンドエンジニアが求められてくるかも

Refs

• BGM&SE
  • 魔王魂/騒音のない世界/OtoLogic