8 ms·

Why weren't separate cookie jars the default in the first place? I know that browsers other than Firefox have no real incentive to protect your privacy, but I'm

Why weren't separate cookie jars the default in the first place? I know that browsers other than Firefox have no real incentive to protect your privacy, but I'm wondering why cookies were designed to be shared among different pages in general

Xylakant 4y ago
Cookies were invented at Netscape like 25 years ago, nobody considered the current situation.
- _jal 4y ago
  Yes they did. It was foreseen, look at the sibling comment where the issue was discussed in the spec. They just punted, just like they did with https and CAs. (And Javascript, for that matter, although that's less directly security-related.) The concern was being first to market, not with solid engineering.
ravenstine 4y ago
There are legit cross-domain use cases. A good example is how someone here mentioned (comment seems deleted though) account sessions being shared between Atlassian products like JIRA and BitBucket. The problem with that is domains are a poor way of representing ownership that can be trusted. If the web was rebuilt from scratch, a better approach might be to allow cookies to be shared between secure sites using the same certificate. But that adds more complexity that I'm not sure is worthwhile. The web can absolutely get away with not having shared cookies.
- deleted 4y ago
  [deleted]
- vman81 4y ago
  There are also legit use cases for leaving all your doors unlocked. But they usually aren't really worth considering when you are installing your doors/locks.
- layer8 4y ago
  > allow cookies to be shared between secure sites using the same certificate Or maybe encrypting cookies using the site certificate, which would still allow cookies to be shared with domains having a different certificate, but the server needs the correct key for decryption.
  - exo762 4y ago
    Ciphertext leaks information via its size and its presence / absence.
    - dylan604 4y ago
      yeah and so? how is this information useful? if the actual useful information is encrypted, then size is meaningless as it is just random text until decrypted. presence/absence? you have a cookie or you don't?
      - recursive 4y ago
        You say the size is meaningless. But sometimes it may actually be meaningful. And presence/absence is information also. Not much, but it definitely exists.
        dylan604 4y ago
        In what way? If I'm storing 255 bytes of username/email/credentials/settings/etc, but pad in some fun way to 512 bytes prior to encryption, what in the world does knowing that the cookie is 512 bytes do you? You have no idea what data is stored. You don't know if there are 512 bytes of actual data, 128 bytes with lots of fluff, or anything at all other than 512 bytes. Hell, it could be 0 bytes of data and 512 bytes of random data that I submit to every single person that visits the site just to fuck with people like you! You seem like you need something to do ;-)
        recursive 4y ago
        If the contents of the cookie is a JSON array of recently viewed items, then the size is correlated to whether I've been actively viewing items recently. Adding random padding makes it harder to get a signal, but with a high enough sample size, it's still possible to get some information. If you always pad to a fixed size, then there's probably no useful information. At the moment, I think I have enough to do, but I'll probably be looking for something new in the next few weeks. Got any novel single player video game recommendations?
- notriddle 4y ago
  There’s no technical reason why this has to be hard. If jira was at jira.atlassian.com and bitbucket was bitbucket.atlassian.com, they would have the same origin, plus they would make the relationship between them visible to any moderately savvy user. It’s only complicated because they allow their marketing dept to make it complicated.
  - oefrha 4y ago
    You do realize acquisitions occur?
    - dylan604 4y ago
      you do realize reorganization occur after acquisitions?
    - notriddle 4y ago
      So use a 301 redirect.
    - abdullahkhalids 4y ago
      Business operation complications are not a valid reason for the violation of the rights of humans.
      - Thorrez 4y ago
        Cross-domain cookies are a tool that can be used for good or bad. It's a tradeoff to block them or not block them.
  - filmgirlcw 4y ago
    I think that’s unfair. By tying things to domains that way, you also make it potentially difficult to change URL structure (look at how long the various go.com domains lasted across all Disney/ABC properties. I know of teams that had very real problems years later b/c the infra was still based on domain stuff that was setup 15 years prior when the parent company thought internet portals were worth spending billions on), not to mention if you want to spin-off or sell an asset. Or if you acquire an asset! To say nothing of SSOs, where you might not want to carry your login across, but you’d like to have the option of saying “yes, I’d like to use this account here too” and then authenticate.
