> 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