Unlike other Web standards, HTTP cookies don't use the common definition of the "origin" as with the "same origin policy"; cookies are segregated by domain names and subdomains. (And there is the secure flag to only return the cookie inside an HTTPS connection, which is yet another subtle matter.)

To determine whether sharing of cookies is allowable, browsers rely on the concept of "same registrable domain".

That's a fundamental isolation guarantee for cookies:

If DX and DY are two different registrable domains, and X and Y two host names inside DX and DY respectively, then

  • the Web pages in X cannot mess with the cookies created by Web pages of Y: they can't read them, modify them;
  • and they X pages can't create cookies that would be sent by browser to Y pages.

That requires a common definition of what a "registrable domain" is; otherwise, what is allowed by some agents and considered safe would be disallowed by others, and no one would consider his own product buggy.

The definition is based on where users can acquire (get some sort of immaterial property) of domain names.

Is that a sound foundation for a fundamental security isolation property?

  • Is there one definition of what constitutes a "registrable domain" universally accepted?
  • Is it precise and decidable in all cases?
  • Do all browsers agree on what counts as a "registrable domain"?

1 Answer 1


All browsers use the "Public Suffix List", at https://publicsuffix.org/

Besides TLDs, it lists all suffixes "under" which people can have their own domain (for free or not).

This is also called the "eTLD+1" policy, eTLD being "effective TLD", so not necessarily a real "Top" Level Domain, but any suffix that works effectively as a TLD, hence allowing registrations under it.

Is there one definition of what constitutes a "registrable domain" universally accepted?

Maybe not, but at least for now everything has converged on Mozilla curated Public Suffix List aka PSL.

Note that there was (and still is) various attempts to do the same thing, typically by storing in the DNS itself data about "relationships" between domains.

Latest attempt was DBOUND: https://datatracker.ietf.org/wg/dbound/about/

Its charter had:

Various Internet protocols and applications require some mechanism for determining whether two domain names are related. The meaning of "related" in this context is not a unitary concept. The DBOUND working group will develop one or more solutions to this family of problems, and will clarify the types of relations relevant.


The current way most of this is handled is via a list published at publicsuffix.org (commonly known as the "Public Suffix List" or "PSL"), and the general goal is to accommodate anything people are using that for today. However, there are broadly speaking two use patterns. The first is a "top ancestor organization" case. In this case, the goal is to find a single superordinate name in the DNS tree that can properly make assertions about the policies and procedures of subordinate names. The second is to determine, given two different names, whether they are governed by the same administrative authority. The goal of the DBOUND working group is to develop a unified solution, if possible, for determining organizational domain boundaries.

The working group was closed in April 2017, by failure of finding a real working solution (people agreed there is a problem, but the work seemed too big and hence no offered solutions were convincing people enough to make it a working group document and advance it as a standard).

There are still some work by individuals, like:

Is it precise and decidable in all cases?

Yes, if you use the PSL. It is not perfect, because the PSL is humanly curated. So some entries are missing on it, and some entries in it do not even resolve anymore so should be cleaned. However the problem is on authorization: which party should be authorized to change which content on this list?

Do all browsers agree on what counts as a "registrable domain"?

Browsers use the PSL, yes. You can find on https://publicsuffix.org/learn/ a (non-exhaustive) list of software using it, like libraries.

Note how it is used also:

  • by the DMARC specification (for email filtering)
  • by the CAB Forum requirements, to require CA to issue certificates only if they validate properly per the PSL
  • in HTML5
  • by Let's Encrypt to apply rate-limiting

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .