Public Suffix List: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
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,

Revision as of 15:38, 8 March 2007

The effective TLD list is an attempt to build a database of top-level domains and their respective registry's policies on domain registrations at different levels.

Currently, browsers use an algorithm which basically only denies setting wide-ranging cookies for top-level domains with no dots (e.g. com or org). However, this does not work for top-level domains where only third-level registrations are allowed (e.g. co.uk). In these cases, websites can set a cookie for co.uk which will be passed onto every website registered under co.uk.

Clearly, this is a security risk as it allows websites other than the one setting the cookie to read it, and therefore potentially extract sensitive information.

Since there is no algorithmic method of finding the highest level at which a domain may be registered for a particular top-level domain (the policies differ with each registry), the only method is to create a list of all top-level domains and the level at which domains can be registered. This is the aim of the effective TLD list.

As well as being used to prevent cookies from being set where they shouldn't be, the list can also potentially be used for other applications where the registry controlled and privately controlled parts of a domain name need to be known, for example when grouping by top-level domains.

Data collection

Maintaining an up-to-date list of all top-level domains and policies is clearly a vast task, and therefore each registry will be asked to maintain their own section of the database and email any changes to the effective TLD list maintenance team, who will then merge it with the master database.

Registries for all top-level domains will be contacted by email (possibly via an ICANN mailing list) that will inform them of the intentions of the effective TLD list, how to participate and formats for data files.

Tasks to do

  1. Choose and set up a contact email address
  2. Send the email to all TLD registries
  3. 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)
  4. Monitor the contact email address regularly and manage changes
  5. Make the effective TLD list file available to other browser manufacturers

Name

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

The email address for submissions has not yet been decided.

Email address monitoring

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

Dear Sir,

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".

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>

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.

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>.

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.

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.

Thanking you in advance,

The Mozilla Public Suffix List Team

Links

TLD Lists

Mozilla Bug Reports

Internet Drafts

Articles

--Rubena 14:38, 6 March 2007 (PST)

Retrieved from "https://wiki.mozilla.org/index.php?title=Public_Suffix_List&oldid=51173"