雑記

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|
2007|01|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|09|11|
2009|02|03|05|06|07|08|10|11|12|
2010|01|03|04|05|06|07|08|09|10|
2011|05|06|09|10|
2012|03|07|09|12|
2013|01|02|04|05|07|08|10|11|
2014|04|05|08|10|12|
2015|01|05|
2016|09|

2007-12-06 [長年日記]

[個人情報保護] Google Analyticsのスパイウェア的情報収集

このエントリは、以下のエントリの続きです。

前回、Google Analyticについて書いた直後にこれから書く問題に気づき、IPAの脆弱性報告に届出を提出、コメントを控えてきたのですが、IPAから

届出頂きました問題について運営者(筆者注:Google)は脆弱性ではないと判断されました。

この判断の詳細については運営者様のポリシーにより、お伝えする事が出来ません事をご理解ご了承頂けますようお願い致します。

IPA で上記の運営者の判断の詳細を判断を確認した結果、運営者と同様に脆弱性ではないとの判断に至りました。

および、

届出頂いたサービスの問題ではなく、個々のウェブサイトやウェブブラウザの問題と考えております。

との回答をいただき、また実際に対処が施されていないことを確認したので、ウェブサイトの運営者やブラウザの利用者の方々向けの参考情報として、公開します。

事実確認

今回確認した事実についての再現方法について説明します。確認には異なるドメインのWebサーバが2つ必要です。ここでは、www.on-sky.netとwww.example.comを使うことにします。www.on-sky.netはGoogle Analyticsを使ってアクセス解析を行っているサイト、www.example.comは単にwww.on-sky.netにリンクを張っているだけのサイトで、ここではGoogle Analyticsは利用していないとしましょう。

まず、アクセス解析のために、www.on-sky.netには次のようなファイルを置きます。

http://www.on-sky.net/gaum_test.html

<HTML>
<HEAD>
<TITLE>GAUM test</TITLE>
</HEAD>
<BODY>
Google Analytics Urchin Module test<br>
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "";
urchinTracker();
</script>
</BODY>

このままではwww.google-analytics.comに解析用のアクセスが飛んでしまうので、実際には確認用のサーバにリクエストが飛ぶように修正します。

次に、www.example.com上に、www.on-sky.netの解析用ページへのリンクを含むページを置きます。

http://www.example.com/gaum_link.html

<HTML>
<HEAD>
<TITLE>GAUM link</TITLE>
</HEAD>
<BODY>
<A HREF="http://www.on-sky.net/gaum_test.html?t4=d&t5=f&t6=g">on-sky</A>
</BODY>
</HTML>

赤字の部分はGETリクエストのオプションで、通常はこんなことはしないでしょうが、後で説明をはしょるためにつけています。

これで、準備はできましたので、ブラウザを使って以下の(オプション付きの)URLにアクセスします。

http://www.example.com/gaum_link.html?t1=a&t2=b&t3=c&

すると、www.on-sky.net上の解析スクリプトを埋め込んだページへのリンクが表示されるので、クリックしてそのページへと飛びます。

このとき、解析用のサーバwww.google-analytics.comに送信されるリクエストは以下のようになります。

GET /on-sky.jpg?
utmwv=1&常に"1"(バージョン情報?)
utmn=1985892416&毎回生成される乱数
utmcs=Shift_JIS&文字コード
utmsr=1600x1200&画面サイズ
utmsc=32-bit&色数
utmul=ja&言語
utmje=1&Javaアプレットの実行(有効:1, 無効: 0)
utmfl=9.0%20%20r28&Flashのバージョン
utmdt=GAUM%

20test&

ページタイトル
utmhn=www.on-sky.net&サイト名
utmr=http://www.example.com/utm_test.html?t1=a&t2=b&t3=c&リファラ
utmp=/gaum_test.html?t4=d&t5=f&t6=g&ページのパス
utmac=&Google Analyticsのアカウント名
utmcc=(省略)ファースト・パーティCookie

これで判るとおり、Google Analyticsを利用しているwww.on-sky.netのパスだけでなく、そこに単にリンクを張っているだけのwww.example.comについても、青字で示したオプション部分を含めた完全なURLが、リファラ情報としてwww.google-analytics.comに送信されます。

問題点

この種の挙動の何が問題なのかという点については、既に星澤氏や高木氏によって2005年に指摘されていますので、そちらのURLを示して説明に代えさせてもらいます。

■ 星澤裕二のSecurity Watch

ウイルスバスター2006のフィッシング詐欺対策ツールバー
http://itpro.nikkeibp.co.jp/article/Watcher/20051226/226749/
http://itpro.nikkeibp.co.jp/article/Watcher/20051226/226753/

