Firefox 102、追跡用クエリパラメーターの除去に対応 30
ストーリー by headless
除去 部門より
除去 部門より
Mozilla が 6 月 28 日にリリースした Firefox 102.0 では、強化型トラッキング防止 (ETP) 機能の「厳格」モードで、追跡に用いられるクエリパラメーターの除去が可能になっている
(リリースノート、
BleepingComputer の記事、
The Next Web の記事、
The Register の記事)。
こういったクエリパラメーターは Facebook の「fbclid」など、リンクのクリックを追跡するために用いられるクリック ID で、例えば「https://example.com/?fbclid=123abc」の「fbclid=abcd」部分を指す。リリースノートで除去の対象となるパラメーターは具体的に示されていないが、BleepingComputer の記事では fbclid のほかに Olytics の「oly_enc_id」「oly_anon_id」や Drip の「__s」、Vero の「vero_id」、HubSpot の「_hsenc」、Marketo の「mkt_tok」、MailChimp の「mc_eid」を挙げている。
除去はFirefoxの設定 (about:preferences) → プライバシーとセキュリティの「強化型トラッキング防止機能」で「厳格」を選択すれば有効になるが、プライベートウィンドウには適用されない。プライベートウィンドウで除去を実行するには、「about:config」で「privacy.query_stripping.enabled.pbmode」を「true」にする必要がある。この設定にしたプライベートウィンドウでは「強化型トラッキング防止機能」の設定にかかわらず除去が行われる。実際の動作は BleepingComputer が作成したテストページで確認できる。
以前から Brave はより幅広いクリック ID の除去に対応しているが、mkt_tok は除去されなかった。Brave の Brendan Eich 氏は DuckDuckGo ブラウザーが Facebook や Google のクリック ID を除去する一方で Microsoft のクリック ID「msclkid」を除去しないと批判していたが、Firefox 102.0 も「msclkid」を除去しない。また、Google のクリック ID「gclid」も除去されなかった。
こういったクエリパラメーターは Facebook の「fbclid」など、リンクのクリックを追跡するために用いられるクリック ID で、例えば「https://example.com/?fbclid=123abc」の「fbclid=abcd」部分を指す。リリースノートで除去の対象となるパラメーターは具体的に示されていないが、BleepingComputer の記事では fbclid のほかに Olytics の「oly_enc_id」「oly_anon_id」や Drip の「__s」、Vero の「vero_id」、HubSpot の「_hsenc」、Marketo の「mkt_tok」、MailChimp の「mc_eid」を挙げている。
除去はFirefoxの設定 (about:preferences) → プライバシーとセキュリティの「強化型トラッキング防止機能」で「厳格」を選択すれば有効になるが、プライベートウィンドウには適用されない。プライベートウィンドウで除去を実行するには、「about:config」で「privacy.query_stripping.enabled.pbmode」を「true」にする必要がある。この設定にしたプライベートウィンドウでは「強化型トラッキング防止機能」の設定にかかわらず除去が行われる。実際の動作は BleepingComputer が作成したテストページで確認できる。
以前から Brave はより幅広いクリック ID の除去に対応しているが、mkt_tok は除去されなかった。Brave の Brendan Eich 氏は DuckDuckGo ブラウザーが Facebook や Google のクリック ID を除去する一方で Microsoft のクリック ID「msclkid」を除去しないと批判していたが、Firefox 102.0 も「msclkid」を除去しない。また、Google のクリック ID「gclid」も除去されなかった。
リダイレクトがルーピングするリスク有り (スコア:2, 参考になる)
特定のパラメーターが無かったら、パラメーター付きのURLにリダイレクト（HTTPリダイレクトやJavaScriptでのリダイレクト）するというのは、よくある設計なんですね。
ところが、ブラウザー側でそれを排除されてしまったら、リダイレクトがルーピングしてしまうんです。
HTTPリダイレクトならばモダンなブラウザーはリダイレクトを10回ぐらい?ループさせるとルーピング検知で止まりますけど、JavaScriptだと止まりません。
そうなるとDoS状態になって、DoS対策をしていないサイトでデータベース処理が重いページだったりするとデータベースサーバーの同時接続数を使い果たして他のユーザーが接続できなくなっったりします。CloudFlare入れてても、秒間20リクエストとかなら普通検知しないので、バックエンドデータベースで障害が起こることがあります。
DoS対策がされているサイトならば、DoS攻撃判定されて、そのユーザーのIPアドレスはファイアウォールレベルでブロックされて接続できなくなります。
日本だと、日本の某図書館事件のように、利用者がDoS攻撃したと誤認識されて、逮捕されるリスクまであります。
Firefoxはシェアが少ないので、もうクエリーまで弄られると対応が面倒なので、UserAgent でブロックするようなサイトも増えてくるでしょう。
こういうやり方は誰の利益にもならないと思います。
当然対策済み (スコア:4, 参考になる)
We will only strip the query string if it is redirecting to a third-party URI in the top level.
https://github.com/mozilla/gecko-dev/blob/388ea3d22361b97c7f81d02757a1... [github.com]
ということでご指摘の
example.com/?lang=ja -> example.com -> example.com/?lang=ja -> exmaple.com -> 最初に戻る
みたいなループは発生しません。
さらに言うと削除されるパラメーターはdenylist方式でトラッキング用のもののみが削除されるようになっているのでlangみたいな一般的なパラメーターはサードパーティーへのリダイレクトであっても削除されません。
# 最近プライバシー保護技術のストーリーに逆張りコメントする人がいるようですがそっち系の業者の中の人なんですかね