iOS11とmacOS high Sierraに搭載のSafariから ITP (Intelligent Tracking Prevention) 機能が搭載され、デフォルトでオンになります。
元ネタが主に webkit の開発blog しかなく、しかもなんだかよくわからないので今理解したと思っているところまでを書いてみる。
SafariのCookie受け入れポリシー
そもそもSafariはサードパーティクッキーを食べないのがデフォだよね、というところから。
つまり、Safariの設定はこうなっているはず。
常にブロック
閲覧中の Web サイトのみ許可
閲覧した Web サイトは許可（デフォルト）
常に許可
ITP以前
これで何が起きるのか、ITPで主に慌てることになっているのは次のような仕組みにしている場合だと思っている。
全ての始まり
次の流れで、クロストラッキングしたいサイトが、閲覧したWebサイトになる。
Aというサイトで広告を踏む
Xという広告配信トラッキングサイトを経由
Zという広告へリダイレクトされる
始まってしまった人は
その後はXを訪れなくてもXのクッキーは他のサイトを訪れた場合にも読み書きできる。
これが元Blogの画像に載っている、 3rd party context でのCookie利用なのではないかと推測
ITP以後
全ての始まりのXを経由してファーストパーティクッキーを食べさせられてから24時間はITP以前と同様にトラッキングされる
Xを再び訪れてファーストパーティクッキーが更新されることなく24時間経過後は、Cなどのサイト（Bも）からXのリソースを参照したとしてもXのクッキーの情報が送られたり更新されたりすることはなくなる
Xを再び訪れてファーストパーティクッキーが更新されることなく30日経過するとXのファーストパーティクッキーは削除される
わからないこと
元のBlogでは、ユーザーのサイトでのインタラクションを元に機械学習でクロストラッキングが目的かどうかを分類してITPの対象かどうかを決めるとあります。
ファーストパーティクッキーの削除がITP対象かどうかに関わらず全サイト対象だとすると、広告配信単体ではなくユーザーが定期的に訪れるサービスを持っているサービスだけがユーザーを継続して認識できるので、FとかGとかいうサービスは大勝利ですね！
webkitのチェンジログあたりからコードを確認しようとかほんの少し思いましたが、あっという間に挫折しましたよ。
あんな巨大なものは一朝一夕では追えません…。いや、時間の問題ではないか。
目的からすると
そもそもSafariは3rd party cookieを食べないのがデフォなので、ITPは直接アクセスさせて食べさせた1st party cookieを別のサイトから（つまり3rd party conntextで）利用できるのが1日、という理解。
これはクロスサイトのトラッキングを予防するという目的に合致する（つまり、1日しかできないのであれば無駄なので3rd party contextでの利用を諦めるだろうという意味で予防）。
ABテストやAnalytics設置先のドメイン用Cookie（1st party cookie）は少なくとも30日もつと思ってる。ITP対象じゃないから指定すれば2年でも保つんじゃないかとか。ABテストやAnalyticsをさせないのが目的ではないはず。