AppleがITP 2.1導入決定。JavaScript生成cookieの保存期間が7日間へ。どう対処するかまとめた

「iOS12.2以降で搭載されるSafari 12.1からITP 2.1が導入される」とWebKitの公式サイトで2月21日に発表されました。

非エンジニアのサイト担当者や広告運用担当者がITP 2.1問題をどう対処すべきか、ざっくりWeb担編集部が、まとめると以下の通りです。

非エンジニアの担当者さん的には、「なんとなくわかった、でも私はどうしたらいいの？」と感じる方も多いはず。そんな場合は、ツール提供者事業者に「ITP 2.1への対応ってどうなるんでしょうか？」と確認するのが一番早いです。

以下、もっと詳しく知りたい人のために、Option合同会社の柳井 隆道 氏が運営するWebサイト「marketechlabo」に掲載された記事「ITP 2.1の影響と対策方法、JavaScript生成cookie7日問題」を、柳井氏の許諾を得てWeb担の読者向けに転載しました。

ITP 2.1の影響と対策方法、JavaScript生成cookie7日問題

iOS12.2以降で搭載されるSafari 12.1からITP 2.1が導入される。

「Googleアナリティクスのcookieが使えなくなるのではないか」などの漠然とした不安が先行しているようなので、その要点と影響範囲、対策方法をまとめた。

ITP 2.1とは

対象の環境

• ブラウザSafari12.1以降
• このSafariを搭載する対象OSはiOS 12.2/mac os 10.13以降

これまでのITP（2.0以前）からの更新内容

1. トラッカー認定されたcookieがすぐに無効化される
2. JavaScriptが扱えるcookieが7日間までしか使えなくなる
3. キャッシュを使ったクロスサイトトラッキング禁止機能の強化
4. サードパーティの別ウィンドウからのストレージアクセスに関する是正措置の終了
5. Do Not Trackの廃止

各項目について、以下で詳しく解説していく。

1. トラッカー認定されたがすぐ無効化される

トラッカー認定されたcookieは以前は通常利用できない別にところに置いておかれた（partitioned cookie）が、ITP 2.1ではそのような特別扱いがなくなり、トラッカー認定されたcookieがすぐ無効化されるようになる。つまりcookieの扱いが単純化された（一本化された）ということ。

2. JavaScriptが扱えるcookieが7日間までしか使えなくなる

これまでcookieは半永続的に有効期限を設定することができていたが、ITP 2.1ではSecure属性とHttpOnly属性のないcookieの有効期間が7日間になる。

2つの属性のうちHttpOnly属性はJavaScriptから生成することができず、サーバから（HTTP通信で）しか設定できない。つまりJavaScriptが生成できるcookieの有効期間が最大で7日になったということである。

これが一部で話題になっている、「Googleアナリティクスのcookieの有効期限が7日になる」ということである。

なおサーバが発行するcookieであっても、HttpOnly属性がなければ有効期間が7日に制限されるので注意が必要である。

具体的な問題点については後述する。

3. キャッシュを使ったクロスサイトトラッキング禁止機能の強化

キャッシュを使ったクロスサイトトラッキングをできないようにする実装（Partitioned Cache）が従来あったものの、不備を突かれて悪用されていた。キャッシュ内容の検証プロセスが追加され、この不備を突けないようにした。

4. サードパーティの別ウィンドウからのストレージアクセスに関する暫定措置の終了

ITP 2.0でサードパーティcookieを使えなくした時に、ソーシャルログインのような（サードパーティドメインの）別ウィンドウ認証などで使うためのデータのやり取り方法としてcookieの代わりのストレージアクセスを一時的に認めていた。今回それを禁止した。

5. Do Not Trackの廃止

実態としてDo Not Trackが無視されていたので廃止した。

詳細は以下を参照
https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/

ITP 2.1によって具体的にどんな問題が発生するか

JavaScriptが発行するcookie（document.cookieで生成するcookie）の有効期間が最大で7日間になる。

JavaScriptで生成するcookieとして典型的なのがデータベース系サイトやECサイトのお気に入りアイテム保存機能。JavaScriptがダメだからといってお気に入りリストのためにわざわざサーバ開発するというのは実装上、微妙でもある……

