Web上でのユーザーを追跡する方法

検索エンジンでの私の古いクエリに応じて、Google AdSenseが頻繁にコンテキスト広告を侵入させてくることに私は常に悩まされてきた。検索したときからだいぶ時間が経ち、ブラウザのクッキーやキャッシュを何度か消去しているのにも関わらず、広告が残った。いったいどうやって彼らは私を監視し続けたのだろう?実は、これを行うための方法がたくさんあることが判明した。

まずはじめに

IDやユーザー追跡、または単にWebトラッキングは、特定のサイトを訪問する各ブラウザの一意識別子を計算し設定することを暗示している。元々はここまで悪用されるとは予想だにせず、他のものと同じく、役に立てるようにとまったく逆に考えられたものだった。たとえば、サイト所有者がボットと普通のユーザーを区別したり、ユーザー設定を保存し、二度目以降の訪問でもそれらを使用できる機能を提供するためだ。しかし同時に、この機能は広告業界に非常に好まれてしまった。あなたも良く知っているように、クッキーはユーザーを識別するための最も一般的な方法の一つである。積極的に広告業界で使われ始めたのが90年代半ば頃だ。

その時から多くのことが変わり、技術ははるか先へと進んだ。現在では、ユーザー追跡はクッキーだけに限られない。実際には、いろいろな方法でユーザーを識別することが可能だ。一番ハッキリした方法は、クッキーに似た識別子を設定することだ。次のやり方は、要求を送ったHTTP­ヘッダから収集することができるPCユーザーによって利用されたデータを活用することである。アドレス、使われたOSタイプ、時間など。そして最後に、ユーザーの行動及び習慣(カーソル移動、サイトのお気に入りセクション、等)によってそのユーザーを区別することができる。

明示的な識別子

このアプローチでは、必要とされるすべてのことが大変にハッキリしている。リソースの二度目以降の訪問の際に確認することができる長い間存在した識別子をユーザー側で保存する。最近のブラウザは、ユーザーに対して透過的にこれを実現させる方法をいくつも提供している。何よりも古い親切なクッキーがそれだ。そして、いくつかのプラグインの特徴はクッキーの機能に近い。例えば、フラッシュのLocal Shared Objects 、あるいはシルバーライトのIsolated Storageである。HTML5もクライアント側でいくつかのメカニズムを持っている。localStorage、File、IndexedDB APIなどである。これらの場所以外に、ユニークなマーカーはローカルマシンまたはメタデータキャッシュのキャッシュされたリソースに保存できる。(Last­Modified、ETag)

また、SSL­接続用ブラウザによって定義づけされているOrigin Bound Certificatesから取得した描画、SDCH辞書に含まれるデータ、これらの辞書のメタデータなどからユーザーを識別することが可能である。一言で言えば、やり方は充分すぎるほどあるのだ。

Cookies

クライアント側でそれほど大きくないあるデータ容量を保存することになった場合、まず一般的に考えるのがクッキーだろう。Webサーバーはクッキーに新しいユーザーの一意識別子を保存しながらそれを設定し、それ以降のすべての要求について、クライアントがその識別子をサーバーに送信する。すべての人気あるブラウザは、クッキーで管理された便利なインターフェースによってだいぶ前から提供されているにも関わらず、ネットにおいてはクッキー管理やクッキーブロックのための外部ユーティリティが溢れかえっているのに、クッキーは依然としてユーザー追跡のために活発に利用され続けている。実は、クッキーをチェックして消去する人は結構少ないのだ。(あなたがそれを最後にやったのはいつだったか思い出してみてほしい)おそらくその主な理由は、たとえば認証に使用することができるような必要な「クッキー」を間違って削除するのを皆恐れているのだろう。一部のブラウザでは、サードパーティクッキーの設定を制限することが出来るのに問題は消えず、ブラウザはちょくちょく、ページコンテンツのロード中にHTTPリダイレクトや他の方法を介して受信されたクッキーを「ネイティブ」だと考えてしまう。後で述べるメカニズムの多くと異なるのは、クッキーを使うことがエンドユーザーにとって透過的なことだ。ユーザーを「指定」するためには、必ずしも別のクッキーに一意識別子を保

存する必要はない。いくつかのクッキーの値から収集することもできるし、又はExpiration Timeのようなメタデータに保存することもできる。したがって、この段階でトラッキングするために特定のッキーが使われているのかどうかを把握することは非常に困難である。