- Groxx 4y ago
  Isn't this solved with a login redirect? Just return a signed ID and set up cookies on the other end with that. Granted, it's one more redirect per domain than before per login period, but that's hardly onerous. Domains that want to collaborate together can still do so.
  - deleted 4y ago
    [deleted]
- Thorrez 4y ago
  > allow cookies to be shared between secure sites using the same certificate In some ways that will be less strict than Firefox's implementation. A CDN might have a certificate with hundreds of unrelated sites in it. In some ways that will be more strict than Firefox's implementation. A site might want to serve large static files on static.foo.com but a secure login page on login.foo.com , and want to hand over the private key for static.foo.com to a CDN but not hand over the private key for login.foo.com .
c0balt 4y ago
While I'm not a friend of tracking via cookies nor tracking in general there is some utility there. For example SSO may be done over cookies, like oauth iirc. I don't know of many other use cases though that couldn't be contained with header etc.
tyingq 4y ago
RFC2109, from 1997, had this: 8.3 Unexpected Cookie Sharing A user agent should make every attempt to prevent the sharing of session information between hosts that are in different domains. Embedded or inlined objects may cause particularly severe privacy problems if they can be used to share cookies between disparate hosts. For example, a malicious server could embed cookie information for host a.com in a URI for a CGI on host b.com. User agent implementors are strongly encouraged to prevent this sort of exchange whenever possible.
- hedora 4y ago
  It's really weird that they claim there privacy work started in 2015. Netscape Navigator add cross site cookie blocking at some point, and firefox has always (?) had it. The innovation here seems to be that they further partition by the URL in the address bar. It's frustrating that browsers have been fighting and losing this war for 25 years. (Presumably they still don't block browser fingerprinting, so sites will just move to that instead...)
  - staticassertion 4y ago
    It's not possible to block browser fingerprinting since it's a range of techniques and heuristics based on numerous features. There's no "turn off fingerprinting" button you can just press.
    - sillysaurusx 4y ago
      Whonix says hello. https://www.whonix.org/ https://www.whonix.org/ I was planning to use it exclusively when I was working on a system to fight cartels, so I got pretty deep into these kinds of questions. Whonix has its own problems but it's the best solution available. The communities are interesting too. One fellow was trying to download map data, which confused me initially. Why was he so fixated on maps? It's because if you're in the middle of a warzone, there's obviously no cell service, and it might be a few weeks before you reach an area with wifi. Remarkably prescient given that this was 2013 or so. But you're right in general that there's no way to do it that isn't a pain in the ass for most people. "I can't resize my browser window? Really?"
pwg 4y ago
Cookies first appeared in Netscape on Oct 13, 1994 [1]. In 1994 the 'web' was a very different place and the current environment of web tracking and invasive advertising companies simply did not exist. And no one saw the privacy invading potential at the time. [1] https://en.wikipedia.org/wiki/Browser_cookie#History https://en.wikipedia.org/wiki/Browser_cookie#History
- jeltz 4y ago
  Yes, but someone here quoted an RFC showing that while people may not have understood this in 1994 they did in 1997. And now 25 years later the privacy issue was fixed.
- PaulDavisThe1st 4y ago
  > And no one saw the privacy invading potential at the time. Maybe not the privacy invasion potential but ... As we got started building amzn in the fall of 94, it was a no-brainer decision to not use cookies even though they were just arriving. The controversy around the idea was intense and it was far from clear that they would be a success as a technology. It is likely true that there was more attention being paid to the "what? it lets a remote server create a file on my driver?" angle than the privacy one.
  - shubhamkrm 4y ago
    How did you manage session information without using cookies?
    - PaulDavisThe1st 4y ago
      http://yourdomain.com/path/to/something?SESSION=af2828c119ae1 and yes, all URLs in every page were rewritten during page generation to include the session ID.
      - marshray 4y ago
        Didn't that break bookmarks?
dec0dedab0de 4y ago
The web was designed to be highly interconnected. Deep linking is a feature. Cookies are set via headers. If you load an image from another domain, the headers from that domain could set their own cookies, and your browser will give each domain every cookie it has set. That is, cookies aren't shared, they're locked down to the domain that set them. It's just that some domains have content loaded by millions of pages. This change won't protect you much if you have a relatively stable IP address without many users on it, because your IP is still in the third party domains logs. This welcome change makes it harder to differentiate people on the same IP, or to track a browser as it changes IPs. As I'm typing this, I'm remembering how helpful IPv6 is for people who want to track everyone.
- tialaramex 4y ago
  If you need Onion Routing then you need Onion Routing. IPv6 Privacy Addressing gives you roughly the same properties you had with IPv4 NAT except now when you did want a stable address you've got one. Multi address is much healthier in IPv6, so it's reasonable for your browser to even spin up an address associated with a Porn tab, and then destroy it again when you close that tab, while still using your other IPv6 address for a post you make meanwhile to Hacker News. It's also reasonable (while it was often likely to cause mysterious problems in IPv4) to give your local web server a long-lived IPv6 address while your web browser's address changes every hour.
- diea 4y ago
  Hmm... I think IPv6 might be actually better. Apple for example will generate and use a temporary IPv6 which changes every few hours to protect your privacy.
  - leaflets2 4y ago
    Can't one look at the first parts of an IPv6 and roughly know anyway who it is? I've read that one can only control the last parts of ones IPv6 space -- the first, one gets from ones ISP?, can they be enough to know who one is?
dahart 4y ago
> Why weren’t separate cookie jars the default in the first place? Tracking today is an interaction between cookies and pages, not really because cookies were designed to be shared between domains. Because of that, ads on web pages are a reason that information gets shared across sites. Any ad or other iFramed content that’s served on a site can get the domain name of where it’s be served from and then access the iFrame domain’s cookies, which enables tracking. The cookie jar language might be a tiny bit oversimplifying/confusing in the sense that cookies are already separated from each other according to the cookie’s domain - they’re already in separate jars in a way, and this feature is changing how they partition the jars. Assuming even the most strict privacy settings, tracking cookies and scripts are often in iFrames and may not have the ability to directly read other cookies from the web site in your URL bar, and the web site might not be able read the tracking cookies. It’s not that cookies themselves are being shared per se. It’s that (say) Facebook is allowed to put an iFramed tracker on some site, and Facebook can then get a tracking blip when you visit that site and add it to a Facebook-only cookie. Total Cookie Protection is going to put cookies that only Facebook can see in a different jar for each separate site you visit, making it so that Facebook can’t read it’s own cookies across different sites.
- Agamus 4y ago
  The solution still seems to be to: 1. Use Firefox, block .js by default, and selectively allow. 2. Set browser to block cross-site cookies, and to purge all cookies when closing browser. 3. Avoid tabbed browsing, and restart browser after using a website. I've been doing this since about 2006. It's inconvenient, but gives some peace of mind.
  - dahart 4y ago
    That’d certainly prevent most tracking, yeah. This new Firefox feature should make #2 and #3 unnecessary. I think this feature by Firefox is great, and privacy options are getting objectively better, if slowly. But the cynic in me guessing that server side tracking methods are going to start getting secretly better, if they haven’t already.
    - 4y ago
zagrebian 4y ago
Why didn’t cars have safety belts in the first place?
pas 4y ago
the web was directly bolted on top of the classic client-server network model. there was no concept of a website, just a bunch of requests needed to render whatever the markup (and the dynamic scripting stuff) wanted. the interaction of those is completely left as an exercise to the (standards) readers. initially only remote code execution was a problem (eg. cross-site scripting), then the usual cross-site request forgery problems. and sure, there was all the usual gimmicks with list of sites you probably visited because it was possible to fingerprint by CSS plus exploiting cache timings. initially framesets were all the jazz. you got free hosting and the provider just put your stuff inside a FRAME and the ad went above in a different frame. serious sites had money to pay for hosting and SSL certs. and even if someone stole some credit card numbers the solution was easy, just use paypal! privacy was seen as something to think about only when someone asked you a/s/l (age, sex, location), so basically when interacting with other humans in chat rooms (or on forums). ... of course slowly but surely software (more exactly the Internet) is eating the world. being online is the default. Alphabet, the 8th on the Fortune 500 list doesn't even have brick and mortar stores (oh well, there's one in NYC and during this year's Google I/O they announced the second, also in NYC).
deleted 4y ago
[deleted]
Thorrez 4y ago
The cookie jar was already partitioned by domain. It's non-obvious that the correct design is to partition it by 2 domains (the domain in the HTTP request and the domain in the URL bar).

Xylakant 4y ago

Cookies were invented at Netscape like 25 years ago, nobody considered the current situation.

_jal 4y ago
Yes they did. It was foreseen, look at the sibling comment where the issue was discussed in the spec. They just punted, just like they did with https and CAs. (And Javascript, for that matter, although that's less directly security-related.) The concern was being first to market, not with solid engineering.

ravenstine 4y ago

There are legit cross-domain use cases. A good example is how someone here mentioned (comment seems deleted though) account sessions being shared between Atlassian products like JIRA and BitBucket. The problem with that is domains are a poor way of representing ownership that can be trusted. If the web was rebuilt from scratch, a better approach might be to allow cookies to be shared between secure sites using the same certificate. But that adds more complexity that I'm not sure is worthwhile. The web can absolutely get away with not having shared cookies.

deleted 4y ago
[deleted]
vman81 4y ago
There are also legit use cases for leaving all your doors unlocked. But they usually aren't really worth considering when you are installing your doors/locks.
layer8 4y ago
> allow cookies to be shared between secure sites using the same certificate Or maybe encrypting cookies using the site certificate, which would still allow cookies to be shared with domains having a different certificate, but the server needs the correct key for decryption.
- exo762 4y ago
  Ciphertext leaks information via its size and its presence / absence.
  - dylan604 4y ago
    yeah and so? how is this information useful? if the actual useful information is encrypted, then size is meaningless as it is just random text until decrypted. presence/absence? you have a cookie or you don't?
    - recursive 4y ago
      You say the size is meaningless. But sometimes it may actually be meaningful. And presence/absence is information also. Not much, but it definitely exists.
      - dylan604 4y ago
        In what way? If I'm storing 255 bytes of username/email/credentials/settings/etc, but pad in some fun way to 512 bytes prior to encryption, what in the world does knowing that the cookie is 512 bytes do you? You have no idea what data is stored. You don't know if there are 512 bytes of actual data, 128 bytes with lots of fluff, or anything at all other than 512 bytes. Hell, it could be 0 bytes of data and 512 bytes of random data that I submit to every single person that visits the site just to fuck with people like you! You seem like you need something to do ;-)
        recursive 4y ago
        If the contents of the cookie is a JSON array of recently viewed items, then the size is correlated to whether I've been actively viewing items recently. Adding random padding makes it harder to get a signal, but with a high enough sample size, it's still possible to get some information. If you always pad to a fixed size, then there's probably no useful information. At the moment, I think I have enough to do, but I'll probably be looking for something new in the next few weeks. Got any novel single player video game recommendations?
notriddle 4y ago
There’s no technical reason why this has to be hard. If jira was at jira.atlassian.com and bitbucket was bitbucket.atlassian.com, they would have the same origin, plus they would make the relationship between them visible to any moderately savvy user. It’s only complicated because they allow their marketing dept to make it complicated.
- oefrha 4y ago
  You do realize acquisitions occur?
  - dylan604 4y ago
    you do realize reorganization occur after acquisitions?
  - notriddle 4y ago
    So use a 301 redirect.
  - abdullahkhalids 4y ago
    Business operation complications are not a valid reason for the violation of the rights of humans.
    - Thorrez 4y ago
      Cross-domain cookies are a tool that can be used for good or bad. It's a tradeoff to block them or not block them.
- filmgirlcw 4y ago
  I think that’s unfair. By tying things to domains that way, you also make it potentially difficult to change URL structure (look at how long the various go.com domains lasted across all Disney/ABC properties. I know of teams that had very real problems years later b/c the infra was still based on domain stuff that was setup 15 years prior when the parent company thought internet portals were worth spending billions on), not to mention if you want to spin-off or sell an asset. Or if you acquire an asset! To say nothing of SSOs, where you might not want to carry your login across, but you’d like to have the option of saying “yes, I’d like to use this account here too” and then authenticate.
Groxx 4y ago
Isn't this solved with a login redirect? Just return a signed ID and set up cookies on the other end with that. Granted, it's one more redirect per domain than before per login period, but that's hardly onerous. Domains that want to collaborate together can still do so.
- deleted 4y ago
  [deleted]
Thorrez 4y ago
> allow cookies to be shared between secure sites using the same certificate In some ways that will be less strict than Firefox's implementation. A CDN might have a certificate with hundreds of unrelated sites in it. In some ways that will be more strict than Firefox's implementation. A site might want to serve large static files on static.foo.com but a secure login page on login.foo.com , and want to hand over the private key for static.foo.com to a CDN but not hand over the private key for login.foo.com .

c0balt 4y ago

While I'm not a friend of tracking via cookies nor tracking in general there is some utility there. For example SSO may be done over cookies, like oauth iirc. I don't know of many other use cases though that couldn't be contained with header etc.

tyingq 4y ago

RFC2109, from 1997, had this: 8.3 Unexpected Cookie Sharing A user agent should make every attempt to prevent the sharing of session information between hosts that are in different domains. Embedded or inlined objects may cause particularly severe privacy problems if they can be used to share cookies between disparate hosts. For example, a malicious server could embed cookie information for host a.com in a URI for a CGI on host b.com. User agent implementors are strongly encouraged to prevent this sort of exchange whenever possible.

hedora 4y ago
It's really weird that they claim there privacy work started in 2015. Netscape Navigator add cross site cookie blocking at some point, and firefox has always (?) had it. The innovation here seems to be that they further partition by the URL in the address bar. It's frustrating that browsers have been fighting and losing this war for 25 years. (Presumably they still don't block browser fingerprinting, so sites will just move to that instead...)
- staticassertion 4y ago
  It's not possible to block browser fingerprinting since it's a range of techniques and heuristics based on numerous features. There's no "turn off fingerprinting" button you can just press.
  - sillysaurusx 4y ago
    Whonix says hello. https://www.whonix.org/ https://www.whonix.org/ I was planning to use it exclusively when I was working on a system to fight cartels, so I got pretty deep into these kinds of questions. Whonix has its own problems but it's the best solution available. The communities are interesting too. One fellow was trying to download map data, which confused me initially. Why was he so fixated on maps? It's because if you're in the middle of a warzone, there's obviously no cell service, and it might be a few weeks before you reach an area with wifi. Remarkably prescient given that this was 2013 or so. But you're right in general that there's no way to do it that isn't a pain in the ass for most people. "I can't resize my browser window? Really?"

pwg 4y ago

Cookies first appeared in Netscape on Oct 13, 1994 [1]. In 1994 the 'web' was a very different place and the current environment of web tracking and invasive advertising companies simply did not exist. And no one saw the privacy invading potential at the time. [1] https://en.wikipedia.org/wiki/Browser_cookie#History https://en.wikipedia.org/wiki/Browser_cookie#History

jeltz 4y ago
Yes, but someone here quoted an RFC showing that while people may not have understood this in 1994 they did in 1997. And now 25 years later the privacy issue was fixed.
PaulDavisThe1st 4y ago
> And no one saw the privacy invading potential at the time. Maybe not the privacy invasion potential but ... As we got started building amzn in the fall of 94, it was a no-brainer decision to not use cookies even though they were just arriving. The controversy around the idea was intense and it was far from clear that they would be a success as a technology. It is likely true that there was more attention being paid to the "what? it lets a remote server create a file on my driver?" angle than the privacy one.
- shubhamkrm 4y ago
  How did you manage session information without using cookies?
  - PaulDavisThe1st 4y ago
    http://yourdomain.com/path/to/something?SESSION=af2828c119ae1 and yes, all URLs in every page were rewritten during page generation to include the session ID.
    - marshray 4y ago
      Didn't that break bookmarks?

dec0dedab0de 4y ago

The web was designed to be highly interconnected. Deep linking is a feature. Cookies are set via headers. If you load an image from another domain, the headers from that domain could set their own cookies, and your browser will give each domain every cookie it has set. That is, cookies aren't shared, they're locked down to the domain that set them. It's just that some domains have content loaded by millions of pages. This change won't protect you much if you have a relatively stable IP address without many users on it, because your IP is still in the third party domains logs. This welcome change makes it harder to differentiate people on the same IP, or to track a browser as it changes IPs. As I'm typing this, I'm remembering how helpful IPv6 is for people who want to track everyone.

tialaramex 4y ago
If you need Onion Routing then you need Onion Routing. IPv6 Privacy Addressing gives you roughly the same properties you had with IPv4 NAT except now when you did want a stable address you've got one. Multi address is much healthier in IPv6, so it's reasonable for your browser to even spin up an address associated with a Porn tab, and then destroy it again when you close that tab, while still using your other IPv6 address for a post you make meanwhile to Hacker News. It's also reasonable (while it was often likely to cause mysterious problems in IPv4) to give your local web server a long-lived IPv6 address while your web browser's address changes every hour.
diea 4y ago
Hmm... I think IPv6 might be actually better. Apple for example will generate and use a temporary IPv6 which changes every few hours to protect your privacy.
- leaflets2 4y ago
  Can't one look at the first parts of an IPv6 and roughly know anyway who it is? I've read that one can only control the last parts of ones IPv6 space -- the first, one gets from ones ISP?, can they be enough to know who one is?

dahart 4y ago

> Why weren’t separate cookie jars the default in the first place? Tracking today is an interaction between cookies and pages, not really because cookies were designed to be shared between domains. Because of that, ads on web pages are a reason that information gets shared across sites. Any ad or other iFramed content that’s served on a site can get the domain name of where it’s be served from and then access the iFrame domain’s cookies, which enables tracking. The cookie jar language might be a tiny bit oversimplifying/confusing in the sense that cookies are already separated from each other according to the cookie’s domain - they’re already in separate jars in a way, and this feature is changing how they partition the jars. Assuming even the most strict privacy settings, tracking cookies and scripts are often in iFrames and may not have the ability to directly read other cookies from the web site in your URL bar, and the web site might not be able read the tracking cookies. It’s not that cookies themselves are being shared per se. It’s that (say) Facebook is allowed to put an iFramed tracker on some site, and Facebook can then get a tracking blip when you visit that site and add it to a Facebook-only cookie. Total Cookie Protection is going to put cookies that only Facebook can see in a different jar for each separate site you visit, making it so that Facebook can’t read it’s own cookies across different sites.

Agamus 4y ago
The solution still seems to be to: 1. Use Firefox, block .js by default, and selectively allow. 2. Set browser to block cross-site cookies, and to purge all cookies when closing browser. 3. Avoid tabbed browsing, and restart browser after using a website. I've been doing this since about 2006. It's inconvenient, but gives some peace of mind.
- dahart 4y ago
  That’d certainly prevent most tracking, yeah. This new Firefox feature should make #2 and #3 unnecessary. I think this feature by Firefox is great, and privacy options are getting objectively better, if slowly. But the cynic in me guessing that server side tracking methods are going to start getting secretly better, if they haven’t already.
  - 4y ago

zagrebian 4y ago

Why didn’t cars have safety belts in the first place?

pas 4y ago

the web was directly bolted on top of the classic client-server network model. there was no concept of a website, just a bunch of requests needed to render whatever the markup (and the dynamic scripting stuff) wanted. the interaction of those is completely left as an exercise to the (standards) readers. initially only remote code execution was a problem (eg. cross-site scripting), then the usual cross-site request forgery problems. and sure, there was all the usual gimmicks with list of sites you probably visited because it was possible to fingerprint by CSS plus exploiting cache timings. initially framesets were all the jazz. you got free hosting and the provider just put your stuff inside a FRAME and the ad went above in a different frame. serious sites had money to pay for hosting and SSL certs. and even if someone stole some credit card numbers the solution was easy, just use paypal! privacy was seen as something to think about only when someone asked you a/s/l (age, sex, location), so basically when interacting with other humans in chat rooms (or on forums). ... of course slowly but surely software (more exactly the Internet) is eating the world. being online is the default. Alphabet, the 8th on the Fortune 500 list doesn't even have brick and mortar stores (oh well, there's one in NYC and during this year's Google I/O they announced the second, also in NYC).

deleted 4y ago

[deleted]

Thorrez 4y ago

The cookie jar was already partitioned by domain. It's non-obvious that the correct design is to partition it by 2 domains (the domain in the HTTP request and the domain in the URL bar).