| |
| ▲ | xp84 3 hours ago | parent | next [-] | | It seems like it would be easily resolvable with TXT records these days. Anyone could try, say, on www.google.com to set a cookie for all of google.com, and the browser can fetch TXT records on google.com to see what, if any subdomains, it wants to allow this privilege for. Google could return a list or a wildcard; co.uk wouldn't allow any. In a world without advertising, there's no reason why google.com couldn't also allow *.youtube.com to set cookies for it, but of course that would cause a tremendous privacy freakout. Though in practice they can and do just send every login/logout through a 302 redirect roundtrip to take care of the cookies on youtube.com. | | |
| ▲ | dgoldstein0 10 minutes ago | parent [-] | | Totally agree that a DNS based replacement to the suffix list would make sense. Especially with more secure forms of DNS like DoH or Dnssec. That said I don't know about making cookies shareable across TLDs. That seems like allowing more privacy nightmares; at least today if you want to share you need complicated redirect dances that make you question if the user perf hit is worth it. I think there was some proposal for a mechanism for allowing non partitioned 3rd party cookies which seemed more sane to me, forget what the details were and if it ever made it beyond just a proposal. | | |
| |
| ▲ | lxgr 4 hours ago | parent | prev | next [-] | | It’s not nearly just cookies, and I think interpreting domain hierarchies as administrative structure generally does make sense. Maybe it could be opt-in or opt-out via some markers at the DNS level, though? The public suffix list having to exist at all is bizarre. | | |
| ▲ | amluto 4 hours ago | parent | next [-] | | An “administrative structure” seems fine, but the fact that a subdomain gets any sort of privilege over the parent has always seemed absurd to me. Surely a better solution would involve an actual request. login.foo.com could send a request to foo.com with Origin: login.foo.com asking to set a cookie, and foo.com could make its own decision. | | |
| ▲ | toast0 an hour ago | parent [-] | | That might be reasonable today, but it's not really reasonable at the time the policies were formed. If you require domain wide cookies be set from a webserver on the domain apex, the domain apex (for high volume destinations) needs to be set up for high volume webserving. High volume webserving often means at least geotargetted DNS, maybe a CDN, often anycast in today's reality. Back in the day, it was common for high traffic domains to run their DNS with a normal DNS server and then delegate (typically via CNAME) high volume subdomains off to a 3rd party DNS server for geotargetting (usually Akamai DNS, but there were others). But you can't CNAME the apex domain away. You'd have to delegate the whole domain to your DNS provider and then you have no way to manage an outage of your fancy DNS provider. Especially if you go back to the days where NetworkSolutions did a single daily zone update for .com ... if you wanted to switch to a new DNS provider for your domain, you would submit the change request and hope it happened in the 24 hours, but sometimes you'd miss the window (or there would be some process error) and it would happen much later. Less of a problem in today's world, where registries typically update the glue records in near real time (although many TLD servers have a 2 day TTL for glue, so you can't switch off a dead provider very quickly) and lots of domains seem comfortable with delegating the whole thing to their CDN. |
| |
| ▲ | markhahn 4 hours ago | parent | prev [-] | | that seems strange to me: why shouldn't policy leverage name resolution? sort of like dkim, but taken further. for instance, for site.com, I'd much rather retrieve its public key from DNS (some DNS++ version, of course). |
| |
| ▲ | dgoldstein0 13 minutes ago | parent | prev [-] | | There are use cases for cookies to affect multiple domains, like shared logins. Keep in mind multiple domains let's you run completely independent servers for different parts of your web presence but that doesn't mean that you want them to act independently. That said the dumbest thing with cookies is not sending their attributes in the cookie header which makes it impossible to distinguish expected cookies from tampered cookies set by insecure subdomains. __Host prefix is basically a workaround for this but took more than a decade to get into browsers. Samesite similarly was bolted on after the fact. Cookies aren't the only web security feature that follow sites instead of origins but they are the only one that was clearly designed without thinking through the consequences. |
|
