見出し画像

今からはじめるITP2.4(?)対応

AD EBiS マーテック研究会

朝起きたらSlackに新しいメッセージが届いていました。
（と書いて、もう１週間経っていますが）

画像2

次期ITPで実装されると思われる機能です。現時点ですでに３種類の変更が見えてきているので、一旦まとめておきたいと思います。前回はITP3としてリリースされると思っていたものが2.1,2.2,2.3に分割されてリリースされたので、バージョン番号の予測だけやめておきます。時期としては早くても3月（Safari 13.1）でしょうかね。

3rd party cookieの規制強化

まずは3rd party cookieの規制強化です。Safariの今までの3rd party cookieの制限を（色々省略して）まとめると
・バージョン1.0（2003年）から持っていないcookieの読み書きをデフォルトでブロック
・ITP1.0からはさらにインタラクション（click, 入力）の記録がなく、そしてトラッカーと判定されたドメインの3rd party cookieをブロック。インタラクションがあったトラッカードメインのcookieは24時間利用OK、24時間過ぎたら1st partyドメイン毎に分離。ITP1.1からは分離されたcookieをセッションごとに削除
・ITP2.0では最初から分離、2.1では最初からブロック
という複雑な流れで規制強化を進めてきましたが、今度は、ついに、3rd party cookieを無条件でブロックする可能性があります。

完全ブロックの他に、サイトに流入してからユーザがインタラクションするまでの間、cookieをブロックするモードも追加されていて、複数のモードから設定できるようになっています。リリースまでの実験のためなのか、ユーザが設定画面から選べるようになるかは不明です。

既存の制御に合わせて、３つのモード
・OnlyAccordingToPerDomainPolicy（従来の、トラッカードメインのみブロック）
・AllOnSitesWithoutUserInteraction（インテラクション前ブロック）
・All（すべてブロック）
になるのですが、それぞれのステータスについてWilanderさんがこうまとめています。

OnlyAccordingToPerDomainPolicy is shipping, AllOnSitesWithoutUserInteraction is in beta,
and All is behind an experimental flag.

「All」がリリースされるかどうかまだ分からないですが、私の知っている限りでは今までのITPのexperimental featureはすべて正式リリースされました。

