tokyo.jp というドメインは、 都道府県型 JP ドメイン という種類の東京版だ。 tokyo.jp が eTLD であるため取得できず、 ${好きな単語}.tokyo.jp は取得できる。これは tokyo.jp をレジストラがそう運用しているからという、仕様ではなく運用の都合なのだ。

ところが、「そう運用されている」という事実を知らないブラウザがあったらどうなるだろうか?

例として example.tokyo.jp というドメインが取得され、なんらかのログインを伴うサービスがデプロイされていたとする。

ここで以下のような Cookie について考えてみよう。

Set-Cookie: session_id=deadbeef;

この Cookie は example.tokyo.jp にしか送られない。しかし以下はどうだろうか?

Set-Cookie: session_id=deadbeef; Domain=tokyo.jp

この Cookie はブラウザが tokyo.jp が eTLD だと知っているかどうかに応じて挙動が変わる。

もし知っているのであれば、 Domain=com などと指定したのと同じで、不正な設定として扱われるだろう。

しかし、知らなければ tokyo.jp のサブドメイン全てに送られる Cookie として扱われ、 .tokyo.jp 以下でデプロイされた他のサイトにも送られることになる。

これは実際に IE で発生した Cookie Monster バグとして知られ、 Session Fixation などに応用可能な脆弱性として問題になった。

まるで IE が悪いかのように喧伝されがちなこの問題だが、そもそも tokyo.jp を eTLD として運用するというのはレジストリの都合だ。 IE からすれば、言われなければ知ったことではない話でもある。

同じことは、都道府県型 JP ドメインの話だけではない。

例えば GitHub Pages が使う github.io は、 jxck.github.io のようにユーザごとにサブドメインが割り当てられる。ホスティングサービスの Glitch が使う glitch.me もアプリごとにサブドメインが振られる。

こうしたサブドメインにデプロイされたサービスが Cookie を持つ場合同じ問題がおこるため、 github.io や glitch.me も eTLD として扱わなければならないのだ。これはいちサービスが提供する機能の都合だ。

さらに、少し前に TLD 自体が爆発的に増え(.web, .new etc)、その上で運用される同様のサービスも増えたが、それらすべての eTLD 運用を把握できてないと、そのブラウザではバグとされてしまう。

そこで、最も現実を追従できている Mozilla の PSL が他のブラウザでも徐々に採用されるようになり、 IE の都道府県型 JP ドメインの問題も PSL への移行をもって解決した。

PSL のその他の用途

PSL の説明によれば、 Cookie 以外にもブラウザが「履歴をドメインごとに並べる」「URL バーで重要なドメインを表示する」など、 UI がドメインを扱う上で活用されている。

しかし、近年これが一番ハイライトされた例に Same Site Cookie がある。 "Same Site" という概念は、 eTLD+1 が同じ であると新しく定義されたのだ。

これは、先の例で言えば github.io が eTLD で jxck.github.io が eTLD+1 にあたる。したがって jxck.github.io と cdn.jxck.github.io はドメインが違えど eTLD+1 が同じなので Same Site となる。

対して jxck.github.io と www.github.io は同じ github.io のサブドメインであるように見えながら eTLD+1 が違うので Cross Site となる。