ローカル共有オブジェクト

クライアント側でデータを保存するためにAdobe FlashではLSOのメカニズムが使われる。これはHTTPのクッキーのアナログであるが、最新のものと異なり、テキストデータの短い断片を保存することができるだけでなく、何よりもそのようなオブジェクトの分析とチェックを複雑にする。10.3バージョンまでは、フラッシュクッキーの行動はブラウザの設定とは別に調整されていて、macromedia.comサイト上にあるフラッシュ設定マネージャを訪問する必要があった。(ちなみに今もこのリンクで設定できる) 今日では、コントロールパネルから直接行うことができる。さらに最近のブラウザのほとんどはフラッシュプレーヤーとの密接な統合を保証しており、クッキーや他のサイトのデータを削除するときにLSO削除される。一方、ブラウザとプレーヤーの相互作用はまだそれほど密接ではないので、ブラウザ内の外部クッキーのポリシー設定がフラッシュクッキーにいつも反映するわけではない。(Adobeサイトで手動でオフにする方法を見ることができる)

 

FirefoxでのlocalStorageからデータを削除

Silverlightの分離ストレージSilverlightのソフトウェアプラットフォームは、Adobe Flashとの共通点がたくさんある。フラッシュのLocal Shared Objects のアナログとなるのはIsolated Storageと呼ばれるメカニズムだ。実際、フラッシュと違ってプライバシー設定がブラウザにはまったく縛られない。だからブラウザのクッキーとキャッシュを完全消去した場合であっても、Isolated Storageに保存されているデータはどちらにせよ残る。ただもっと興味深いのは、ストレージがすべてのブラウザウィンドウ(「シークレットモード」で開いた場合を除く)や同じマシンにインストールされているすべてのプロファイルで共有されていることだ。LSOのように、技術的な観点からすると、ここにはセッション識別子を保存するための障害は何も存在しない。しかも、ブラウザ設定を通じてこのメカニズムにアプローチできないことを考えると、このメカニズムは一意識別子用のストレージとしてそれほど広く展開することなかった。

 

どこでSilverlightの分離ストレージを探すか

HTML5とクライアント上のデータ保存

HTML5は、クライアント上で構造化データを保存するための一連のメカニズムである。これに相当するのがlocalStorage、File API、IndexedDBだ。違いはあるものの、これらはすべて、特定のリソースにバインドされたバイナリデータの任意の部分を永続的に保存できるように設計されている。加えて、HTTPやFlashクッキーとの違って、保存されたデータの量に有意な制限はない。最新のブラウザにおいてHTML5のストレージはサイトの他のデータと一緒に位置している。しかし、ブラウザ設定を介してのストレージの管理の仕方を推測することは非常に困難である。たとえば、 FirefoxのlocalStorageからデータを削除するために、ユーザーはoffline website dataかsite preferencesを選択し、everythingと同等の期間を設定する必要がある。さらにもう一つのIE特有の変わった機能は、データがそのデータ保存時に開いているタブの存続期間中のみ存在することだ。これに加えて、上記のすべてのメカニズムは、HTTP­クッキーに適用される制限に従おうとはしない。たとえば、localStorageに記述して、外部クッキーを切った状態であってもクロスドメインフレームを通してlocalStorageから読み取ることができる。

 

Flash Playerのためのローカルストレージ設定

キャッシュされたオブジェクト

皆、ブラウザが速やかに、止まることなく動作することを望んでいる。だから、ブラウザは訪れたサイトのリソースをローカル・キャッシュに保存しなければならなくなる。(二度目以降の訪問でそれらを要求しなくて済むように) このメカニズムは明らかにランダムアクセスのストレージとして使用されるためのものではないのだが、そのように変換することが可能である。例えばサーバーは、ボディ内部の一意識別子を伴ったJavaScriptドキュメントをユーザーに戻し、Expires/max­age=ヘッダに遠い未来を設定することができる。このようにしてスクリプト、そしてそれと共に一意識別子がブラウザのキャッシュに登録される。その後、既知のURLからスクリプトのダウンロードを要求し、ウェブ上の任意のページからアクセスすることができる。もちろんブラウザは、スクリプトの新しいバージョンがあるかどうか、定期的にIf­Modified­Sinceヘッダを使って確認する。しかし、もしサーバーがコード304(Not modified)を返してきたら、キャッシュされたコピーが永遠に使用できるようになる。他にキャッシュの面白いところは何か?ここではHTTPクッキーのような「サードパーティ」のオブジェクトという概念はない。同時に、キャッシュを無効にすると真剣にパフォーマンスに影響を与えることができる。いくつかの識別子/ラベルを保存しているリソースの自動検出は、ウェブ上で良く見られるJavaScriptドキュメントの複雑さや容量の大きさに起因して困難になる。もちろんすべてのブラウザは、ユーザーが手動でキャッシュを消去できるようになっている。ただ、経験(自分を例にする)から言うと、もしその作業をしているとしても、そんなに頻繁には行わない。

