monolithic kernel

ChromeでサードパーティCookieを完全ブロック

この記事を読んで、ChromeでもサードパーティCookieを完全にブロックできると知ったので、設定してみました。

今回試したバージョン(15.0.874.121 m)ではchrome://flagsを開いて設定を行う必要がありました。

chrome://flags

例外設定

サードパーティCookieを送信しないようにすると、トラッキングを防ぐことができますが、これまで利用してきたサービスが正しく動作しなくなることもあります。例えば、みんなが大好きなはてなスターなど、ログイン状態を管理するためにサードパーティCookieを利用しているサービスが動作しなくなってしまいます。「はてなスターが使えないとなるとサードパーティCookieのブロックは諦めるしかないな」と思ってしまったかもしれませんが、心配ご無用。 利用したいサービスがある場合は、「オプション > 高度な設定 > コンテンツの設定 > 例外の管理… (Cookie)」と辿ってCookieの例外設定を行いましょう。

Cookie とサイト データの例外

ここに項目を追加すると、許可したホストへのCookieの送信はサードパーティCookieの場合でも許可されます。

はてなスターを許可する場合はs.hatena.ne.jpを許可しましょう。

拡張機能への影響

サードパーティCookieのブロックが拡張機能の動作に影響する場合もあります。動作がおかしくなった時はサードパーティCookieを疑ってみるといいかもしれません。

例えば、Taberarelooを使ってLDRからreblogする場合、拡張機能のbackground pageからTumblrに対して通信を行います。background pageは、拡張機能毎に割り当てられたドメイン内のページであるため、background pageから見るとTumblr(www.tumblr.com)のCookieはサードパーティCookieです。そのため、サードパーティCookieを完全にブロックしていると、reblogに失敗してしまいます。

これを回避するためには、やはり例外設定にwww.tumblr.comを追加すればOKです。

ただ、これって拡張機能の動作を把握していないとできないことなので、なかなかハードルが高いですよね……。拡張機能に対しては「サードパーティCookieを受信・送信する」みたいなpermissionが用意されると少しはマシになるかもしれないと思います(あんまり深く考えてないのでマズい点があるかも)。

といはえ、現状でもpermissionを正しく設定している作者は少数派ですし、確認する利用者はさらに少数派だと思うので、そもそも意味がないしれません。システムに触れる人間について考えられていない仕組みだと感じています。