4 ms·
Maybe I don't know enough about cookies but it's kind of shocking that that this wasn't the behavior from day one. I suppose it's one of many things designed fo
by orblivion 6y ago
Maybe I don't know enough about cookies but it's kind of shocking that that this wasn't the behavior from day one. I suppose it's one of many things designed for a simpler time, but so many of those have been fixed by now.
- foepys 6y agoThere is so much legacy tech out there that is still working on the trust level from back when DNS was a hosts file you manually copied to your system once in a while. BGP and SS7 are other famous examples.
- bscphil 6y agoKind of an important point: this appears to be an attempt to make third party cookies useless, without actually disabling them since many sites depend on them. This is achieved in two ways: 1. By allowing third party cookies, but compartmentalizing them by the first-party site that sent the request (a much better name for this feature would be "per-site cookie containers", "total cookie protection" is completely uninformative). 2. By using a heuristic to selectively allow cookies to be accessed across the container boundary if they are actually needed, e.g. for logins. To answer your question, this doesn't make sense as "day one behavior" because it's basically a patch to work around a historical problem with as little breakage as possible. If you were setting up cookie permissions on day one, knowing what we know now, you wouldn't kneecap third party cookies, you'd disable them entirely. Mozilla is trying to make third party cookies useless for 99% of what they're used for: if that's how you feel about third party cookies, you'd just not implement them. Incidentally, I do block all third party cookies by default and have for years. That's a much stronger approach than the compartmentalization that Mozilla is attempting. I can count on one hand the number of sites I've seen break because of this, most of them are happy to let these cookies fail silently.