ETagとLast­Modified

キャッシュが正しく動作するには、ドキュメントのより新しいバージョンがあることをブラウザが何とかサーバーに通知する必要がある。標準のHTTP/1.1は、この問題を解決する2つの方法を提供している。一つ目は、ドキュメントの最終変更日に基づいて、二つ目は、ETagとして知られている抽象的識別子に基づいた方法である。ETagの場合、サーバーは文書と一緒にある応答ヘッダのいわゆるversionタグを最初に返す。指定されたURLへの二度目以降の要求の際、クライアントはIf­None­Matchヘッダーを介してローカルコピーに関連付けられた値をサーバに伝える。このヘッダーで指定されたバージョンが有効であれば、サーバーはHTTPコード304(Not modified)で応答し、クライアントが安全にキャッシュされたバージョンを使用することができる。その逆の場合、サーバーは新しいETagを伴ったドキュメントの新しいバージョンを送ってくる。このアプローチはどこかHTTPクッキーに似ている。サーバーはクライアントの任意の値をあとで計算するためだけにその値を保存する。Last­Modifiedヘッダを使ったもう一つの方法は、のちのちIf­Modefied­Sinceヘッダ内でクライアントによってサーバーに送られる日付文字列内のデータの少なくとも32ビットを保存することができる。興味深いのは、ほとんどのブラウザは、この列が正しい形式で日付を表示する必要がないことだ。キャッシュされたオブジェクトを介してユーザ認証をする場合と同様、クッキーとサイトデータの削除はETagとLast­Modifiedにまったく影響を与えず、キャッシュをクリアにすることによってそれらを取り除くことができる。

 

サーバーはクライアントにETagを返す

HTML5 AppCache

Application Cacheは、ユーザーがオフラインの場合でも、サイトのどの部分をディスクに保存し、利用できるようにしなければならないかを指示することができる。キャッシュのアイテムを保存し、取得するためのルールを設定するマニフェストを使ってすべては管理される。今までのキャッシュのメカニズムと似ているのは、マニフェスト内部と同じように、無期限に保存されているリソース内でAppCacheもユーザーに依存した一意なデータを保存することができることだ。(従来のキャッシュとの違いは、キャッシュからのリソースがある程度時間が経つことで消去されるところ) AppCacheは、HTML5でのデータ保存のメカニズムとブラウザの従来のキャッシュとの中間の値を占める。一部のブラウザでは、クッキーとサイトデータを削除する際にクリーニングされるが、その他は、閲覧の履歴やキャッシュされたすべての文書を削除するときだけだ。

SDCH­辞書

SDCHは、 サーバーによって提供される辞書の使用を基本に、Gzipやdeflateよりも高い圧縮レベルを達成することができたGoogleの圧縮アルゴリズムである。実は普段ウェブサーバーは、ページのヘッダ/フッタ、内蔵JavaScript / CSSなど、あまりにもたくさん繰り返される情報を与えている。このアプローチだとクライアントは、あとに続く応答(同じヘッダー/フッター/ JS / CSS)に表示されることがある文字列を含む辞書ファイルをサーバーから受け取ることになる。その後、サーバーは辞書内のこれらのアイテムを参照することができ、クライアントはそれに基づいて自分でページを収集するようになる。お分かりのように、これらの辞書は、Avail­Dictionaryヘッダ内のサーバーへクライアント自身で返された辞書のIDにも、コンテンツ自体にも直接置くことのできる一意識別子を保存するために、簡単に利用することができる。そしてその後で、ブラウザの従来のキャッシュの場合と同様に使用しようする。

その他の保存メカニズム