ウイルスバスター2006のフィッシング詐欺対策ツールバーはスパイウェアか?
http://itpro.nikkeibp.co.jp/article/Watcher/20051226/226754/
http://itpro.nikkeibp.co.jp/article/Watcher/20051226/226755/
http://itpro.nikkeibp.co.jp/article/Watcher/20051226/226756/
http://itpro.nikkeibp.co.jp/article/Watcher/20051226/226757/

■ 高木浩光@自宅の日記

ウイルスバスター2006はトレンドマイクロの定義で言うところのスパイウェアである
http://takagi-hiromitsu.jp/diary/20051125.html#p01
ウイルスバスター2006はHTTPSサイトのURLもトレンドマイクロに送信する
http://takagi-hiromitsu.jp/diary/20051127.html#p02

さて、Googleが事実確認の項で書いたような情報について収集していることを、Google Analyticsを利用しているサイトの訪問者であった私は、今回調査するまでは知りませんでした。というか、私が普段巡回しているサイトのうち、どこがGoogle Analyticsを使っているのかさえもいまだに完全には知りません。この点について、私は現在かなり強い不快感を覚えていますが、その矛先をGoogle Analyticsを無邪気に利用しているサイトへ向けるのにも正直ためらっているという状況です。なぜなら、Googleは、私の調べた限りでは、Analyticsの利用者に対してそうした情報を収集しているという事実を一切公表していないからです。そうしたサービスを利用しようと思ったときに、ソースを読み、パケットを解析してまで調査しなければならないなんていう状況は、本来あってはなりません。

Google Analyticsの解析用サーバに送信される情報についてのGoogleの説明として私に見つけることができた情報は、Google AnalyticsヘルプセンターのGoogle Analytics の仕組みを教えてください。にある以下のような説明だけでした。

Google Analytics では、ファーストパーティの cookie と JavaScript コードを使用して、サイトを訪問したユーザーの情報を収集し、広告キャンペーンのデータをトラッキングします。具体的には、ユーザーがどこからアクセスしたか、サイトで何を行ったか、サイトのコンバージョン目標を達成したかなど、ユーザーとウェブサイトとのやりとりを匿名でトラッキングします。 他にも、e コマースのデータをトラッキングし、キャンペーン情報およびコンバージョン情報と組み合わせて、広告キャンペーンの掲載結果を分析することができます。

この説明の「ファーストパーティのcookie」というのは、先に挙げた解析用サーバへのアクセスパラメータの「utmcc」のことでしょう。そして、上記の説明や他の箇所で、Google Analyticsがその利用者のWebページにアクセスしたブラウザから「(オプションを含む)リファラ」「サイト名」「(オプションを含む)ページのパス」をはじめとする各種情報を収集しているということについては一切言及がないようです。

私は、

「ユーザに知らせることなしにユーザのコンピュータの動きを送信する」というこの種の挙動は、これまでにも何度かの騒動を経て、やってはいけないことだという常識が、少なくともセキュリティコミュニティにはできあがっていた。(高木浩光@自宅の日記)

については、今も常識であり続けていると思っていたのですが、GoogleやIPAには通用しませんでした。もしかすると、「脆弱性」として扱ってもらおうと考えたことに無理があったのかもしれませんが、かといってそうした事実をこのような取るに足らない個人が公にするにはなかなかの勇気がいります。

いずれにせよ、Googleは「脆弱性ではないと判断」し、IPAは「運営者と同様に脆弱性ではないとの判断に至り」、また「個々のウェブサイトやウェブブラウザの問題と考えて」いるということなので、ウェブサイトの運用者やウェブブラウザの利用者で気をつけるしか今のところ手はありません。

じゃあどうする

Googleには修正する意思は無い、IPAもその判断を支持する、といった結論が出た以上、私には、ウェブサイトの運用者が、Google Analyticsがこれまでに説明したような情報を収集しているということを理解し、サイトの訪問者に対して、説明責任を果たす。サイトの訪問者はその説明を理解して、ウェブサイトを閲覧するかどうか判断する。というぐらいしか対策は思いつきません。

もうひとつ重要な点は、URLに直接的な個人情報や、セッションID等の個人情報にたどり着ける情報を含めるような実装は、Google Analyricsがある限りは絶対にやってはならない手法になったということです。

股引きになってしまいますが、高木@自宅の日記の「携帯電話向けWebアプリの脆弱性事情はどうなっているのか」というエントリによると、WEB+DB PRESS誌のVol.37には、以下のような記述があるそうです。

