結局、気になったのでおうちに帰ってきて、Google Analyticsのクライアント側本体にあたるurchin.jsの中身を調べてみることにした。さすがにケータイからJavaScriptのチェックをするのはキツいもの。

なんかしつこいようだが、ひまなのか…？

これまでのあしあと：
http://memo.hirosiki.jp/article/39107558.html
↓
http://www.milkstand.net/fsgarage/archives/001003.html
↓
http://memo.hirosiki.jp/article/39314566.html
↓
http://memo.hirosiki.jp/article/39344442.html
↓
いまココ！

で、なんでJavaScriptのソースを調べるかというと、JavaScriptを使うとクロスドメインのCookie共有ができてしまうからだ。これは簡単で、

サイトA:
　- Cookie-aをフィード
　- HTML-aをホスト。
　　※HTML-aはサイトBのJavaScript-jを呼び出す
サイトB：
　- JavaScript-jをホスト
　- dummy.gifをホスト

で、JavaScript-jに
　var i = new Image(1,1);
　i.src = 'http://サイトB/dummy.gif?' + EscapeURIComponent( document.cookie );
と書いておくと、クライアントがHTML-aにアクセスするとdummy.gifへのクエリーとしてCookie-aがサイトBに向けて送信される。よね？　つーか、Cookieを直接送信しなくても今回必要なのは一意なIDなので、doument.cookieでなくてもかまわない。

このようなダミー画像による情報の送信自体は、エンベッド型のアクセス解析ツールでは定石だ。実際、
http://www.google-analytics.com/urchin.js
は、l.171のように、
i2.src=_ugifpath2+"?"+"utmwv="+_uwv+s+"&utmac="+_uacct+"&utmcc="+_uGCS();
として、ユーザー情報を送信している。

問題は、ここで送信されている情報の中身なんだよねえ…。sについては、ざっと見ると
　- _uBInfo()（ブラウザ環境情報）
　- _uCInfo()
　- ページタイトル
　- リファラー
　- URL
だ。このうちの_uCInfo()が何をやってるのかよくわかんなかった。サイト内でのクライアント特定用Cookieを生成している部分なんだけれど、ダミー画像側には何も送信していないように見える。

…ということなんだよなあ。結局、
「Google Analytics全体で一意なIDをもっているか」
という点については、JavaScriptから見ても
「技術的には可能だがやってないっぽい」
ということだろうか。

でも、そうするとやっぱりGoogleの人が例のカンファレンスで述べた「ファーストパーティクッキー」というものの意味がつかめない。どういうことなんだろうなぁ…。