Public suffix list Göran Weinholt (29 Nov 2020 09:03 UTC)
Re: Public suffix list Jakub T. Jankiewicz (29 Nov 2020 09:29 UTC)
Re: Public suffix list Göran Weinholt (29 Nov 2020 09:39 UTC)
Re: Public suffix list Magnus Ahltorp (29 Nov 2020 12:30 UTC)

Re: Public suffix list Magnus Ahltorp 29 Nov 2020 12:30 UTC

> 29 nov. 2020 10:39 Göran Weinholt <> wrote:
> "Jakub T. Jankiewicz" <> writes:
>>> So browers need to know which domain names operate as TLDs. The domain
>>> name is going to be acting in the same way as a TLD, so e.g.
>>> will be able to set and read cookies for
>>>, unless something is done about this.
>> I don't think that Web allow to set cookies for different domains, that is
>> impossible, there is something called Origin in browser, which is domain +
>> port + protocol. And only if it's the same cookies are sent. Do you have any
>> article that will show this is not the case?
>> I think that the public suffix is only needed for browsers that hide the
>> part of the URL. I read somewhere that Chrome is considering do that for
>> instance if page is it will only show in
>> address bar, unless browser is told that is like TLD. This is the
>> only reason I can know of when this is needed.
>> There are no any security reason why would need to be like TLD,
>> unless you have something that will confirm what you're saying.
> I should have included a reference for this, of course. I might very
> well be wrong in my explanation or maybe my information is out of date,
> but I'm referring to "supercookies":
> <>
> I think this bug report demonstrates quite well how it was before the
> PSL: <>.
> This is also one of the reason for having the PSL, listed on
> <>:
> | It allows browsers to, for example:
> |
> | * Avoid privacy-damaging "supercookies" being set for high-level
> |   domain name suffixes
> | * Highlight the most important part of a domain name in the user
> |   interface
> | * Accurately sort history entries by site

As far as I understand it, what a subdomain can do is that it can set "default" cookies for the whole domain. It cannot read cookies from other domains (such as hijacking a forum login or an admin interface). This means three things:
1) An application using cookies on a subdomain of would have to take into account that a cookie might already be set.
2) The top-level should not be a website, and either not exist, or redirect to
3) Since subdomains are able to cooperate in privacy-infringing schemes unless forbidden, subdomains should not be allowed to share privacy-damaging information by setting cookies.

Since privacy-infringing activities are not allowed at all on, even setting a tracking cookie on your own domain is forbidden. However, setting a cookie for the top-level should be regarded as extra damaging. There are legitimate uses for cookies on (such as the above mentioned forum logins and admin interfaces), but as a website operator, you should be very careful and only set them when it is absolutely necessary.