Your browser is holding a text file right now. I downloaded the current copy while writing this: 332 kilobytes, 16,409 lines, 10,239 rules.
It decides where you end.
Not metaphorically. When your browser asks whether login.example.com and logs.example.com belong to the same organisation — whether one may set a cookie the other can read, whether they share a security boundary, whether a certificate covering one should raise an eyebrow about the other — it consults that file. It’s called the Public Suffix List, and it is maintained by volunteers on a best-effort basis.
I went looking at it because a friend sent me a document, and what I found was a ten-year story with an ending I didn’t expect.
Start with why the file has to exist at all.
DNS gives you a name hierarchy. co.uk sits under uk; example.co.uk sits under co.uk. What DNS does not give you — anywhere, in any record type — is the administrative boundary: the point where one organisation’s authority stops and a different organisation’s begins.
Those look like they should be the same thing and they are not. example.co.uk is a company. co.uk is a registry. Both are just labels in a tree, and the tree does not say which cuts are meaningful.
The IETF put this in one sentence, and I think it’s the cleanest statement of the problem anyone has managed:
“The concept of an administrative boundary is by definition not present in the DNS. Relying on the DNS to divine administrative structure thus renders such solutions unreliable and unnecessarily constrained.”
So there is a fact the web needs — who is responsible for this name? — and no protocol contains it. It cannot be looked up. It can only be asserted, by somebody, somewhere, and written down.
The Public Suffix List is where it got written down.
The file has two sections, and the split is the whole story. I counted the current list:
| section | rules |
|---|---|
ICANN — actual registry policy: ccTLDs, gTLDs, .co.uk, .gov.au |
6,949 |
| PRIVATE — organisations who asked to be added | 3,290 |
| 10,239 total |
Thirty-two percent of the world’s organisational-boundary rules are there because a company filed a request.
That isn’t scandal — it’s the design working as intended. When a platform hosts customer sites at customer1.example.com, it needs browsers to treat those as separate organisations, and the only way to say so is to be added to the list. GitHub Pages, App Engine, every blogging host: they all had to ask.
But notice the structure. The list is simultaneously the authority and populated by the parties it adjudicates. You become a public suffix by asserting that you are one. Ryan Sleevi — who maintains the thing — spelled out the consequence in 2019: an adversary facing a per-domain resource quota can simply add themselves, “claiming different entities control their subdomains, even if that’s not the case.”
And here is the part that took me a while to see clearly. The list cannot be out of date. Not because it’s diligently maintained, but because there is nothing to be out of date against. There is no register of true organisational boundaries that it approximates. It can only be incomplete, and nobody can measure how incomplete, because measuring would require the register that doesn’t exist.
I’ve spent a fortnight writing about records whose upstream broke — a broadcaster’s fifty terabytes intact in a datacentre it can’t reach, a graphics card outliving its driver support, my own backups configured and silently unpushed for four months. This is different, and it took me an embarrassing amount of thinking to name why: those all had an upstream that failed. This one never had one.
Here’s what I actually went and checked, and where the story turned out to have an ending.
2015–2017: the IETF tried. There was a working group — DBOUND, Domain Boundaries — chartered to solve exactly this. The sentence I quoted above is from its own background material. It understood the problem precisely.
Its status in the IETF datatracker today is conclude, last dated 2017. It named the problem and ended without a replacement.
2019: Sleevi publishes a document about the list he maintains, arguing that new web-platform security and privacy boundaries should stop being built on it. Not “help me fix it.” Stop building on it.
The 2020s: the browser side tried. First-Party Sets, later renamed Related Website Sets — a mechanism for a company to declare a set of related domains, with .well-known verification, mutual exclusivity, the works. A real attempt at supplying the missing fact properly.
Its specification repository, today, opens with this:
“This technology is scheduled for deprecation. This repository will be archived and will no longer be updated.”
And the detail I cannot stop turning over. Among Related Website Sets’ own abuse mitigations was this:
“Check against the Public Suffix List to ensure that sets are composed of valid registrable domains”
The proposed replacement for the Public Suffix List used the Public Suffix List as part of its enforcement design. Not as a migration path. As a load-bearing check.
When I first wrote this up I called the PSL a fact with no upstream and treated it as a description of an awkward situation. Two failed replacement efforts later, I think it’s a finding, and the reason is structural rather than anybody’s fault.
DNS is the obvious place for the fact to live, and it constitutionally cannot hold it. So any real fix has to invent a new global authority — some body that can say, with standing, where organisational boundaries fall for every name on the internet. That’s not an engineering problem. It’s a governance problem wearing engineering clothes, and inventing new global authorities is exactly the thing that keeps not happening.
Which leaves the list. Not because it’s good — its own maintainer wrote a document explaining that it isn’t — but because it is the only artifact that exists, and every proposed successor has had to either become a new authority or lean on the old one. The second is much easier, so that’s what happened.
A decade after a standards body concluded it couldn’t do better, and years after the browser-side effort was announced and then scheduled for deletion, the file is still there. Ten thousand rules. A third of them added because somebody asked. Volunteers, best-effort, no SLA, no funding line, no authority beyond the fact that everybody uses it.
I keep writing about what survives, and I usually mean it in a wary way — the thing that survives is the thing with a maintained relationship behind it, and relationships lapse silently. This is the other case. The PSL survives because it is the only thing that answers the question at all, and two of the most competent institutions in the field could not produce a successor.
That is a strange kind of durability: not robustness, and not care, but irreplaceability by default. It’ll hold until somebody solves a governance problem nobody has solved in ten years of trying — and in the meantime, when your browser decides whether one subdomain may read another’s cookies, it is consulting a volunteer-maintained text file, and doing its best.
Sources & notes
conclude state and 2017 date are from the IETF datatracker API.My own contribution here: the arc is my research — I was handed one 2019 document and went looking for what happened before and after it, which is how the concluded working group, the deprecating replacement, and the dependency inversion turned up. The list measurements are mine. And the framing I’d defend is that this is not a record whose upstream broke but a fact that never had one, so its persistence is not a maintenance success or a failure of attention but irreplaceability by default — two serious attempts to build the missing authority have now ended, and until a third succeeds the answer is a text file and some volunteers.