ちなみに3rd party cookieを使いたい人は、ITP1.1のときに導入されたStorage Access API (SafariとFirefoxに実装済み、Edgeで実装予定、たしか）をご利用ください、というスタンスです。FacebookとYoutubeが実装済みとの噂です（実装すると、ユーザにcookieの利用を許可しますかポップアップが表示されます）

あ、アドエビスのようにユーザインタラクションの記録がないドメインは、Storage Access APIを呼んでも3rd party cookieへのアクセス許可がもらえない（そもそもcookieがブロックされているのでcookieを持っていないはずな）のでご注意ください。皮肉なことにオプトアウトというインタラクションをしていただいたユーザに対してのみAPIが使えるようになります。が、オプトアウトしたらcookieを使わないので意味がありません。

ログイン状態の監視（IsLoggedIn API）

２つ目の新しい機能は、9月に福岡で行われたTPACカンファレンスに向けてWilanderさんが考案した、ブラウザ側でログイン状態を把握するための新しいJavaScript API 「IsLoggedIn」です。

早速実験的にWebKitに実装されて、

すでに海外の記事で取り上げられています。

ユーザへのログイン状態の表示の他に、ログインしている時だけcookieへの制限を緩和する、もしくはログインしていない時に今よりcookieを厳しく制限したり、ログアウト時に1st party cookieを含めてサイトデータを削除したりするような制御を入れるためのAPIになるのではないかと想定されます。

Explicitly logging out should clear all website data for the website, not just the credential token. The reverse, the user clearing the credential token (individually or as part of a larger clearing of website data), should also log them out for the purposes of IsLoggedIn.（https://lists.w3.org/Archives/Public/public-webappsec/2019Sep/0004.htmlより）

考え方としては、先ほど述べた、インタラクションまでの3rd party cookieをブロックする機能と似ており、サイトに流入しただけで数年残るcookieを付与できてしまう既存の仕組みを問題視しているそうです。

We’re just saying the current practice of dropping >10 year cookies on users as soon as they visit a website is not acceptable.

3rd party JavaScriptの監視

３つ目は（１週間前の）今朝、Slackでお知らせが届いた機能です。今のところは、3rd party scriptのロードを1st party domainごとにカウントしているだけですが、今後はITPで使われている他の統計データと一緒にトラッカー判定やスクリプトのブロックに使われると推測できます。

実はITPの未来予測を聞かれるときの回答によく使ってきたネタです。

画像3

「どこかの掲示板」というのはW3Cの下記ワーキンググループ「WebAppSpec」のメーリングリストです（たしか）。2017年3月のこの投稿です。

https://lists.w3.org/Archives/Public/public-webappsec/2017Mar/0034.html

websites should have the ability to tell users that only first party resources are involved in a web page

最初はfirst party（=アドレスバーに表示されている）ドメインのリソース（画像、スクリプト等）だけを使っていることを、ユーザに知らせるインジケータとして紹介されていますが、インジケータを増やすべきではないという（ChromeのエンジニアMike Westの）指摘に対して、ブラウザ(JavaScript)のAPI制限も提案しています。

https://lists.w3.org/Archives/Public/public-webappsec/2017Mar/0050.html

One way to use Single Trust and avoid new UI is to restrict sensitive APIs or browser functions to single trust pages. That way the user doesn’t have to know anything or make security decisions.

その1年半後Twitterで、Single Trust/3rd partyリソースの規制 について、あまり関心が集まらなかったことに触れて、再び協力を呼びかけていましたが、

結局コンセンサスを待たずに、先にWebKitに実装する作戦に乗り出したと思われます。

現時点では3rd party JavaScriptロードのカウントがどのようにITPで利用されるかは上記メーリングリストのやり取りやヒントはありません。

CNAMEの規制は？

ITP2.1~2.3対応として多くのベンダーが採用しているカスタムドメイン（CNAME）に関しては、最近Firefoxのアドオン「ublock origin」では対応済み、Braveブラウザーも対応中とのことで、話題になっていますが、ITPではまだ特に制限が入っていません。

というのも、Apple自身がCNAMEを使ってサイト内計測をしているのでSafari (ITP)がどう対応するかは想像しにくい。WilanderさんはCNAMEと3rd party scriptでできることがあまり変わらない、新しい問題ではないという見解をTwitterで示しています。やはりWebKit/ITPとしては先に3rd party scriptを制限するのが優先課題でしょうか。

最後に

8月に発表されたWebKit（ITP）のトラッキング防止ポリシーでは、Unintended Impact（意図していない影響）として下記のような一覧を掲載しています。

・Funding websites using targeted or personalized advertising (see Private Click Measurement below).
・Measuring the effectiveness of advertising.
・Federated login using a third-party login provider.
・Single sign-on to multiple websites controlled by the same organization.
・Embedded media that uses the user’s identity to respect their preferences.
・“Like” buttons, federated comments, or other social widgets.
・Fraud prevention.
・Bot detection.
・Improving the security of client authentication.
・Analytics in the scope of a single website.
・Audience measurement.

つまり、Safari/WebKitはITPによってクロスサイトでのトラッキングを防いではいるが、Measuring the effectiveness of advertising（広告効果測定）は意図していない影響としており、cookieやlocalstorageを使ったサイト内トラッキングも現段階では許容している解釈ができます。
防止対象となっているのは一般的なストレージ領域（cookieやlocalstorage）以外の仕組みを使ったトラッキング及びfingerprintingです。

Covert stateful tracking is stateful tracking which uses mechanisms that are not intended for general-purpose storage, such as HSTS or TLS.

3rd partyベンダーによるトラッキングの規制を伺わせるような記述もありますが、どう解釈すればいいかはっきりしておらず、Appleが3rd partyベンダーにトラッキングを委託する現状ではすぐに3rd partyベンダーの排除に乗り出すとは考えにくいです。

sharing of data from that activity with parties other than the first party on which it was collected.

ルールがはっきりしない限り、（Braveを除く）主要ブラウザの中で一番進化が早くて影響も大きいITPの新機能をウォッチして、仕様からやっていいこと、やってはいけないことを推測しかないと考えています。
今後のWebKitの動きについてはtwitterで共有したいと思います。

この記事が気に入ったらサポートをしてみませんか？