しかし、方法はこれで全部ではない。JavaScriptとその同類の仲間を使用して、すべての閲覧履歴やサイトデータを削除した後でさえ存続できるような形で一意識別子を保存し、取得することができる。その方法のひとつは、保存のためにwindow.nameまたはsessionStorageを使うことだ。たとえユーザーがすべてのクッキーとサイトデータを削除しても、追跡サイトが開かれたタブを閉じなかったら、二度目以降のエントリーの際、サーバーによってトークンが受信され、ユーザーは再びそれについて既に収集されたデータに関連付けられてしまう。同じような動作がJSでも観察され、開いているあらゆるJavaScriptコンテキストは、ユーザーがサイトデータを削除した場合でも状態を保存する。この場合、このようなJavaScriptは表示サイトに属するだけでなく、iframeやウェブワーカー内に潜むことができる。たとえば、iframeにダウンロードされた広告は閲覧履歴やデータの削除にはまったく関係なく、JS内のローカル変数に保存されたIDを使用し続ける。

プロトコル

JSや色々なプラグインの利用、キャッシュに関連するメカニズムに加えて、最新のブラウザでは一意識別子の保存および取得を可能にするいくつかのネットワーク機能がある。

1. Origin Bound Certificates(別名Channel ID) ­ クライアントを識別するHTTPSサーバへの永続的な自己署名証明書。それぞれの新しいドメインのために、後に開始する接続に使用する別の証明書が作成される。サイトはユーザー追跡のためにOBCを使用することができ、その際クライアントに気づかれるような何かしらのアクションを実行しない。一意識別子として、正当なSSLハンドシェイクの一部のようにクライアントが提供する証明書の暗号ハッシュを取得することができる。

2. 同様に、TLSにも2つのメカニズムがある。完全なハンドシェイクを実行せずに、中断したHTTPS接続をクライアントによって再開することができるsession identifiersとsession ticketsである。これは、キャッシュされたデータを使用することによって達成される。これら2つのメカニズムは、一人のクライアントからの要求をサーバが短時間で識別することを可能にする。

3. 事実上、すべての最新ブラウザでは名前解決のプロセスをスピードアップするための独自の内部DNSキャッシュを実装する。(場合によっては、DNS rebinding攻撃のリスクを減らす)。このキャッシュは少量の情報を保存するために簡単に使用することができる。例えば、もし16個のIPアドレスを持っている場合、8~9個のキャッシュされた名前でネットワーク上の各コンピュータを識別するのに十分であろう。しかし、このアプローチは、ブラウザの内部DNSキャッシュのサイズによって制限され、名前解決においてDNSプロバイダとの衝突につながる可能性が潜在的にある。

マシンの特徴

ここまで見てきたすべての方法は、ユーザーが二回目以降の要求のためにサーバーに送信される何らかの一意識別子を設定するということが基本になっている。他に、クライアントのマシンの特徴の要求または測定によるユーザー追跡のあまり目立たないアプローチがある。単独だとそれぞれが得た特徴は情報の数ビットだが、もしいくつかを組み合わせた場合、それらは独自にインターネット上のあらゆるコンピュータを識別することができる。しかもそのような追跡を見分けて防止するのは非常に難しいことから、この技術は様々なブラウザやプライベートモードを使用しているユーザーを識別することができてしまう。

ブラウザの「描画」

トラッキングの最も簡単な方法は – 各オプションが別々だとそれぞれは反応しないのに、それらが一緒になると各マシンに固有の値を形成するといった、ブラウザ環境で利用可能なオプションのセットを組み合わせることで識別子を構築することだ。

∙ User­Agent。ブラウザ、OSのバージョン、およびインストールされたアドオンのいくつかを配布。User­Agentが見つからないか “本物”であるかをチェックしたい場合、実装された、あるいはリリース間で変更された特定の機能をチェックすることでブラウザのバージョンを確認することができる。

∙ クロックシステム。もし、システムがサーバー側の時間とクロックを同期していない場合、クロックはJavascriptを使ってマイクロ秒まで正確に測定することができるシステムタイムとリアルタイムの間のユニークな違いを生じさせ、遅かれ早かれ、進んだり遅れたりし始める。実際に、NTPサーバーと同期する場合であっても、どちらにしても測定することができるような小さな変化が生じる。

∙ CPUとGPUに関する情報。これは直接(GL_RENDERERを通じて)か、JavaScriptで実装されたテストとベンチマークを通じて得ることができる。

∙ 画面解像度とブラウザウィンドウのサイズ(マルチモニタシステムの場合の第2のモニターのパラメータを含む)

