以前、「Inoreaderのフォルダ名って駄々漏れだよねって話」という記事を書いたが、これは間違いだった。
以下はwww.inoreader.comのソース抜粋。
<!DOCTYPE html>
<html>
<head>
<title>Inoreader - The content reader for power users who want to save time.</title>
<meta http-equiv="Content-Type" content="text/html"; charset="UTF-8">
<meta name="description" content="One place to keep up with all your information sources. Rely on powerful free search, full archive of your subscriptions. Monitor specific keywords, save pages from the web and subscribe to social media feeds.">
<meta name="referrer" content="origin">
見ての通り、メタタグにてリファラポリシーが指定されていた。”Origin”とはドキュメントのオリジンのみを送信せよ、という意味らしい。（MDN)
no-referrer |
HTTP Referer ヘッダを送信しません。 |
origin |
ドキュメントのオリジンを送信します。 |
no-referrer-when-downgrade |
推測的に見てよりセキュアな宛先 (https->https) にはオリジンをリファラとして送信しますが、安全性が低い宛先 (https->http) には送信しません。これは既定の動作です。 |
origin-when-crossorigin |
同一オリジンへのリクエストでは URL 全体 (パラメータは除く) を送信しますが、他の場合はオリジンのみ送信します。 |
unsafe-URL |
同一オリジンへのリクエストでは URL 全体 (パラメータは除く) を送信します。 |
ということで、普通、inoreaderではフォルダ名はもれない。IE11とかいうのは除いて。
ではなぜ誤解したのか
私がリファラが漏れていると勘違いしたのには理由がある。ウェブサーバーのアクセスログを眺める機会があって、あるアクセスにinoreaderからのリファラがフルURLで送信されていたのだ。
なぜ、オリジンしか送信されないはずなのに、フルで送信されていたのか？それは、実はこのアクセスが私自身によるもので、私がリファラを制御するブラウザアドオンをインストールしていたからだと思われる。
私は人並みにプライバシーを気にしている。だからリファラコントロールアドオンを利用して、普段はリファラを一切送信しないようにしていた。しかし、そろそろ平成も終わろうか、という時代ではあるけど、リファラを切っていると利用できないウェブサイトも結構多い。そういう時にはリファラをフルで送信するモードに手動で切り替えていた。手動で切り替えると、ついつい元に戻すのを忘れちゃうのが人の性というもの。その時もリファラを送信する状態でinoreaderにアクセスしちゃったというのが事の顛末だと思う。つまり私が利用していたアドオンでは、ドキュメントのリファラポリシーを無視して、設定された条件でリファラを送信していたようだ。確かに、リファラをコントロールするためのアドオンなので正しい動作だと思うけど、肝心のユーザーがポンコツだと却ってプライバシーが漏れやすくなるというのは皮肉だ。