トピックス

ukbd0: ServerEngines SE USB Device, rev 1.10/0.01, addr 2, iclass 3/1
kbd2 at ukbd0
ums0: ServerEngines SE USB Device, rev 1.10/0.01, addr 2, iclass 3/1
ums0: 8 buttons and Z dir.

初期不良かと思いきや、標準添付のマウスを直接つなげるとちゃんと動作するという困った状態。とりあえずKVMスイッチはインストール作業で使うだけなのでまあよしとする。

◆ RAIDモードでは動作しない

Intelマザーでやった時のように、BIOSメニューでRAID1を構築してインストールしようとすると、ar0として認識しない。

試行錯誤した結果、BIOSメニューでRAIDをDisable、SATA AHCIをEnableにした上で、OSインストール、atacontrol create -> ... detach -> /etc/fstab編集 -> 再起動 -> ... addspare -> .,. rebuild という手順を踏むと、なぜか再起動してもちゃんと認識して問題なく動く。これだけではRAIDの情報がどこにあるのかわからず怖いので実験。リブート、コールドブート、電源コンセントを抜いて3分待機したあと電源を入れるとか試しても問題無いようなので、よしとする。うーん、RAIDの情報はHDDに記録されていて、BIOSメニューとFreeBSDで読み書きする位置や内容の整合性が取れてないのかな？

リビルドは何とかなりそうだが、再インストールが必要になった場合は面倒そう。

ディスクI/Oの速度とかは普通かな。

# dd if=/dev/zero of=/usr/t.img bs=1024 count=1024000
1024000+0 records in
1024000+0 records out
1048576000 bytes transferred in 16.435910 secs (63797867 bytes/sec)

◆ ACPI disableで立ち上がらない

起動途中でカーネルパニック。RAIDが使えなかった際の試行錯誤で気づいたものの、結果的にはenableでもRAIDは使えたのでよしとする。shutdown -pとかも普通に出来る。

◆ NICは特に問題なし

NICはbgeとして認識し、通信も正常。

# ttcp -ts -n65536 server
ttcp-t: buflen=8192, nbuf=65536, align=16384/0, port=5001 tcp -> server
ttcp-t: socket
ttcp-t: connect
ttcp-t: 536870912 bytes in 8.76 real seconds = 59879.22 KB/sec +++
ttcp-t: 65536 I/O calls, msec/call = 0.14, calls/sec = 7484.90
ttcp-t: 0.0user 2.0sys 0:08real 24% 16i+324d 474maxrss 0+2pf 54730+136csw

作業用のHubにつないだだけなので、こんなもんでしょう。

