shiodaifuku.io

third-party cookieと2020年

この記事はしおだいふく Advent Calendar 2020 22日目の記事です。 気づけば終わりが見えてきました。

今日は僕が2020年に戦ったthird-party cookie問題と、2020年末時点での状況と今後の展望をまとめておこうと思います。

特に結論のないうえに、多くの人には役に立たないであろう僕の自分用メモです。 というのも、third-party cookieが真に問題になるのはそれをトラッキングに利用している広告屋さんか、第三者に向けてfederated loginを提供しているプラットフォーム屋さんくらいであり、 自分たちのビジネスがどちらにも依存していないWeb屋さんは概ね我関せずのスタンスを貫くことができるからです。

とはいえ、広告を掲載しているWebサイトはこのへんの事情の煽りを受けて対応を迫られる可能性があるかもしれないので、 ちょっと知っておくくらいはしたほうがいいかもしれません。

今日はモバイルの2大巨頭ブラウザであるSafariとChromeに絞って話しますが、この2つだけでも地獄のような状態なのでEdgeとかFirefoxまで見た場合の状況はお察しください。

2020年末時点でのおおよその状況

SafariはITPによって3rd party cookieが利用できなくなっています。 Safariとしては、Storage Access APIを代替手段としてつかってほしいようです。 このAPIはInternet Explorer以外の主要なモダンブラウザで利用可能ですが、まだ標準化のプロセスにはのってなさそうです。

Storage Access APIはfederated loginの一部のユースケースに対応できておらず、完全な代替とはなりえないことがわかっています。

また、Safariでは暫定措置としてTemporary Compatibility Fixとよばれる機能を利用することできます。 これは、first partyのページに埋め込まれたiframeや、first partyのページからポップアップした別タブの内部でユーザインタラクション1を取ることによって session storageと同等の期間にわたってthird-party cookieの利用を認めるものです。

ユーザインタラクションを取るというのは広告屋さんには難しく、federated loginにとっては(若干のUX劣化が起こりますが)そんなに難しい話ではないということで、 これを利用するのが現在の落とし所となっています。いつまで使わせてもらえるかはわかりませんが。

Chromeのほうでは、現時点でthird-party cookieがまだ利用可能です。 ただし、2022年にthird-party cookieの完全抹殺が宣言されており、とりわけプラットフォーム屋としては (自分たちが対応を済ませた後でプラットフォーム利用者の側にも何らかの対応をしてもらうことになるので)時間的な猶予はそんなにない状況です。

Chrome側の想定している代替手段としてはFirst-party SetsとTrust Token APIあたりが挙げられるでしょうか。

この問題の難しいところ

大きなデッドラインが2022年に設定されているにも関わらず、ブラウザ屋さんの間で合意に至った、統一された&標準化されそうな方式が今のところないのが最大の苦しみポイントですね。 全部のブラウザに対応するために上述した対応手段を全部詰め込んでいく、みたいな力技以外に対応策がありません。

結論が出るのを待ってもいられなそうですし、どこかで見切り発車せざるを得なくなりそうです。 プラットフォーム屋としては、いじる場所が認証認可周りで影響範囲も広く重要度も高いところなので非常につらいです。

怪しい迂回策はとらないほうが良さそう

既存の技術をこねくり回してなんとか問題を回避する方法がなくはないのですが、iOS14.2におけるCNAME規制2のようにだいたい封じられるので、 おとなしくブラウザが用意する方法に乗っかるしかなさそう(なのにブラウザごとに異なる対応が必要)なところが辛いポイントその2です。

そしてこのthird-party cookie規制が安全なWebを作るための第一歩に過ぎないという点にも注意が必要です。 ひとつひとつの取り組みが最終的に目指している世界をちゃんと見据えて、それに反するような行いは最初から避けておくほうが長期的には賢明と言えます。 ここで変なオリジナリティを発揮して規制を迂回しても、行き着く先は新たな規制です。

規制はどんどん厳しくなる(だろう)

いまのところはfirst-partyがどうとかthird-partyがどうとかいう問題に終始していますが、 どうせこれからはlocal storageとかindexed DBとかも期限付きストレージになったりしていくに決まっています3

長期間セッションを頑張って維持してログイン画面をなるべく出さないような方針でやっているとそのうち苦しむことになるでしょう。 直近でやるべきこととしては、今よりも高い頻度でログインを求められても苦にならないUXを研究しておくとか、 ユーザエンゲージメント4を高めるようなサイト作りとか技術(WebならPWAとかですかね。これもブラウザ差分があって辛いけど)に習熟しておくとかが大事なんじゃないでしょうか。

まとめ

まったく夢もキボーもありゃしない。 5

余談: プラットフォーム屋の苦悩

third-party cookieの問題を大雑把に抽象化すると、Cookieの発行者が、そのCookieが発行されたサイトを超えてユーザを識別することができてしまう点がよろしくないとされています。 広告のトラッキングもプラットフォームのfederated loginも本質的に「ユーザを識別する」という点では同じであり、 いくら「ウチは広告屋とはちがう!トラッキング目的じゃないんや!」と主張してもダメなところですね。

なので、今後認証機能を提供しようという方は、Cookieに頼らずCORSもちゃんと取り入れてトークンをやりとりする方式のプラットフォームを作るのがいいと思います。


  1. ボタンのクリックやフォームへのフォーカスなど、ユーザ自身が意図を持ってページ上で何らかの操作をすること。
  2. CNAMEレコードを使って全然関係ないサイトをfirst-partyのように見せかける技を制限するアップデートのこと。
  3. 実際にWebKit勢はそういう話を進めているらしい。
  4. どうやらこれはブラウザに保存されたデータを長期間維持する上での重要なクライテリアだと思われているらしい。
  5. 夢喰いメリーは素晴らしい漫画です。2020/12/22現在Amazon Prime会員ならKindle版無料なのでぜひ読んでください。

最新記事

  1. Cloud RunでgRPC streamingができるようになったので動かしてみたりした
  2. 2020年の執筆業まとめ
  3. アーキテクチャを設計する仕事とは
  4. 決済システムを設計するときに忘れてはならないたった1つの大切なこと
  5. third-party cookieと2020年