セッション
PCサイトでセッションを使う場合は,通常セッションIDをCookieに保存しますが,携帯ブラウザではCookieにデータを保存することができません.そこで携帯サイトでCookieを使う場合はURLにセッションIDを埋め込むことになります.

こうした実装のサイトが、Google Analyticsを利用している場合だけでなく、Google Analyticsを利用しているサイトに対してリンクを貼るだけで、セッションIDはGoogleという第3者へと漏洩します。さらに悪いことに、トレンドマイクロのケースとは違い、Google Analyticsではリファラやページのパス等のデータを平文でwww.google-analytics.comに対して送信しますので、www.google-analytics.com宛のHTTPパケットを監視するだけで、そうした情報は簡単に盗聴できてしまいます。

また、個人的には、リンクを張った先のサーバにリファラ情報が送信されるのと、リンクを貼るという行為によってリンクを張った先ではない第3者(Google)にリファラ情報が送信されるというのとでは、まったく次元が異なる話だと感じています。

ちなみに、私が調べた範囲では携帯電話にはリファラを送信するものと送信しないものがあるようです。GoogleやIPAの弁に従えば、現在の状況では、そうした携帯の挙動について完全に把握し、絶対にセッションID等がGoogleという第3者に漏れないようにする責任は、ウェブサイトの運用者にあります。

もうひとつ付け加えると、GoogleはGoogle Analyticsによって収集した情報の利用目的を明確にしていません。少なくとも私には、プライバシーポリシーはすぐに見つけられましたが、Analyticsで収集したデータの取り扱いに関する記述は1つも見つけることができませんでした。Google Analyticsをその利用者(サイト運営者)の視点から見ると、自分の管理するサイトを訪れた人の数や行動についての分析結果を無料で得られるという魅力的なサービスに映ります。また自分のサイトの訪問者について、そうした分析を行うことや、分析を委託することについてはなんら問題は感じません。それはあくまで個々のサイトという点の中に閉じた話ですから。

しかしながら、Googleはそうした点の情報を無料という餌でかき集め、リファラという点どうしを結びつけることが可能な情報まで現に収集しています。Google Analyticsを利用するサイトが増えればその分精度は上がっていきますので、このまま「無邪気」なサイトが増え続ければ、ウェブに関しては、個人のインターネット上での全ての行動を正確に把握できる情報を収集するといった夢物語が、現実になる日もそう遠くは無いでしょう。しかもそうした情報の取り扱いについて、Googleは誰にも何の意思表示もしていないのです。私の知る限りでは。

余談

今回いろいろ調べなおしていて、トレンドマイクロ騒動のときは、「Googleツールバーは「?」以降を送信しないしHTTPSのときも送信しない」を読んでGoogleの態度に関心したことを思い出したのですが、2年間で変わってしまったんでしょうか。だとすれば残念です。

今回の件についても、実は以下の2行を追加すれば、「?」以降を送信しないという実装に、簡単に修正できる話なんですけどね。

_ur=_ur.substr(0,_ur.indexOf('?'));
pg=pg.substr(0,pg.indexOf('?'));

また、こうしたところでGoogle Analyticsの解析について、何らかの悪影響が出るとは考えにくいのですが、なんかやってるのかな。

もしかすると、「&」をエスケープしていない時点でオプションとしては別になるので、そうした不要なオプションは除外している、というトレンドマイクロと似た論法を使っているのかもしれませんが、そうであるなら上の2行を付け加えることによって疑いの目を向けられることもなくなりますし、解析サーバの負荷も減るはずなので、もし関係者の目に触れることがあれば是非採用してほしいところです。

最後にもう一度、

「ユーザに知らせることなしにユーザのコンピュータの動きを送信する」というこの種の挙動は、これまでにも何度かの騒動を経て、やってはいけないことだという常識が、少なくともセキュリティコミュニティにはできあがっていた。(高木浩光@自宅の日記)

が、今後も常識であり続けることを切に願います。

本日のツッコミ(全1件) [ツッコミを入れる]
- itochan (2007-12-11 02:47)

「(オプションを含む)リファラ」についてですが、<br>例えばこの記事そのもののURLは、<br>http://www.on-sky.net/~hs/index.cgi?date=20071206<br>であり、?以降を削って<br>http://www.on-sky.net/~hs/index.cgi<br>とすると、全く異なったURLとなります。<br>2年前の記事は読んでいませんが、ブログ全盛の今、アクセス解析に「?以後を無視する」という仕様がどれだけ受け入れられるか疑問に思います。