[ツッコミを入れる]

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 [「(オプションを含む)リファラ」についてですが、例えばこの記事そのもののURLは、 http://www.on-s..]

2007-12-08 [長年日記]

◆ [個人情報保護] Google Analyticsを応用したWeb巡回追跡実験デモ動画と解説

ふと思いついた実験でGoogle Analyticsの脅威がわかりやすく説明できそうだったので、デモ動画と解説を公開します。右の画像をクリックすると、動画(AVIファイル：20MB)を見ることができます。

このデモはあくまで可能性の提示であり、実際にGoogleがこういうことをやっているかどうか、私の関知するところではありません。また、動画中にはいくつかの実サイトが登場しますが、これは私がたまたま知っているサイトのうち、デモに都合が良かった、または、動画の取得時にたまたまリンクがあったというだけです。各サイト様におかれましては、運が悪かったということでご容赦ください。

◆ 動画解説

まず画面構成について説明します。画面左は実験用に準備した偽www.google-analytics.comの解析サーバのコンソールです。ここに、www.google-analytics.comに送られた解析用データを整形したものが表示されます。

右は何の変哲も無いFirefoxの画面です。動画では、最初にGoogleで「はてな」をキーワードに検索し、はてなのトップページに移動した後、「最近の人気記事」を開いて各種ニュースサイトを巡回します。

動画の流れとしては、右のFirefoxでWebを巡回している時に、www.google-analytics.comに送信される解析用データの様子が、左のコンソールにリアルタイムで表示されるようになっています。

以下、動画の冒頭について少し詳しく解説します。初期のGoogleの画面では私はログインしていて、右上にメールアドレスが表示されています。つまり、GoogleはHideki Sakamoto(hs@on-sky.net)の検索内容について、把握可能な状況です。ここでキーワードに「はてな」と入力して検索し、はてなのトップページに飛びます(0:25)。

はてなのトップページが表示されると、www.google-analytics.comに次のようなデータが送信され、左のコンソールに表示されています。

-----
IP: 192.168.xxx.xxx
TIME: 08/Dec/2007:23:07:10 +0900
HOST: www.hatena.ne.jp
UTMP: /
UTMR: http://www.google.co.jp/search?hl=ja&q=%E3%81%AF%E3%81%A6%E3%81%AA&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=
UTMCC:
  __utma=90496003.1296348447.1194094804.1197115118.1197119304.16;
  __utmb=90496003;
  __utmc=90496003;
  __utmz=90496003.1197119304.16.10.utmccn=(organic)|utmcsr=google|utmctr=%E3%81%AF%E3%81%A6%E3%81%AA|utmcmd=organic;

UTMR変数にはリファラであるところのGoogleの検索ページのURLが、検索語「はてな」を含む完全なURLとして入っています。さてここで、「08/Dec/2007:23:07:10 +0900」に「www.hatena.ne.jp」を訪問した、__utmaの最初の2つの数字(以下、「個人ID」とする)が「90496003.1296348447」である人物がhs@on-sky.netであるということは、もし仮にGoogleが検索についてログを記録している場合、IPアドレスと検索語、および上記TIMEの前後の時刻を照合することにより把握することができます(しつこいようですがあくまで仮説です)。という話はひとまず置いておいて、次の説明に進みます。

動画では、0:30にページ内にある最近の人気記事の一覧リンクをクリックしています。このリンク先はb.hatena.ne.jpで、ここでまたwww.google-analytics.comに次のようなデータが送信されています。

-----
IP: 192.168.xxx.xxx
TIME: 08/Dec/2007:23:07:15 +0900
HOST: b.hatena.ne.jp
UTMP: /hotentry
UTMR: http://www.hatena.ne.jp/
UTMCC:
  __utma=12101991.1308323039.1193486202.1197115125.1197119312.12;
  __utmb=12101991;
  __utmc=12101991;
  __utmz=12101991.1197119312.12.12.utmccn=(referral)|utmcsr=hatena.ne.jp|utmcct=/|utmcmd=referral;

b.hatena.ne.jpとwww.hatena.ne.jpは異なるサーバなので、個人IDには別の値「12101991.1308323039」が入っています。ところが、IPアドレスについては当然1つ目と2つ目のエントリで同じです。また、1つ目のエントリのHOSTとUTMPを組み合わせれば、2つ目のUTMRとの照合ができます。このような2つのデータの照合により、www.hatena.ne.jpにおける個人ID「90496003.1296348447」と、b.hatena.ne.jpにおける個人ID「12101991.1308323039」が同一人物であるということが分かり、1つ目のエントリの解説にある仮定が本当なら、それがhs@on-sky.netであると特定できます。

さて、動画では0:36に読売新聞のサイトに飛んでいますが、ここはGoogle Analyticsを使っていないようで、www.google-analytics.comには何も届きません。ただし、ブラウザの戻るボタンをクリックしてはてなのページに戻る(0:40)と、www.google-analytics.comには2つ目のデータとまったく同じデータが再び届きます。Google Analyticsではこうやって戻るボタンでページに戻ってきたことを把握可能なようです。

さらに動画では0:48にwww.ideaxidea.comというサイトに飛んでいます。ここもGoogle Analyticsを利用しており、先ほどと同様、IPアドレス、b.hatena.ne.jpエントリのHOSTとUTMP、www.ideaxidea.comエントリのUTMRを照合することにより、www.ideaxideax.comの個人ID「236144985.1540274803」がb.hatena.ne.jpの個人ID「12101991.1308323039」と同一人物であると特定できます。

あとは同様な処理を繰り返すだけで、b.hatena.ne.jpの個人ID「12101991.1308323039」と同一人物である他のサイトの個人IDは収集可能です。動画の中では最終的に次のサイトと個人IDを収集できています。

www.hatena.ne.jp	90496003.1296348447
b.hatena.ne.jp	12101991.1308323039
www.ideaxideax.com	236144985.1540274803
codezine.jp	2413090.890357120
www.goodpic.com	141067684.491258399
www.100shiki.com	169936416.1719369956
code.google.com	247248150.894477186
internet.watch.impress.co.jp	180657279.1043611980
www.excite.co.jp	148185315.1361122659
gigazine.net	208899204.21573543
zapanet.info	133676037.963137375

あらためて見るとかなりのサイトに浸透してます。

一方で、動画中の巡回先でGoogle Analyticsを利用していないサイトは以下の通りです。

komachi.yomiuri.co.jp

mainichi.jp

sankei.jp.msn.com

www.itmedia.co.jp

www.asahi.com

www.watch.impress.co.jp

portal.nifty.com

ちょっと面白い結果ですが、単に予算の都合だけなのかもしれませんし、これだけではなんとも言えません。

◆ ユーザーが可能な対処

こうしたブラウザからGoogle Analyticsに追跡用のデータが送られることを阻止する方法は、Firefoxならいくつかあります。Internet Explorerについては残念ながらよく知りません。

1つは、Google Analyticsへのトラッキングコードがhttp://www.google-analytics.com/__utm.gifまたはhttps://www.google-analytics.com/__utm.gifという画像ファイルへのアクセスの形で送信されることを逆に利用する方法です。具体的には、

Firefoxのメニューバーで[ツール]→[オプション]をクリックしてオプションダイアログを開きます。
上のメニューの[コンテンツ]をクリックして、「画像を自動的に読み込む」という表示の右にある[例外サイト]ボタンをクリックします。
「サイトのアドレス」欄に「google-analytics.com」と入力して[不許可]ボタンを押し、画像の自動読み込みを不許可とするサイトとして登録します。

これで現状では十分な対処となりますが、Googleが解析用のURLを画像ファイル以外の拡張子を持ったファイルへと変更すると、この方法は使えなくなります。ただしその場合でも、次の方法を使えば対処可能です。

その方法とは、9月6日のエントリへのコメントでinoueさんに教えてもらったAdblockというFirefox用のアドオンを利用するものです。このアドオンをインストールした後、以下の手順でgoogle-analytics.comへのアクセスを禁止にします。

メニューバーで[ツール]→[Adblock]→[Preferences]をクリックしてAdblockの設定画面を開きます。
「New Filter」欄に「google-analytics.com」と入力して、その右の[add]という部分をクリックしてgoogle-analyrics.comを登録します。
「Enable Adblock」の左にあるチェックボタンをクリックしてチェックが入っている状態にします。
[Done]ボタンをクリックして設定画面を閉じます

これで、google-analytics.comへのアクセスがブロックされるので、結果として追跡用のデータが飛ぶこともなくなります。

◆ Googleはファーストパーティcookieの有効期限を2年に短縮したようだがまったくの無意味

__utmaの有効期限 __utmaの有効期限更新 9月1日のエントリ内の画像にあるように、当時はGoogle Analyticsで利用されているファーストパーティcookieの有効期限は2038年1月18日9:00に固定されていましたが、いつの間にやら修正が入って、2年間になっていました(左図)。が、これはまったくもって無意味です。

なぜなら、ファーストパーティcookieの有効期限は、Google Analyticsを利用しているサイトを訪問するたびに更新されるからです(右図)。

左右の図を比べてみれば分かるとおり、__utmaに含まれる個人IDの部分は「169936416.1719369956」という同じ値であり、有効期限が2009年12月7日1:38:25から13:54:10に変わっています。これは、最後にアクセスしてから2年以内に同じサーバ(図の例では100shiki.com)にアクセスすれば、「169936416.1719369956」という個人IDはさらに2年間有効期限が延長されるというサイクルが繰り返されるだけであり、毎日とか週1とか月1とか年1とかぐらいの頻度で訪問しているサイトであれば、半永久的に同じ個人IDが使われるということを意味します。

で、Googleの中の人は何を考えてこんな変更をしたんでしょうか。意味不明です。