雑記

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|

2003-09-03

ZDNet

ここのところ,ZDNetのWebバグサイトが良く落ちてますねぇ.今もcgi4.zdnet.co.jpにアクセスしようとすると,TCP_ERRORが返ってきます. 例えば,メールで送られてくる記事のURLが
http://cgi4.zdnet.co.jp/g/01_0309030f10_/enterprise/0309/02/epn16.html
となっている場合,
http://www.zdnet.co.jp/enterprise/0309/02/epn16.html
のように書き換えれば記事を読めることが知っていますが,通常はWanderlust(xemacs)を使っていて,メール内のURLをクリック一発で参照しているので,なかなか面倒です.
そうそう,私は上の方法をmozillaと組み合わせて使っているのですが,(少なくともこのペアだと)起動済みのmozillaがあればそれにリクエストを投げてくれます.この機能を利用してxemacsをリモートホストで起動した際,あらかじめmozillaをローカルホストで起動しておくようにすると,私の自宅─職場間など回線が十分太くはないときには応答速度がけた違いに改善します.xemacsは重くないんかいと突っ込まれそうですが,画像とか無いのでこっちのスピードは十分許容範囲.

と思ったらWebバグ廃止??

上の記述は「ZDNet Wire 03/09/03 朝刊」での挙動を元に書いていたのですが,私の手元に届いた「ZDNet Wire 03/09/03 夕刊」のURLからWebバグと思しき文字列がきれいさっぱり消えていました.(手元に残っているメールによると)去年の5月24日にこれについて,「どういう情報を集めているんですか?」と問い合わせたときには無視されてしまったのですが,今回の措置は時代の流れですかね.

にしても,今回のWebバグの廃止と同時にサーバも停止したのでしょうか? だったらちゃんとその旨ユーザに伝えた上で,しばらくは参照先の記事に自動的に飛ばす機能だけは残しておいてくれれば良いのに.


2006-09-03

携帯電話が無い

お昼を食べに外に出ようとして、携帯電話を探すが見当たらない。机上ブラックホールに入り込んだかなと思い、電話をかけてみるが「電波の届かないところか…」と繋がらない。今朝からの行動を思い出していくと、朝食を食べたときにしょうゆをこぼしてしまい、そのまま上着を洗濯機に放り込んで洗ったなぁ、といやな予感。恐る恐る洗濯機のふたを開けると、洗濯・脱水済みの京ぽんが。

仕事に使っている端末なので乾燥させてリカバリを試すなどという悠長なまねをしているわけにもいかず、急遽機種変更決定。いっそのこと割り切ってnico.にしちゃうかとも思いましたが、結局W-ZERO3[es]を購入しました。メールの設定と電話帳のリカバリまでやってとりあえず封印。


2007-09-03

[個人情報保護] GoogleはAnalyticsを使って個人の行動履歴を収集している?(補足)

09/04: 不正確な表現等を修正しました

昨日書いたTracking手法は、基本的には同一IPアドレスのコンピュータは同じ人が使っているという前提での話でした。ならば、IPアドレスを変えれば安心かというと、実はそういうわけにもいきません。

昨日のエントリで記述したとおり、_utmaという値はユーザーがあるサイトを始めて訪問したときに、サイト名のハッシュやMath.random()で作った乱数等を使って生成される値で、それ自体にはユーザーと直接結びつくような情報は持ちません。しかしながら、その値は「ファースト・パーティCookie」としてあなたのブラウザに記録され、昨日のエントリの画像内の「有効期限」を見てもらえば分かるとおり、2038年1月18日まで最初の3つの数字については同じ値が使い続けられます。つまり、仮にクライアントのIPアドレスが変わったとしても、この_utmaの最初の3つの数値が同じであれば、それは同じユーザーであるとみなせるわけです。これは、1台のコンピュータを複数のユーザーでアカウントを使い分けている時にも有効で、クッキーはアカウントごとに管理されるので、同一コンピュータを共有していても個人を識別することが可能になります。さらに複数のクライアントがLDAPやNIS、アクティブディレクトリ等を利用した環境できちんとしたアカウント管理下にあれば、コンピュータが変わったとしても個人を同定することが可能です。

つまり、_utmaクッキーを取得済みの場合はこれを使ってユーザーを識別しつつ、異なるサイトに関しては短期間で同一IPアドレスから来るリクエストは同じユーザーであると仮定する、というアルゴリズムにすれば、あるユーザーがGoogle Analyticsで解析を行っているサイト間をどのように渡り歩いたのかといった情報が収集可能になります。また逆に、同一IPのクライアントから異なる_utmaクッキーを受け取った場合、ユーザーが切り替わったという判定に使うこともできます。話がそれてきたので最初のお題に戻ると、このように_utmaの値を比較することにより、仮にクライアントのIPアドレスが変更されたとしてもユーザーを特定することが可能になり、使っているIPアドレスとは無関係に個人を追跡可能になるという非常に強力な仕組みとなっています。

こうした追跡から逃れる方法は、IPアドレスをこまめに変更しつつ「ファースト・パーティCookie」の受け入れを拒否する、あるいはブラウザの起動/終了時に全ての「ファースト・パーティCookie」を削除するといった手間をかけるか、NATの奥に多数のクライアントマシンを設置して常に複数のユーザーが外見上同一IPアドレスでインターネットにアクセスするような環境を利用する、ぐらいでしょうか。

繰り返しになりますが、これは技術的に可能であるという話であり、実際にGoogleがそうしているかどうかは分かりません。

本日のツッコミ(全1件) [ツッコミを入れる]

- 近藤@古代図書館 [Firefox は first party cookie を session only に設定することは可能ですよ。..]