∙ たとえば、getComputedStyle APIを使用して取得したインストールされているフォントの一覧。

∙ バージョンも含めたすべてのインストールされているプラグイン、ActiveXコントロール、BrowserHelper Object などの一覧。navigator.plugins[ ]探索を使って得ることができる。(一部のプラグインはHTTP­ヘッダー内にその存在を配布)。

∙ インストール型拡張機能、およびその他のソフトウェアに関する情報。広告ブロッカーのような拡張機能は、拡張の種類やその設定を決めることができる現在のページに一定の変更を行う。

ネットの「描画」

さらに、ローカルネットワークのアーキテクチャやネットワークプロトコルの設定においても様々な兆候が見られる。そのような兆候は、クライアントマシンにインストールされているすべてのブラウザで見受けられるようになり、単にプライバシー設定または一部のセキュリティユーティリティでそれらを隠すことはできない。次のようなものがそれだ。

∙ 外部IPアドレス。IPv6アドレスの場合、このベクターは特に興味深い。場合によっては最後のオクテットがデバイスのMACアドレスから得られ、したがって異なるネットワークに接続された場合であっても保存することができる。

∙ 発信TCP / IP接続のポート番号。(通常、ほとんどのOSに一貫して選択される)

∙ NATまたはHTTPプロキシの背後にあるユーザーのためのローカルIPアドレス。外部のIPアドレスと一緒になって独自に顧客の大半を識別することができる。

∙ HTTPヘッダ(X­Forwarded­For)から得たクライアントが利用するプロキシ∙サーバの情報。いくつかの可能なプロキシをバイパスする方法で受信したクライアントの実際のアドレスとの組合せでも、ユーザーを識別することができる。

行動分析や習慣

そしてもう一つのやり方は、PCではなく、地域の設定や行動などのエンドユーザーに関連する特性を見ることだ。このような方法も、プライベートブラウジングの場合においての様々なブラウザセッション、プロファイル間でクライアントを識別することが可能だ。研究のために常に利用可能である以下のデータに基づいて結論を出すことができる。

∙ 優先言語、デフォルトのエンコーディングおよびタイムゾーン(すべてはHTTP­ヘッダ内にあり、JavaScriptから得られる)

∙ クライアントのキャッシュ内のデータと閲覧履歴。キャッシュの要素は、時間の攻撃により検出することができる。追跡者は、単にダウンロードの時間を計測することにより、人気のあるリソースに関連するキャッシュの長寿命の要素を検出することができる。(時間が予想されるローカルキャッシュからのダウンロード時間を超えた場合、動作をキャンセルする) また、ブラウザの履歴に保存されたURLを抽出することもできるが、そのような攻撃は最新のブラウザではユーザーのちょっとした操作を必要とする。

∙ マウスジェスチャー、キーストロークの頻度および持続時間、加速度計データ ­ これらのパラメータのすべては、各ユーザーに固有である。

∙ サイトの標準フォントの変更とそのサイズ、zoomのレベル、テキストの色、サイズなどの特別な機能の使用。

∙ クライアントによってカスタマイズされたブラウザの特定の機能のステータス:サードパーティクッキーのブロック、DNS prefetching、ポップアップブロッカー、Flashのセキュリティ設定など(皮肉なことに、デフォルトの設定を変更したユーザーは、実際には、自分のブラウザを簡単に識別できるようにしてしまう)これは、表面的に存在する明らかな方法である。もしもっと掘り下げたい場合は、さらに方法を思いつくことができる。

まとめ

ご覧のように、実際には、ユーザーを追跡するためのさまざまな方法がある。それらのいくつかは、実装の間違いや欠落の結果であり、理論的には補正することが可能となる。他の方法となると、コンピュータネットワークの原理やウェブアプリケーション、ウェブブラウザを完全に変更をしないことには、実際に根絶することは不可能である。何らかの技術で対抗できるのは、キャッシュやクッキー、または一意識別子を保存することができる他の場所をきれいにすることだ。他は、ユーザーには完全に気づかれないように作動し、それらからの防御はまず上手くいかない。したがって最も重要なことは、プライベート閲覧モードでのネットサーフィンであろうと、あなたの動きはどちらにしても追跡されていることを覚えておくことだ。390870_3121815863768_2033907823_n

 

 

 

  • rell

    はぁはぁ。。。。更新する気力がなえたんですか。。。