name: Naoto Kato layout: true --- class: center, middle, inverse # Cookieの基本からITPまでをざっと理解する 株式会社プレイド 加藤 尚人 (github: @otolab / twitter: @otoan52) ??? アドベントカレンダーなのにスライド！という敢えてのパターンに挑戦しました。 こんにちは。 @otolab です。 少しメタ的な話をすると、このスライドはremark.jsというライブラリで作られています。マークダウンでスライド、しかも発表資料が作れるというスグレモノ。 ご覧になっているのが発表者モードです。今回はこちらに本文を置き、読みながら画像を繰っていく構造にしました。 `p`のキーを押すと発表側のモードに、`c`を押すと別ウィンドウでもう一つの画面が開き、しかもそれらが連動している...というものすごく便利な子です。 さて。そろそろ次に進みましょう。 `↓`か`→`のカーソルで進めるのが良いと思います。 --- ## 目的 3rd party cookieによるクロスドメイントラッキングが問題に。 それを防止するITPがSafariに導入される。 → 大騒ぎ ...という3行を理解するのが目的 ??? この資料は社内の非開発メンバー向けに最近の動き...とくにITPの話題についての正しい理解を進めてもらうために、「昼会」という定期イベントでミニ講義(?)したときの資料です。 目的はスライドにある3行をなんとなーく理解することです。 ページ数は多いですが図のパターンが多いだけですので、ご心配なく。 --- name: agenda class: inverse # Agenda 1. cookieとは 2. トラッキングとは 3. Webの安全性 4. ITPとはなにか 5. 影響について 6. ブラウザ戦争の眺めかた(おまけ) ??? --- class: section-1 template: agenda ??? ちなみに、最後の6.はほんとにおまけですが、一番話したいことでもあります。 --- class: center, middle, inverse # cookieとは ??? まずは、cookieってなに？3rd party cookieってなに？という基本的な話です。 --- ## cookie cookieはドメインに紐付けてブラウザに保存されるデータ アクセス時に暗黙のうちにサーバとやり取りしている ??? ブラウザのプライバシー設定のなかから、どのドメインにどんな内容のCookieが入っているかなどもみられますね。 ブラウザの開発ツールのネットワークタブ、RequestとResponseの「cookieヘッダ」としてやり取りされているのをみることができます。 --- background-image: url(05.png) ??? 一番上が接続先のサーバ、一番下が手元のコンピュータ。矢印はデータの要求（リクエスト）と応答（レスポンス）。【A】というのがcookieのデータです。 中段のHTMLと書かれているのが開いた状態のページ。 また、手元のコンピュータの右にあるのが「保存領域」のイメージです。cookieのデータである【A】が保存されています。 --- ## cookie いまアクセスしてきたユーザと、 さっきアクセスしてきたユーザが同じであると識別する ??? HTTPの仕様上「リクエストしたのが誰なのかを識別する一意な値」は存在しません。（昔のガラケーなどでは端末IDを送る仕様などもあったように記憶していますが、HTTPの標準的な仕様ではありません） そのため、ユーザの識別はCookieの主な役割です。 --- ## 3rd party cookie あるドメイン上のページの中から、 他のドメイン上のリソースの読み込みを行うとき、 「他のドメイン」から発行されるcookie 開いたページとは異なるドメインに紐付いて管理される ??? 文章にすると判りづらいですね。 画像で説明していきます。 --- background-image: url(05.png) ??? これはさっきの基本的なCookieの図です。 今回は、このページ上から、リソース...画像とか、ページとは別のファイルになっているデータを読み込みます。 ポイントは、domainAではないサーバのファイルを要求するところです。 --- background-image: url(06.png) ??? はい、domainAのページから、domainBのリソースデータを読み込むことが出来ました。 リクエスト・レスポンスの時にCookie 【B】がやり取りされています。**このCookieがdomainAにとっての3rd party cookieです**。 domainAとdomainBは異なるドメインであるため、手元のコンピュータの保存領域もA、Bそれぞれ専用の領域が用意されます。 「基本的に」domainAのサーバはdomainBのサーバのCookieを受け取れませんし、domainBでも同様です。 --- background-image: url(07.png) ??? 他のdomainCのページから、同様にdomainBのリソースを読み込んでみました。 この時、コンピュータにはA、B、C、3つの保存領域がつくられ、それぞれにデータが保存されることになります。 当たり前っぽいですが、ここが結構重要なポイントです。（後述） --- ## 3rd party cookie 今アクセスしてきたユーザが、 他のドメインでは誰なのか・どういう状態なのかを判別できる 例： * 共通ログイン - facebookログインとか * クロスドメイントラッキング ??? 利用例としては、共通ログインの機能（googleとかfacebookログインとか）などですね。 後述する「クロスドメイントラッキング」もよく行われる技法です。 --- ## 何でいきなり3rd??? 商売のモデルから来ている用語 * 1st party vendor - 製品を作って商売をする * 2nd party vendor - 1st partyの製品を使って商売をする * 3rd party vendor - エコシステムの中で、第三者として商売をする - (PCの周辺機器など) ??? なんで3rd?というのはよくある疑問なのですが --- ## 何でいきなり3rd??? * 1st party cookie - サービスサイトと同一のドメインのCookie * 2nd party cookie - とくにない * 3rd party cookie - サービスサイトとは別のドメインのCookie ??? 3rd party vendorが発行するから3rd party cookieなのです。 まあ、厳密には3rd party vendorとして分類するべきか迷う業態のサービスも少なくないわけですが、とりあえずそういうことです。 --- class: section-2 template: agenda --- class: center, middle, inverse # トラッキングとは ??? さらっと出てきた「クロスドメイントラッキング」まで順を追って進んでみましょう。 --- ## トラッキングとは ユーザの行動を追跡すること アクセスしたのが誰なのか判別したい HTTPのリクエストは一回ずつ独立しているので、Cookieなどの仕組みを使わないと判別できない ??? 接続元IPアドレスで分ける手法もありますが、複数端末でアドレスを使い回すのはよく行われているので、安定した手法ではありません。 昔の携帯だと通信時に端末のIDを送ったりしていたとおもますが、最近はもうやらなくなっているはずです。 --- ## 普通のトラッキング 自サイトのcookieに固有の値をもたせることで、アクセスしたのがどのユーザなのかわかる 自サイト...この場合は利用者が意図して開いたページ ??? この程度だとあまり「トラッキング」とは言わないかもしれませんが、「オプトアウト」という観点からは考慮に入れる必要があります。 トラッキングとは呼びづらいところもありますが、管理画面や会員制サービスのログイン状態の維持にもCookieを使うのが一般的です。 ログインするとクッキーに鍵が登録、次のアクセスではそれを送信して、サーバはログイン済みユーザであることを認識する。という感じです。 図にすると... --- background-image: url(05.png) ??? 一番最初に出てきたあの図です。 さて... --- ## クロスドメイントラッキング？ 他サイトにさっきアクセスしたユーザと、 自サイトにいまアクセスしたユーザが同じユーザであるか特定したい ??? こういう需要ももちろんあります。 * 一つの会社が複数のドメインでサービスを展開していて、ユーザの嗜好に合わせたパーソナライズを行いたい * パスワード管理が簡単になるようにログイン機能を共通化したい などは便利な使い方だと多くの人が思うのではないでしょうか。 --- ## クロスドメイントラッキング？ でも、cookieはサイトごとにやり取りされ、値の管理もサイトごとに別れている つまり、サイト運営側は自ドメイン以外のことは知り得ない これは不便... ??? ドメイン毎に保存領域が別れていて、それぞれは独立しているという話をしたと思いますが、その制限を突破する方法が昔からあります。 --- background-image: url(08.png) ??? クロスドメイントラッキングの技法の例。 ２つのサイトA, Bがあった時に、サイトAからサイトBのリソースにアクセスします。この時、iframeを使ってサイトBのページを読み込みます。 iframeの中と外はjavascriptで通信できる。というところがポイントです。 なお、セキュリティ的な観点で言うと、別ドメインのiframe内のデータは勝手に読めないようになっていて、通信やスクリプト実行の拒否など制限をかけることができます。 この通信の成立にはサイトA、サイトBの合意が必要です。 --- background-image: url(09.png) ??? ドメインBのページを開いているiframe内に、domainAのクッキーの値を流し込み、domainBのクッキーとして登録します。 ドメインBのサーバは、【A】と【B】のデータを両方取得することができました。ドメインBのクッキーの保存領域にも【A】【B】両方のデータが保存されています。 さて、さらに... --- background-image: url(10.png) ??? domainCのページを別途読み込みました。 ここで先ほどと同じように、ifameでdomainBのページを読み込みます。 --- background-image: url(11.png) ??? domainBのページ読み込みの時、既に保存されている【A】【B】のクッキーは自動的に送られます。 iframe内への通信でdomainCのクッキー【C】も送り込むことが出来るので、domainBのサーバは3つのクッキーを一度に受け取ることが出来ます。 さらにサーバ間のAPI連携などを行えば、さまざまな情報を同期することができます。 --- background-image: url(13.png) ??? もう少しシンプルな技法です。 ２つのサイトA, Cがあった時に、サイトAからサイトCのページにアクセスします。 あとは前述の方法と同様に、iframe内と通信を行なって、クッキー【A】を送り込みます。 --- background-image: url(14.png) ??? サイトCへのアクセスが発生すると、すでに保存されている【A】【C】2つのクッキーが送信されます。 さて... --- ## クロスドメイントラッキングについての議論 「広告が追いかけてくる」 「Instagramで何を見てたかAmazonが知ってたら嫌だ」 「利用者とサービスは一対一の関係に閉じるべき」 「裏側でサービスが勝手につながっているのはプライバシーの侵害」 ??? ...という声が近頃は多く聞かれるようになりました。 リマーケティング・リターゲット広告と呼ばれる広告技法が普及したこともあり、利用者が自分の行動を「追跡」されている感覚を強く持つようになったのかもしれません。 つまり... --- ## クロスドメイントラッキングについての議論 ユーザの行動履歴は時に個人情報である ??? ...という思想が一般的になってきたと言えるのではないでしょうか。 利便性とプライバシーのバランスはあるものの、住所氏名を勝手に送らないように、行動履歴も勝手に収集されたくないというわけです。 --- ## プライバシーとトラッキング HTML5のlocalStorage, IndexedDBの仕様書では、 トラッキングを制限するための対策を許容している > *UA は、データベースオブジェクトへのアクセスを ＜略＞ 制約してよい — 具体的には iframe 内で稼働している他のドメインからのページに対しては API へのアクセスを否認する。* [索引付きデータベース API - 8.1. 利用者の追跡](https://triple-underscore.github.io/IndexedDB-2nd-ja.html#user-tracking) ??? HTML5は比較的最近つくられた規格なので、前述のポリシーに基づき、クロスドメイントラッキングにつながるの機能の制限を含んでいます。 「ユーザの利便性を損ねない範囲」という条件はあるようですが、iframe内の機能制限を許可しています。例えばSafariでは、iframe内だとWebStorageの機能に制限があり、localStorage（長期保存可能）がsessionStorage（ブラウザを止めると消える）に勝手に変わる機能があります。 この方向は既に既定路線といえそうです。 対して、Cookieは古い規格であり、そのような制限はありませんでした。 --- class: section-3 template: agenda --- class: center, middle, inverse # Webの安全性 ??? HTMLやブラウザの仕様の話が出てきたところで、ブラウザにとっての安全性とはなにか？という点について考えてみたいと思います。 --- ## Webの安全性 Webは完全にオープンなプラットフォーム すでに性善説には立てない 審査や登録を通して安全を確保できない ??? 審査で本当に安全性が分かるのか？はおいとくとしても、まったく自由なプラットフォームならではの考え方は必要になります。 --- ## Webの安全性 * 通信やシステムそのものの安全性 * サイトが利用者に対してできることを制限する * Web上のサービスが不用意に相互作用することを防ぐ ??? 安全性についてのテーマについて、今回の話に関係することだけですが、簡単に分類してみました。 一つずつ見ていきましょう。 --- ## 通信やシステムそのものの安全性 例： * SSL * 不正アクセス * 情報漏えい * などなど ??? まあ、よく聞く感じの話です。 通信経路から先、サーバの領域の安全性についてです。 今回は流します。 --- ## サイトが利用者に対してできることを制限する 例： * PC上のファイルの読み書き * 音やシステム通知 * 入力インターフェイスを奪わない（たとえば全画面時の制限） * **保存できるデータ量・期間の制限** * リソースの制限、メモリ・CPU * など ??? サンドボックス化という言い方がよいかもしれません。 ページ内で任意のプログラムを動かせるが、無制限に何でも出来るようにはなっていない。ということです。 --- ## Web上のサービスが不用意に相互作用することを防ぐ 例： * **ユーザデータのパーティション** * iframeの内外のAPI制限 * CORSの制限 * その他各種通信系のオプション ??? もしgmail.com用に保存されたデータが、他のサイトから読めると...? こわいですね。悪意あるサイトがメールを盗んでいくかもしれません。 そのためドメインやOrigin、つまり組織やサービス単位に基づき、アクセスできるデータを区画分けするようになっています。 当たり前に思えますが、裏側ではデータが行き来しないように制限する機能が、いろいろあるということです。 一方で、許容される範囲であれば相互に連動できるように規格が組み立てられています。 そんな中、cookieのパーティションは歴史的経緯により、少しゆるいと言えます。 --- class: section-4 template: agenda --- class: center, middle, inverse # ITPとはなにか ??? さて、ついにここまで来ました。 --- ## 目的 クロスドメイントラッキングをやめさせたい ??? 新規格での制限に近づけたいという言い方でもよいかもしれません。 --- ## どうやれば防止できるか クロスドメイントラッキングが成立するのは、ドメインに直でデータが紐付いているから あるドメインに紐づくcookieは、他のドメイン上からリクエストしたときも内容が同じ ??? 文章にするの難しい...。図で見て行きましょう。 --- background-image: url(09.png) ??? 前に説明した図を再度出しています。 domainAのページからdomainBのページを開き、【A】のクッキーを送り込みました。 このデータはdomainBの保存領域に保存されます。 そして... --- background-image: url(11.png) ??? domainCのページからdomainBのページを開き、domainBに保存されていたクッキーを取得したり、【C】のクッキーを送り込んだり出来ます。 domainBのサーバは【A】【B】【C】のクッキーを揃えることが出来ました。 これが今までの仕様です。 --- ## どうやれば防止できるか 利用者が開いたページのドメインと、 外部リソースのドメインを「対にして」パーティションを作る **Double Keying** つまり サイトAから見たサイトC、サイトBから見たサイトCは、 異なるcookieを持っている！ ??? ここ、テストに出ます。 冗談はさておき、Double Keyingについて簡単に図解していきます。 ※ なお、DoubleKeyingについて詳しい話は、こちらの記事がオススメです。[Foreign Fetch が削除されそうな理由と Cookie の double keying](https://blog.jxck.io/entries/2017-09-19/remove-foreign-fetch.html) --- background-image: url(15.png) ??? いままでの図とほぼ同じなのですが、iframe内で呼ばれたdomainBのページのクッキーが、「A→B」という領域に保存されています。 「A→B」domainAのページから呼ばれたdomainBのページのクッキーだ。という意味です。 そして... --- background-image: url(16.png) ??? domainCのページを別途開きます。 そして、domainBのページを読み込むと... --- background-image: url(17.png) ??? 「C→B」の保存領域が現れ、そちらに保存されました。 この時「A→B」に入っているクッキーは使われません。 さり気なく【B】の色が異なることにもお気づきでしょうか。実はそれぞれ別な値を持っています。domainBもさっきと同じ人が来たことに気づけないのです。 これで、クロスドメイントラッキングを防止することが出来ました。 --- ## 3rd party cookieのフェアユース 単純にDouble Keyingに切り替えると、問題ないユースケースも妨げてしまう * login状態を複数のサイトで共有するケース * 実質的に同じ組織上でのcookieのやりとり 既存のシステムを破壊しうる → Safariを使ってもらえなくなる可能性もある ??? 利便性とプライバシーは時に両立できません。 Double Keyingに切り替えを行えば、不快なクロスドメイントラッキングが防止できる代わりに、安全な範囲・便利な範囲の機能も制限されることになります。 --- ## Intelligent! ITPは、 *Intelligent* Tracking Prevention * 各ドメインへのアクセス状況をブラウザが分析 * クロスドメイントラッキングを行っているサービスを検出 * 黒判定のドメインだけdouble keyingのルールを適用 - ついでにcookieの寿命も短くする ??? つまり、自動的なブラックリスト方式です。 --- ## Intelligent! 具体的には、 * ドメイン(TLD+1)の範囲でのユーザ操作の有無 * どのくらいの数のサイトから参照されているか * そのほか(?) ??? 数サイトで相互に参照されている程度であれば「トラッキングを目的としたサービス」とはみなさないということです。 --- ## ITPは意外ときびしい * 4ドメイン以上からアクセスがあるとトラッカー判定 * ユーザの直接操作が先になければ即座に削除 * ユーザが直接操作から24時間で分離、30日で削除 参考： [ITPの仕様と挙動について、あまり知られていないことを簡単に整理する](https://www.mm-lab.jp/report/itp_specification_and_behavior/) ??? 基本的にはあるdomainが「黒判定」されても、ページ上でユーザ操作（interaction）が発生すると、猶予期間が与えられる感じになっています。 facebookログインを使う時、facebookのページが開いてログインボタンを押すのが「interaction」で、その直後に発行されたCookieであれば、24時間は分離されずにアクセスできる。ということになります。 --- ## ITPは広まるのか？ * クロスドメイントラッキングの防止はほぼ既定路線 * ITPの仕組みそのものが広まるかは不明 ??? この辺は意見が別れるところだとは思いますが、Safariはプラットフォームとしての利便性より、安全安心をとる路線の気はします。 他のブラウザが同様の仕組みを取るかどうかはまだわかりません。単純に固定式のブラックリストという線もあるのではないでしょうか。 --- class: section-5 template: agenda --- class: center, middle, inverse # 影響について --- ## 現在の動き * ITP実装の開発・調整中(?) * 各社、ITPの影響について告知 * 他のブラウザベンダーは様子見？ * 議論中だったService WorkerのForign Fetchは死んだ ??? --- ## ITPが広まると... * リターゲット広告は... * オーディエンスデータは... * 共通ログイン機能のプレゼンスが上がるかも ??? リターゲット広告はほぼ狙い撃ちにされた形ですね。Safariでの安定動作は見込めないと思います。 技術的には、リンクにIDを載せて遷移させるなどの工夫が主流になり、共通ログインの機能はインタラクションを集められるので、地位が上がるかもしれません。 --- ## というわけで 3rd party cookieによるクロスドメイントラッキングが問題に。 それを防止するITPがSafariに導入される。 → 大騒ぎ ??? というわけで、ここまで如何でしたでしょうか。 ここからはおまけコーナーです。 --- class: section-6 template: agenda --- class: center, middle, inverse # ブラウザ戦争の眺めかた ### (おまけ) ??? Mosaic, NN, IE, Webkit, Mozilla/FireFox, Chrome（, Edgeも）その他たくさんのブラウザが戦いを繰り広げてきましたが、筆者はこの雰囲気、嫌いじゃないのです。 考える、楽しむポイントについて語ってみたいと思います。 --- ## デファクトスタンダード * 標準化団体はあるが、常に実装先行 * 規格があっても利用・実装されなければ消える 実力行使可。なにも決まってない。誰も結論が見えてない ??? ゲーム理論の世界。 SafariがITPを作ったが、どうなるかはわかりません。 --- ## 標準化と独自規格 * 出来ればWebを独占したい * 独自規格で他が付いてこれないようにしたい * 標準化してプラットフォームとしての地位を上げたい せめぎあい。 ??? 最近だとAMP(Accelerated Mobile Pages)とか、Service Workerとか。 ブラウザ間の紛争があるかと思うと、ネイティブアプリ vs Webアプリの図式もあったりと気が抜けません。 --- ## 発言力 * ブラウザのシェア * OSのシェア * サーバサイドのシェア 先行・独走したとき、どのくらい影響力・強制力があるか？ ??? また、ユーザにとってどのくらい必須か。支持されているか？ 乗り換えが発生するか。 今回のITPについては、スマホの一端を握っているAppleだから発言権があります。 CPUにもお金を出してるAppleの姿もあったりと、プラットフォーム争いは熾烈です。 https://pc.watch.impress.co.jp/docs/column/kaigai/1022475.html --- ## Webのとらえかた * webサイトはコンテンツかアプリケーションか * どの層のベンダーが主導権を握れるのか アプリケーション・プラットフォームとして強いのは OSか？ブラウザか？ハードウェアか？ ??? たとえばActiveX, JavaApplet, FlashPlayerはブラウザの上のレイヤーの戦いでしたが、HTML/CSS/javascriptに一本化する流れになりました。 現在だと、Webアプリがネイティブアプリの機能に追いつこうと機能追加している段階というのが個人的な見解です。PWAなどですね。 このあたりのGoogleとAppleの駆け引きが興味深い。 --- ## Web依存度 * googleは検索、GAなど浸透度も高い * SNS系はグロースのための足掛かり * AppleからみてWebはメディアの一つ どのくらい、どのような影響力をもっておきたいか？ ??? 各社地盤が違うことが大きく影響しています。 googleがAndroid / Chromeを出した理由ですね。 Adobeにとっては直接顧客(2nd party)の戦場であったりと、間接的な関わりをもつ企業は少なくありません。 --- ## ブラウザ戦争のなかのPLAID さて。 ??? Webサービスを展開する企業として、いろいろ考えなければならないことは多いです。 今後も深く広く考えて行きたいと思います。 --- class: center, middle, inverse # ありがとうございました ??? これでアドベントカレンダー2017二日目を終わります。 ありがとうございました。