Comment 89 for bug 44062

(In reply to comment #82)
> I think the only secure solution to this problem is to allow setting cookies to
> the current domain, port and connection type (HTTP/HTTPS) only (and strip out
> "domain" and "secure" flags from requests). This could break a few sites, but
> site owners could work around it.

That would completely break sites like Google, Yahoo!, and countless others, which set a login cookie to "google.com" and then use that cookie on other domains, such as "maps.google.com", "mail.google.com", "movies.yahoo.com", etc., etc.

There would not be any workaround for that. The only way would be to use the same domain "www.google.com" for every part of the site - which is not always practical (ex. when the separate domains point to servers in different physical locations.)

I personally think a much better solution is either at the HTTP header level or, even better, the DNS level. Some provision in DNS to communicate permissions seems most logical, e.g. in a TXT record. This would be accessible before the request is sent, cache-able, and reasonably efficient.

Example: the __security.google.com might be set to 2 (.google.com), while __security.dnsalias.net might be 3 (.example.dnsalias.net).

Thus putting the effective TLD in DNS (where they can be determined by other parties, which negates your NEVER.) That said, I guess the question is whether queries are performed for each part - __security.co.uk, __security.yahoo.co.uk, __security.movies.yahoo.co.uk, etc.

Even so, the effective TLD solution is simple and effective for the greater part of the current problems without causing any false positives.

-[Unknown]