|
|
| Line 17: |
Line 17: |
| == Tasks to do == | | == Tasks to do == |
|
| |
|
| # Sort out a contact email address | | # 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 | | # Send the email to all TLD registries |
| # Monitor the email address regularly and manage changes | | # 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 | | # Make the effective TLD list file available to other browser manufacturers |
|
| |
|
| == Name == | | == Name == |
|
| |
|
| In order to prevent the effective TLD list being seen as an authoritative database of effective TLDs, it will be called 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. | | The words "Effective TLD" are, for several good reasons, politically charged. In public and in external communications, the list will be 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 == | | == Email address == |
|
| |
|
| The email address for submissions has not as of yet been decided. | | The email address for submissions has not yet been decided. |
|
| |
|
| == Email address monitoring == | | == Email address monitoring == |
|
| |
|
| The email address must be monitored daily for emails, 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 the next browser update and be available to as many users as possible. | | The email address must be monitored regularly, and submissions, after being verified as originating from the registry, must be integrated with the master list in time for the next browser update. |
|
| |
|
| == Email to registries == | | == Email to registries == |
|
| |
|
| Dear Registry, | | Dear Sir, |
|
| |
|
| By design, web browsers set cookies for websites with very little checking to see whether the website in question is allowed to set that cookie. Therefore, there is the possibility that a website may set a cookie at a higher level than itself (e.g., example.co.uk could set a cookie for .co.uk). 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 it.
| | The Mozilla Project (http://www.mozilla.org/) is making a list of all "Public Suffixes". A Public Suffixes is a domain label or set of labels under which end users can directly register domains. Examples of Public Suffixes are ".net", ".org.uk" and ".pvt.k12.ca.us". |
|
| |
|
| As you can see, this is a major breach of privacy since such cookies will be sent to sites that they should not be sent to. Since there is no algorithmic method of working out which level domains are allowed to be registered (and hence cookies set) at for each top-level domain, a list must be compiled with this information to 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.
| | This information is needed by web browsers in order to have secure cookie-setting policies, and for other security and user interface purposes. A more detailed rationale for this work can be found here: <url> |
|
| |
|
| This is where your registry comes in. Since compiling the Public Suffix List of every single top-level domain and its associated rules for domain registrations on a large scale would be a very long-winded, tedious and error-prone task, your registry can help by compiling a smaller list pertaining to your own top-level domain. These smaller lists can then easily be combined to provide a definitive list.
| | We have compiled an initial list of Public Suffixes, which includes data for each TLD. However, it is in your interest as a registry to make sure that your entry is correct and complete. Any errors may either cause your customers to not be able to set cookies when they should, or cause cookie information to be leaked between two domains without a trust relationship. Neither of these things is desirable. |
|
| |
|
| The format of the Public Suffix List is very simple. It basically defines one rule on each line, ignoring comments preceded by two forward slashes (//). Each rule states the lowest level at which a cookie may be set. Each rule starts with a dot, and a wildcard (*) can be used in place of a subdomain. An exclamation mark (!) at the start of a rule marks an exception to a previous wildcard rule.
| | Therefore, we are writing to ask you to view the current list and, if it is incorrect, to submit updated data. A description of the format of the list, and details for sending updates is <here>; the list 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>
| | Our data is made freely available under a liberal licence, and so can be used by other browser manufacturers and software authors who wish to institute similar security policies. We therefore hope that you will not have to notify any organisation other than us about such changes, thereby keeping the workload to a minimum. |
| .com // This is a comment
| |
| .co.uk
| |
| *.tokyo.jp
| |
| !metro.tokyo.jp
| |
| </pre>
| |
| | |
| The first line says that cookies may be set for any domain below .com. This line also has a comment, which will be ignored. The second line says that cookies may be set below .co.uk, and also implies that cookies may not be set directly below .uk. The third line says that cookies may be set for any domain below subdomains of .tokyo.jp. Therefore, for example, a cookie may be set for site.city.tokyo.jp but not for city.tokyo.jp or state.tokyo.jp. The last line is an exception to the line above, and says that cookies may be set for metro.tokyo.jp.
| |
| | |
| 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 the list should not take too much time and will help immensely with privacy protection for browser users. The list only needs to be updated when registration rules change, and so is very low maintenance.
| |
| | |
| Your participation in this program will be greatly appreciated.
| |
|
| |
|
| Thanking you in advance, | | Thanking you in advance, |