Public suffix list
Göran Weinholt
(29 Nov 2020 08:59 UTC)
|
Re: Public suffix list
Jakub T. Jankiewicz
(29 Nov 2020 09:28 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 <xxxxxx@weinholt.se> wrote: > > "Jakub T. Jankiewicz" <xxxxxx@onet.pl> writes: > >>> So browers need to know which domain names operate as TLDs. The domain >>> name .scheme.org is going to be acting in the same way as a TLD, so e.g. >>> mallory.scheme.org will be able to set and read cookies for >>> alice.scheme.org, 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 mallory.scheme.org it will only show scheme.org in >> address bar, unless browser is told that scheme.org is like TLD. This is the >> only reason I can know of when this is needed. >> >> There are no any security reason why scheme.org 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": > > <https://en.wikipedia.org/wiki/HTTP_cookie#Supercookie> > > I think this bug report demonstrates quite well how it was before the > PSL: <https://bugzilla.mozilla.org/show_bug.cgi?id=252342>. > > This is also one of the reason for having the PSL, listed on > <https://publicsuffix.org/>: > > | 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 scheme.org would have to take into account that a .scheme.org cookie might already be set. 2) The top-level scheme.org should not be a website, and either not exist, or redirect to www.scheme.org. 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 .scheme.org cookies. Since privacy-infringing activities are not allowed at all on scheme.org, 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 scheme.org (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. /Magnus