Public Suffix List/Use Cases
From MozillaWiki
Note: this Mozilla wiki page has not been updated in 10 years, and the PSL maintenence and wiki/etc has migrated to GitHub, where there is a wiki and other documentation that are better resources for those curious about the PSL.
The PSL is being used for more things than was originally intended, and various edge cases, which need to be "in" for one use but "out" for another, are causing people difficulty. This page attempts to gather those potential use cases and help us make a decision on which ones to support, and how.
The current definition according to publicsuffix.org is: 'A "public suffix" is one under which Internet users can directly register names.'
| Name | Description | Question | In List | Not In List | Doesn't Matter |
|---|---|---|---|---|---|
| Cookie-Setting | Deciding whether a cookie should be allowed to be set for a suffix of a given domain | Are this domain and its suffix controlled by the same entity? | com, appspot.com, co.uk | ||
| 'Responsible Domain' Highlighting/Browser History Sorting | Deciding which parts of a domain to highlight or sort on in a UI - "Public Suffix + 1" | Are this domain and its suffix controlled by the same entity? | com, appspot.com, co.uk | ||
| Navigability | Deciding whether a browser should attempt to navigate to a given URL without consulting DNS | Is there (likely to be) an A record for this domain? | com, co.uk | appspot.com | |
| SSL Wildcards | Deciding whether to issue or accept an SSL wildcard certificate for *.public.suffix. | Are the servers of this domain and its suffix operated by the same entity? | com, co.uk | appspot.com | |
| TLD Validation in programming languages | Numerous programming languages use the PSL to validate form entries or logic determining validity of TLDs where PSL is used to validate the rightmost apex of TLD. | In this form value someone just submitted for the URL of their API, was the TLD valid? | com, co.uk | appspot.com | |
| Anti-Spam | The rightmost apex of TLDs is reviewed for validity on return/sender addresses as a basic check, using match in PSL as initial pass/fail to reduce processing time. | Should I quickly drop this email FROM: perp@scam.you if .you isn't in the list of TLDs? | com, co.uk | appspot.com | |
| Whois or other TLD related client software | Use of PSL to track delta/changes/additions to list of possible TLD extensions for purposes of determining whois servers for distributed clients. | What changed in the last version of the PSL, so I know what needs to get attention specifically? | com, co.uk | appspot.com |
[pkasting] Three questions:
- I don't know whether the cookie "question" is precisely correct. Are there situations where one organization should be able to read/write another organization's cookies? For example, should a page on appspot.com be able to read a page on foo.appspot.com?
- I don't think I understand the "history sorting" case completely. What are some concrete examples of this? In an ideal world, would this distinguish between subdomains which are conceptually "different sites" from the parent domain (e.g. mail.google.com versus google.com) and those which are not?
- We should probably consider hypothetical future cases involving ICANN's new "sell anyone their own TLD" policy, like whether we need to do anything special if someone buys a TLD and tries to make it directly navigable via an A record. (Is there some organization which has the authority to approve or reject such actions?) [Jothan] Will track this
