Changes

Jump to: navigation, search

Public Suffix List/Uses

3,499 bytes added, 15:42, 4 February 2014
Created page with "This page attempts to list all the known uses of the Public Suffix List, to help us work out what problems any replacement for it would need to solve. The PSL website has [ht..."
This page attempts to list all the known uses of the Public Suffix List, to help us work out what problems any replacement for it would need to solve.

The PSL website has [http://publicsuffix.org/learn/ a list], on which this one is based, and this data may migrate there later.

In this document, the "registered domain" is the part of a domain consisting of the public suffix plus one additional label. ("Registered" can also be "Registrable" if the domain is not yet registered; we ignore this for linguistic convenience.)

The modern PSL has two sections, the ICANN area and the PRIVATE area, delimited by structured comments. Most applications use both areas without distinction; if an application uses only one or the other, that is noted (where known).

The PRIVATE area exists because some registered domain owners wish to delegate subdomains to mutually-untrusting parties, and therefore wish to have them occupy different origins, as far as web browsers are concerned. Getting added to the PSL is an effective way to accomplish this. Entries in this part of the PSL come from many pseudo-NICs such as CentralNIC (owner of e.g. eu.com and us.org), and companies such as Amazon, Google, GitHub, Heroku, Microsoft and Red Hat, who provide cloud services. They are segregated into a different part of the PSL because some applications need to distinguish between the two types.

==Browsers==

===Cookies===

Browsers restrict the domains for which cookies can be set, to avoid "supercookies" being set for e.g. "co.uk", which would allow sites to track users across multiple domains owned by different entities.

===document.domain===

The document.domain attribute is used to enable pages on different hosts of a domain to access each others' DOMs. Browsers restrict the values to which the document.domain property can be set, to maintain the same origin policy. [http://www.w3.org/TR/html5/browsers.html#dom-document-domain See the HTML5 spec for the algorithm].

===URL Bar===

Both Firefox and Chrome highlight the registered domain. Chrome has a combined search and URL bar, and so uses it to determine whether entered text is a search or a domain name.

===Certificates===

Chrome will reject wildcard certificates (*.foo.bar) if foo.bar is a Public Suffix. They ignore the PRIVATE area for this purpose.

===Other UI===

Firefox uses the registered domain to sort entries in the Download Manager and Cookie Manager.

===To Be Investigated===

DOM Storage quotas?

==Standards==

===CAB Forum Baseline Requirements===

The [https://cabforum.org/baseline-requirements-documents/ CAB Forum Baseline Requirements], in section 11.1.3, require that CAs, before issuing a wildcard certificate, make sure that such a certificate is not for *.public.suffix, e.g. *.co.uk. (Or, that the entity actually owns the entirety of the public suffix, which could be true for suffixes in the PRIVATE area).

===DMARC===

The [https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ DMARC draft RFC] uses the PSL to determine the "organizational domain". This is where the DMARC algorithm looks for DNS records relating to DMARC. (This usage should probably exclude the PRIVATE area, but the draft does not currently say that it should.)

===HTML5===

As noted above, the HTML5 standard references the PSL when defining how the document.domain property should be implemented.

==Other==

* [http://www.whoismind.com/ WhoisMind] uses the PSL to get the registered domain name out of inputted URLs.
Accountapprovers, antispam, confirm, emeritus
4,925
edits

Navigation menu