ITP2.1の影響と対策方法、JavaScript生成cookie7日問題

iOS12.2以降で搭載されるSafari12.1からITP2.1が導入される。
「Googleアナリティクスのcookieが使えなくなるのではないか」などの漠然とした不安が先行しているようなので、その要点と影響範囲、対策方法をまとめた。

ITP2.1とは

対象の環境

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

これまでのITP(2.0以前)からの更新内容

ITP2.1の更新内容

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

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

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

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

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

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

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

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

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

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

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

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

Do Not Trackの廃止

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

詳細は以下を参照

https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/

ITP2.1によって具体的にどんな問題が発生するか

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

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

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

対策方法はあるのか

ITP2.1への対策

サーバプログラム

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

JavaScript

ITP2.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問題はあらかじめ解決するよう、設計しておこう。

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

ITP2.1に該当するセグメント

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

基本的なスタンス

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

https://developers.google.com/web/fundamentals/instant-and-offline/web-storage/offline-for-pwa

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

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

追記

Appleの中の人のツイート

localStorageやindexedDBも今後ターゲットになることを示唆している。今回はcookieがターゲットではあるが、段階的に他のローカルでのデータ保存方法を潰していく可能性はある。
一方でローカルでデータを保存することはブラウザの機能上必要ではあるので、急に使えなくするのではなく、データ保存の代替方法を用意したり暫定措置をとる可能性はある。
(今回も1番目と4番目は暫定措置の終了の意味合いが強い)

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

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

作成日:2019年2月25日

計測実装 の記事一覧