Jump to: navigation, search

Public Suffix List

1,230 bytes removed, 15:38, 8 March 2007
no edit summary
== Tasks to do ==
# Sort out Choose and set up a contact email address# Decide on how to prevent email forgeries (Gerv recommends "pinging" each registry that sends an email and get them to confirm that they actually send it)
# Send the email to all TLD registries
# Decide on how to prevent forgery of replies (Gerv recommends "pinging" each registry that sends an email and get them to confirm that they actually send it)# Monitor the contact email address regularly and manage changes
# Make the effective TLD list file available to other browser manufacturers
== Name ==
The words "Effective TLD" are, for several good reasons, politically charged. In order to prevent public and in external communications, the effective TLD list being seen as an authoritative database of effective TLDs, it will be called known as the "Public Suffix List". Internally, however, the list and the service which uses it will continue to be known as the effective TLD list and effective TLD service respectively.
== Email address ==
The email address for submissions has not as of yet been decided.
== Email address monitoring ==
The email address must be monitored daily for emailsregularly, and submissions, after being verified as originating from the registry, must be integrated with the master list as soon as possible in order to be included in time for the next browser update and be available to as many users as possible.
== Email to registries ==
Dear RegistrySir,
By design, web browsers set cookies for websites with very little checking to see whether the website in question The Mozilla Project ( is allowed to set that cookiemaking a list of all "Public Suffixes". Therefore, there A Public Suffixes is the possibility that a website may domain label or set a cookie at a higher level than itself (eof labels under which end users can directly register domains.gExamples of Public Suffixes are ".net", example" could set a cookie for " and " Since the domain the cookie is being set for matches at least part of the domain name where the request originates from, the browser sets itus".
As you can see, this This information is a major breach of privacy since such cookies will be sent to sites that they should not be sent needed by web browsers in order tohave secure cookie-setting policies, and for other security and user interface purposes. Since there is no algorithmic method of working out which level domains are allowed to be registered (and hence cookies set) at A more detailed rationale for each top-level domain, a list must be compiled with this information to work can be used by the browser when determining whether a cookie may be set or not. Mozilla has devised the Public Suffix List as a solution to this problem.found here: <url>
This is where your registry comes in. Since compiling the We have compiled an initial list of Public Suffix List of every single top-level domain and its associated rules Suffixes, which includes data for domain registrations on a large scale would be a very long-winded, tedious and error-prone taskeach TLD. However, it is in your interest as a registry can help by compiling a smaller list pertaining to make sure that your own top-level domainentry is correct and complete. These smaller lists can then easily Any errors may either cause your customers to not be combined able to set cookies when they should, or cause cookie information to provide be leaked between two domains without a definitive listtrust relationship. Neither of these things is desirable.
The format of Therefore, we are writing to ask you to view the Public Suffix List current list and, if it is very simple. It basically defines one rule on each lineincorrect, ignoring comments preceded by two forward slashes (//)to submit updated data. Each rule states A description of the lowest level at which a cookie may be set. Each rule starts with a dotformat of the list, and a wildcard (*) can be used in place of a subdomain. An exclamation mark (!) at details for sending updates is <here>; the start of a rule marks an exception to a previous wildcard rulelist itself is <here>.
Here is an example list:We would also ask you, for the reasons given above, to institute a policy of sending updated data as soon as possible if your registration policies change in a way which requires a change in the Public Suffix List.
<pre>.com // This Our data is made freely available under a*!</pre> The first line says that cookies may be set for any domain below .com. This line also has a commentliberal licence, which will and so can be ignored. The second line says that cookies may be set below, used by other browser manufacturers and also implies that cookies may not be set directly below software authors who wish to institute similar security The third line says We therefore hope that cookies may be set for any domain below subdomains of Therefore, for example, a cookie may be set for but you will not for or The last line is an exception have to the line abovenotify any organisation other than us about such changes, and says that cookies may be set for The compiled list (and any subsequent updates) should be sent to [INSERT EMAIL ADDRESS HERE]. They will then be integrated with the master list. Compiling your registry's section of thereby keeping the list should not take too much time and will help immensely with privacy protection for browser users. The list only needs workload to be updated when registration rules change, and so is very low maintenance. Your participation in this program will be greatly appreciateda minimum.
Thanking you in advance,
Accountapprovers, antispam, confirm, emeritus

Navigation menu