箱のプログラミング日記。

渋谷の自社開発企業でRails書いてます。

ITP対応の歴史をまとめる

f:id:y_hakoiri:20191102121842j:plain


少し前になりますが

ITP2.3が発表されましたね。

 

blogs.itmedia.co.jp

 

今回のアップデートの大きなところは、「トラッカー判定」されたドメインからのフラグ付き(URLパラメタ)のアクセスについては、ローカルストレージに保管したデータも制限(1週間で削除)の対象になるということ。

  

なるほどなるほどー。

 

待てよ、今回の変更点はなんとなく理解できたけど、

そもそもこれまでITP対応って、どんな変遷があって

ここまできたんだろうか。

 

と気になったので、歴史を調べてみました

 

そもそも、ITP対応とは

Apple社がsafariで使われるCookieなどを制限すること。

 

なんとなく自分の言葉でまとめると↑になりました。

正式にはIntelligent Tracking Preventionの略らしい。

 

 

ITP対応は、ブラウザ(safari)を利用するクライアントが

プライバシーを必要以上に第三者から侵害されてしまうのを防ぐために、

Apple社が行なっている防衛策みたいなものです。

 

クライアントのブラウザに保存されるCookieの情報を使って、

ユーザーに適した広告を表示させたりするのはもう当たり前になってますが、

最近それがプライバシー的にどうなの〜みたいなことが言われてますよね。

 

Apple社がITP対応を頑張れば頑張るほど、

プライバシーを侵害されたくないユーザーにとっては良いものの、

広告業者は困ってしまうわけですね。

 

以下、具体例が詳しく解説されてます

 

code-a.net

 

ITP対応の歴史

ちょっとここから駆け足で行きます。笑

 

2017年 ITP1.0

  • 3rd Party Cookie24時間を超えると無効化されるように

2018年 ITP2.0

  • 3rd Party Cookie24時間を待たずに即時無効化されるように
  • 1st Party Cookieはユーザーが許諾する、30日間以内にユーザーがアクションをとるといった条件を満たせば破棄されない
  • リダイレクトによるデータの破棄

20192月 ITP2.1

  • 1st Party Cookieの有効期限を最大7日までにする

 (JavaScriptを利用したCookieの取得に対して)

 

 

1st Party Cookieと3rd Party Cookieに関しては

ユーザーが訪れたページの運営元が発行するCookieと

運営元とは異なる第三者(広告業者など)が発行するCookie

くらいの簡単な説明で終わりたいのですが、

 

ここまでの歴史を見ると、

例えばユーザーのログイン状態を保持するといったように、

そのユーザーに直接的なメリットがある状況は許容されつつ、

(1st Party Cookieへの制限はそこまででもないが)

第三者へはできるだけ情報が渡らないように

3rd Party Cookieに対しては厳しめに

制限が進められてきたように感じられます。

 

localStorageにはCookieが保存されるのでこちらで代用することで

対応してきたサービスが多いみたいですね。

 

とはいえイタチごっこ的なところはあるのかなーと。

今後ローカルストレージもどんどん制限されていきそう...。