2 ms·

What would make a lot more sense is a DNS mechanism for domains to indicate their subdomains are trusted/untrusted with parent domain cookies, possibly with a w

by throwaway2048 7y ago

What would make a lot more sense is a DNS mechanism for domains to indicate their subdomains are trusted/untrusted with parent domain cookies, possibly with a white/blacklist mechanism. It would be a lot more manageable than some centralized list that tries to capture every user controllable content domain on the internet.

regecks 7y ago
No thanks. There are already too many DNS lookups and TCP connections a user-agent has to make in 2019: - OCSP if not stapled. - IPv4/IPv6 racing/Happy Eyeballs. - Encrypted SNI (DNS lookup). - Certificate Transparency: some Chrome builds are now querying logs to confirm embedded SCTs (if I understood correctly). and now: - Related Domains by DNS (draft-brotman-rdbd-02), or whatever replaces the PSL. RDBD would have to be in the critical path (in order to understand the cookie scope), it's just going to make things slow and complex. Are we also gonna give the same treatment to the HSTS preload list?
- throwaway2048 7y ago
  DNS requests don't need to be serial, blocking load, its easy to issue a burst of them at once. Virtually every user agent is already doing this I don't see the downside of that. Not sure why you feel there is arbitrarily "too many", do you have a concrete objection?
  - regecks 7y ago
    Extra queries are a gamble that you don't encounter latency on any of the important ones, right? For example, on mobile data when you're hitting packet loss. I'm not so fussed about extra queries when they do not delay the user. But if we send out a RDBD query that a resolver doesn't respond to in a speedy manner, what does the user-agent do if it needs to decide how to scope a cookie? You can't exactly soft-fail something like that ...
sleevi 7y ago
This has been a common suggestion since before the Publix Suffix List existed, as you can see from the linked issues in the text (and the references to the IETF DBOUND WG). Like most things, on first glance, it seems like it does make sense. Except it has a lot of issues, which you can see have been discussed for 15 years without resolution, even though yes, it would scale better.

regecks 7y ago

No thanks. There are already too many DNS lookups and TCP connections a user-agent has to make in 2019: - OCSP if not stapled. - IPv4/IPv6 racing/Happy Eyeballs. - Encrypted SNI (DNS lookup). - Certificate Transparency: some Chrome builds are now querying logs to confirm embedded SCTs (if I understood correctly). and now: - Related Domains by DNS (draft-brotman-rdbd-02), or whatever replaces the PSL. RDBD would have to be in the critical path (in order to understand the cookie scope), it's just going to make things slow and complex. Are we also gonna give the same treatment to the HSTS preload list?

throwaway2048 7y ago
DNS requests don't need to be serial, blocking load, its easy to issue a burst of them at once. Virtually every user agent is already doing this I don't see the downside of that. Not sure why you feel there is arbitrarily "too many", do you have a concrete objection?
- regecks 7y ago
  Extra queries are a gamble that you don't encounter latency on any of the important ones, right? For example, on mobile data when you're hitting packet loss. I'm not so fussed about extra queries when they do not delay the user. But if we send out a RDBD query that a resolver doesn't respond to in a speedy manner, what does the user-agent do if it needs to decide how to scope a cookie? You can't exactly soft-fail something like that ...

sleevi 7y ago

This has been a common suggestion since before the Publix Suffix List existed, as you can see from the linked issues in the text (and the references to the IETF DBOUND WG). Like most things, on first glance, it seems like it does make sense. Except it has a lot of issues, which you can see have been discussed for 15 years without resolution, even though yes, it would scale better.