Readiumに設定されたGoogle Analyticsについて

※2012年3月15日時点の情報です。その後状況が変わっている可能性があります。

IDPFによるリファレンス実装であるReadiumプロジェクト、Google Chrome Extention版の実装はGithubで行われていますが、 そのバージョン0.1.8から内部にGoogle Analyticsによる解析が組み込まれるようになりました。

それ自体はまぁ、開発のヒントにもなるだろうし(オプトインしてほしいかな、とか思いますが)悪くないかなぁと思ってるんですが、やはり自分がどんな本読んでるかバレバレだったりするとやっぱちょっとアレじゃないですか。

ということで、Readiumのソースをgithubのリポジトリから取ってきて、自分でとったGoogle AnalyticsのIDと差し替えてどのような情報が取れるのか確認してみました。

結果から書きますと、現状の設定ではEPUBの情報までは解析していません。
利用状況とユーザの環境情報が参考になる感じですが、アレゲな本を読んでるのがバレバレになるということはありませんでした。

 

ユーザーサマリー

以下のような感じ。普通に情報が取れています。

f:id:uraito:20120315073910p:plain

 

コンテンツサマリー

viewer.htmlというのが、EPUBのビューアでして、その後の「&book=」のあとに続くハッシュらしきものが気になりますよね?

f:id:uraito:20120315073919p:plain

これはEPUBをローカルストレージに保存するときのキーで、EPUBを閲覧するときに呼び出されるため、Google Analyticsに捕捉されてますが、これは以下のように生成されてます。

model/extractBook.js の ExtractBookを定義してるところで、以下のようにURLと日付情報からMD5でハッシュキーを作ってる。

var _urlHash = Readium.Utils.MD5(url + (new Date()).toString());

urlは以下のようにhandleFileSelect()というファイル選択イベントハンドラーの内で、ファイル名から作られてます。

var files = evt.target.files; // FileList object
var url = window.webkitURL.createObjectURL(files[0]);

まぁ、日付情報から生成されているので同じEPUBファイルを読み込ませても別々の値になります。ということで、アレなEPUBをReadiumで読んでも、中の人に温かく見守られたりはしません。よかったです。

(注記)私はこうした読書履歴を捕捉することそのものについては、否定的ではありません。ソーシャルリーディングとか、それそのものが新しいエンターティメントとなる場合もあるでしょうし、読書履歴を自動的に保存しておいてメモとか残せたりするとあとで便利だろうなと思うのです。
ただ、裏でこっそり履歴を取って勝手に利用されたりはやはり気持ち悪いかな、と思います。

Readiumはまだオープンソースなのでこうして検証できますが、アプリなど裏の挙動がわからないものも多いです。
読書履歴は、ちょっとセンシティブな情報だと思いますので、やはり何が保存され、どのように扱われるのかポリシーがはっきりしていることを望みます。

電子書籍リーダー開発各社、および開発者の方々、ぜひそのあたりフェアにお願いいたします。