あとはビーコン型のウェブ解析ツールやMAツールである。Googleアナリティクスもまさにこれにあたる。ということで、「（現状の実装のままだと）GoogleアナリティクスのクライアントIDが8日以上保持できなくなる」というのは確かに真実である。

対策方法はあるのか

ITP 2.1への対策

サーバプログラム

cookieにSecure属性とHttpOnly属性を追加するのを忘れずに。

JavaScript

ITP 2.1ではあくまでdocument.cookieが7日間で使えなくなるだけで、localStorageなどのストレージは8日目以降も引き続き使うことができる。

データ保持が7日以内で十分なものはこれまで通りで問題ないし、8日以上データ保持しておく必要があれば、localStorageを使えばいい。

• document.cookieで使っているものをすべてlocalStorageに置き換える
• セッションの最初のヒットの時だけlocalStorageを参照、書き込みをし、同一セッション内では従来通りcookieを使うのでもいい

ただしlocalStorageはcookieと異なり

• サブドメインは別扱い
• httpとhttpsは別扱い

となる。この点は留意しておく必要がある。

Googleアナリティクスなどのトラッキングツールでは

このようにJavaScriptだけでも対策方法はあるので、GoogleアナリティクスやAdobe Analyticsなどのトラッキングツールではツール側が対応することに期待しておいていいだろう。

なおGoogleアナリティクスの場合、Google側の実装が遅れても以下のように実装すればいい。

var GA_LOCAL_STORAGE_KEY = 'ga:clientId';

if (window.localStorage) {
  ga('create', 'UA-XXXXX-Y', {
    'storage': 'none',
    'clientId': localStorage.getItem(GA_LOCAL_STORAGE_KEY)
  });
  ga(function(tracker) {
    localStorage.setItem(GA_LOCAL_STORAGE_KEY, tracker.get('clientId'));
  });
}
else {
  ga('create', 'UA-XXXXX-Y', 'auto');
}

ga('send', 'pageview');

参考 https://developers.google.com/analytics/devguides/collection/analyticsjs/cookies-user-id#using_localstorage_to_store_the_client_id

ただしサブドメインとhttp/https問題はあらかじめ解決するよう、設計しておこう。

参考までに検証用セグメントの実装を紹介する。

同様にITP 1.0やITP 2.0についてもセグメントを作れるので、それぞれの数値の違いを比較するのもいいかもしれない。

基本的なスタンス

決してブラウザがデータを保持できないようにするわけではない点に留意しておくべきである。特に今後PWA（Progressive Web Application）化の動きもあり、ブラウザ側でのデータ保持はより便利になっていく。

これはGoogleのドキュメントだが、iOSでもPWAにはある程度対応する動きを見せている。

自社サイトのトラッキングは、技術的にはPWAや自社サービスのユーザビリティを高める動きと同じ枠組みになるので、防ぎきることはできない。トラッカーのリソースをすべて自社ドメインに置いてしまえば、ブラウザからはそれがトラッキング目的のものなのかPWAのものなのか区別できないのである。自社サイトのトラッキングに対しては今後もそこまでナーバスになる必要はないだろう。

追記

Appleの中の人のツイート

localStorageやindexedDBも今後ターゲットになることを示唆している。今回はcookieがターゲットではあるが、段階的に他のローカルでのデータ保存方法を潰していく可能性はある。

一方でローカルでデータを保存することはブラウザの機能上必要ではあるので、急に使えなくするのではなく、データ保存の代替方法を用意したり暫定措置をとる可能性はある。（今回も1番目と4番目は暫定措置の終了の意味合いが強い）

ITP 更新のたびに使える方法と使えなくなる方法が発生する可能性があり、ツールユーザ側の判断で個別に対応するのはリスクが大きい。プラットフォーム側は仕方ないが、対応はプラットフォーム側に任せるのが安全だろう。

またITPの趣旨からしてもクロスドメイン系は特にリスキーなので、サイト側の実装としてクロスドメイントラッキングやサブドメイントラッキングは極力採用しないことをおすすめする。