すると「github.io 自体の Cookie はどうなるのか?」というと、 PSL に登録したドメインは TLD と同じように扱われるため、 Domain=com な Cookie が付与できないのと同じく Domain=github.io な Cookie は付与できない。(したがって https://github.io/ や https://glitch.me/ には何もデプロイされてない)

PSL の運用

もともとは Mozilla の bugzilla で管理されていたものが GitHub に移された。しかし、当時担当だった Mozilla の Gerv Markham が亡くなってからは、数人のボランティアが引き継いでいるため、実質 Mozilla 管理というわけでもなく、良く言えばオープンになっている。

リクエストの受付も事実上一本化されているため、出す側は良いかもしれないが、メンテナンスをしている側のリソースは非常に少ない。同じように審査と登録をするレジストラや CA のような運用ではなく、人が手作業でボランティアでこの重要なリストをメンテナンスしているのだ。

Issue を見てみるとアクティブに Assignee になっている人は 2,3 人しかいないようだ。

ホスティングサービスのように、ユーザにサブドメインを振るサービス形態も増え、さらに近年は TLD 自体が増えていることもあり、これまでもリクエストは定期的にあった。

PSL 追加リクエストの増加

ここからが本題だ。

近年、そんな厳しい運用によってメンテナンスされている、非常に重要なファイルに対して、追加リクエストが頻発し問題になっている。

New interaction between iOS 14 and Facebook Pixel causing increase in PSL inclusion requests - Issue #1245 - publicsuffix/list

High volume of requests to add domains to the PSL - Issue #78 - privacycg/private-click-measurement

以降、ここでまとめられている問題を順に解説する。

iOS14 と Facebook Pixel 問題

まず、 iOS 14.5 以降でトラッキングをする際は、 AppTrackingTransparency(ATT) を通じた許諾の取得が必須となった。

ユーザーのプライバシーとデータの使用 - App Store - Apple Developer

周知の通り、この変更は多くのトラッキングサービスに影響を与え、その 1 つに Facebook Pixel がある。

Apple の iOS 14 リリースが広告やレポートに及ぼしうる影響 | Facebook Business ヘルプセンター

そこで Facebook Pixel は Aggregated Event Measurement(AEM) への移行を促した。

合算イベント測定について | Facebook Business ヘルプセンター

AEM ではドメインごとに 8 つまでしかコンバージョンイベントが設定できないため、多くのイベントを設定していたユーザにとっては厳しい制限となる。

ところが、このドメインの定義は PSL をサポートしているため、 eTLD+1 単位で設定ができることがガイドラインに明記されているのだ。

つまり、保有しているドメインが eTLD+1 だとそのサブドメイン含め 8 個に制限されるが、そのドメインが eTLD になれば、そのサブドメインが各々 8 個のイベントを設定できることを意味する。

FB のアナウンスは「ワークアラウンドとして PSL の追加がある」と、特に PSL をよくわかっていないマーケターに示しているような状況になっているのだ。

PSL リクエストの例

案の定 iOS および Facebook が当該アナウンスをしてから、その対応を理由にした PSL 追加の PR が増えている。(そのドメインそのもので Cookie が使えなくなるといったことを理解してリクエストしているのかは謎だが)

中には、「そのサブドメインにクライアントが何かをデプロイしている」といったプラットフォームからの、いわゆる正統なリクエストもあれば、単にトラッキング制約を回避したいがためだけのリクエストもある。

前者は対応されつつも、後者は棄却されたり、一時的に追加を凍結するといった対応が取られている。

ところが、トラッキング制約の迂回に躍起になっている人間からは、かなり攻撃的な反応が GitHub 以外の場所(電話など)から、中の人に対して来ているようだ。

https://github.com/publicsuffix/list/issues/1245#issuecomment-818050711

完全に健全な状態とは言えず、無視できない状況である一方、こうした運用を想定しなかった中の人は、ひたすらに消耗している。

近年 Privacy Sandbox 系の議論が行われている Privacy CG でも、この問題が取り上げられた。

https://github.com/privacycg/meetings/blob/main/2021/telcons/04-08-minutes.md

Webkit で Privacy 系 API を担当している John Wilander は、これを Privacy Click Measurement の迂回に使っている業者については、「望ましくないとはいえ、そうした業者を block list に乗せて PCM を使えなくするといった対応もあり得る」という趣旨の発言をしている。

過去にも Fingerprinting や CNAME Cloaking など、代替手段として提供されたものはあったが、特に Safari はそうしたものを徹底して塞いできた。これまで運用されていた仕組みがワークアラウンドに利用されることを防ぐためにパッチングを積み重ねることは、 Web をより複雑にし、少しづつ歪が増え、将来的に負債になることは想像に難くない。

かりそめのワークアラウンドのために PSL が利用され、内部の運用まで圧迫している現状は、 Web を利用する誰にとっても良い結果にはならないと筆者は考えている。

理想的な状態は何か

そもそも、そんな仕組みで動いてる現状自体が問題というのは、全くそのとおりであり、この問題は以前から指摘され続けてきた。

Public Suffix List Problems

DNS の構造を無視していることも、 Origin の概念ともズレていることも、レジストラやサービス提供者の気分次第で定義されることも、テキストファイルでメンテされていることも、そのメンテナンスが重要でありながらボランティアベースであることも、全てが問題といっていいだろう。

しかし、一旦このファイルが壊れれば、多くのサイトで Cookie に関するなんらかの問題が発生するか、各ベンダがフォークして互換性の問題が発生するか、もっと最悪な何かになる可能性がある。

既に動いている様々な機能が、 PSL を基底に構築されてしまっている以上、 PSL をやめるためにはそれら全ての仕様を更新し、実装をリリースし、サービスが対応しないといけない。

これが簡単ではないことは、説明しなくてもわかるだろう。したがって、現状はなんとかこの PSL の運用が健全に行える状態に戻すことが先決となる。

Outro

PSL の仕組みと、そこで今起こっている問題について解説した。

トラッキング制限の迂回を目的としたような追加リクエストは妥当とは言えず、それがメンテナを疲弊させている現状は看過し難い。

PSL が正しく理解され、運用が少しでも健全な状態に戻るよう願う。