sleevi / psl-problems

(This is a collection of thoughts from a maintainer of the Public Suffix List (PSL) about the importance of avoiding new Web Platform features, security, or privacy boundaries assuming the PSL is a good starting point. This isn't anything stamped with the Google Seal of Approval or Official Policy, but comes up enough in design reviews to be worth publicly documenting and sharing.)

In the beginning was the cookie, and it was good. It was a time when the root zone was small, cookies were simple, and small furry creatures from Alpha Centauri were real small furry creatures from Alpha Centauri. With the exception that none of this was ever true.

When cookies were first introduced, the idea was simple: anybody who registered a domain could take advantage of this hot new storage/persistence layer. If you registered example.com, then you could do whatever you wanted and set whatever cookie you wanted, for any host in the example.com domain namespace - because it was your domain. This worked for the few generic TLDs (gTLDs) that were set up by RFC 920, but was known to break down when it came to country code TLDs (ccTLDs), that did what they wanted and made their own rules. Whether this was .us which divided into states and cities, or .uk, which had its own subdivisions mirroring the gTLDs, such as .co.uk and .net.uk.

This divergence between the gTLD and ccTLD set led to browsers to implement a set of heuristics in order to mitigate security issues, which were originally introduced in the cookie spec. However, the fundamental assumption, at the time of introduction, was that the party who registered the domain was in control of all content that appeared on their domain, and below it. The cookie boundary was not even seen as a security or privacy boundary - it was merely indicative of a misconfigured or spammy server causing more work for itself.

Leave a Comment