It's unfortunate that we have this mess. But couldn't this have been avoided by defaulting to minimal access? Per Mozilla (https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies), if a cookie's domain isn't set, it defaults to the domain of the site excluding subdomains. If instead, this defaulted to the full domain, wouldn't that resolve the issue? The harm isn't in allowing people to create cookies that span sites, but in doing so accidentally, correct? The only concern is then tracking cookies. For this, a list of TLDs which it would be invalid to specify as the domain would cover most cases. Situations like github.io are rare enough that there could simply be some additional DNS property they set which makes it invalid to have a cookie at that domain level.
Similarly, the secure and http-only properties ought to default to true.
Since first-party cookies are used to track login state, you do want someway to opt into sharing them site wide for sites where forum.example.com
and mail.example.com
have the same concept of a user.
For this, a list of TLDs which it would be invalid to specify as the domain would cover most cases.
That is what the public suffix list is?
some additional DNS property they set which makes it invalid to have a cookie at that domain level
The problem with his approach is that registries would need to opt in, but in some cases registries can't be bothered and, since it's a security matter, the PSL maintainers (Mozilla) do it for them.
Are
forums.example.com
andmail.example.com
the same site? I'd say yes, since they're probably run by the same people. What aboutexample-a.github.io
andexample-b.github.io
? I'd say no, since GitHub allows anyone to register pages likeusername.github.io
. I can make my judgments as a human, but what should the browser do? Shouldwww.example.com
be able to set a cookie that will be sent tomail.example.com
?It is a bit of a hack, but the way browsers deal with this is a big list: the Public Suffix List. The PSL contains, for example,
com
andgithub.io
, which tell us thatexample.com
andexample.github.io
are independent sites. On the other hand, any subdomains are not separate sites:forums.example.com
andmail.example.com
. Have a look, it's pretty hairy: public_suffix_list.datBrowsers are somewhat ashamed of the hackiness of
site
, and nervous about the security risk of omissions, and so have generally used a much stricter concept oforigin
when introducing functionality. For example,https://a.example.com
cannot write tolocalStorage
in a way visible tohttps://b.example.com
. As browsers work to prevent cross-site tracking, however, with privacy changes such as cache partitioning, theorigin
model is too strict. These mitigations generally use the PSL, and I wanted to look back at its origins.HTTP was originally completely stateless. This poses challenges if you want to implement per-user functionality, like a shopping cart. Netscape's solution, which the world adopted, was cookies. If you read the original specification, it has some discussion of how to prevent someone setting a cookie on all of
This simple heuristic worked reasonably well at the time: it understands that.com
:example.com
andexample.co.uk
are independent sites, separate from other.com
or.co.uk
sites.Perhaps because this special-cased domain names, it was not included in the first two attempts to standardize cookies, RFC 2109 (Feb 1997) and RFC 2965 (Oct 2000).
There were, even from the beginning, cases that this heuristic did not handle. My library growing up was
mln.lib.ma.us
, which ideally would not have shared cookies with anything else underlib.ma.us
. In 2000, however, ICAAN announced seven more TLDs, and initially browsers did not allow anyone to set cookies onexample.info
etc. It wasn't too bad, since you could still set a cookie onwww.example.info
, but you couldn't share it withforum.example.info
.In 2005-2006, Mozilla decided to replace their inconsistent collection of heuristics and exceptions with an explicit list (b319643, b331510),
effective_tld_names.dat
. You can see the first public version on github (Mar 2007).The next round of cookie standardization, RFC 6265 in 2011, recommended projects use it:
This still doesn't explain how
github.io
got on the list: that's not a public registry, the wayco.uk
is. The first private registry to be added wasoperaunite.com
, in November 2009 (b531252):Next were
appspot.com
for App Engine andblogspot.com
for Blogger (b593818), though the Blogger change was rolled back for two years (b598911, b805367). These changes seem to have been uncontroversial; I don't see any pushback about how these are not "real TLDs".As more of these came in, there was discussion about how these were fundamentally different concepts (b712640, 2011), and the list was split into public ("BEGIN ICANN DOMAINS") and private ("BEGIN PRIVATE DOMAINS") sections. For example, no one should be able to get a wildcard cert for
*.co.uk
, but one for*.github.io
still makes sense.Over the last ten years, I believe everyone has migrated to using Mozilla's list. It does take some time for updates to fully propagate, since the list is compiled into browsers, but having one place to update and one place to check for the definition of a site is pretty good.
Comment via: facebook