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
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.
> 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.
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.
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.
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.
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).
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).
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.
Facebook Container is a stricter form of protection for Facebook specifically, so no, you should continue using it if you're interested in isolating Facebook.
Total Cookie Protection is about isolating third party cookies/web storage, without breaking as much of the web as simply blocking third party cookies does.
I think Cookie Protection does solve the problem that I used the containers for. I wasn't really using it to keep accounts separate, per se, but more to keep companies like Google from snooping and sneaking peeks at my other cookies.
I wonder if there's anyone from any advertising/ad-targeting companies on HN who can shed some light on if/how much this change may affect their "product".
Asking this since I know friends working at companies that were DRASTICALLY affected by the Apple advertising changes in terms of user targetability (and hence revenue) and I'm wondering if this change will be similar.
Cookies are the easiest way to shore and share information but far from the only way. If it affects someone's product, it is not hard to fingerprint browsers.
Not in an ad targeting company, but given Firefox current marketshare and their previous anti tracking measures, I doubt this will make a that much of a difference. But if the feature attracts loads of Chrome users then at least the ad companies relying on third-party cookies will feel it. Obviously if you are currently targeting Firefox users and your company is not in the current tracker list then I assume you will see significant drop
It appears Safari is just blocking the cookies, while Firefox is isolating the cookies. I guess Safari has to keep track of who to block while Firefox just isolates everybody. Are there other benefits to the Firefox approach?
Frankly, I have a hard time understanding why this Cookie Sandbox approach wasn't implemented a long time ago. I get that 25 years ago we weren't concerned about privacy, but there has been plenty of time to fix this. Advertiser influence?
It would be nice to allow users to create "trusted tuples" to list small groups of domains that are allowed to share their cookies. For instance: Zendesk, Asana, Jira, etc.
But have each tuple listed still be isolated from the other, only domains listed together in a single list could share a cookie container.
Very cool to see more privacy by default in Firefox.
It is still a lot of effort to have clear separations in every browsern...
I am using Firefox containers with the temporary containers plugins (with history deletion enabled) as well as cookies auto delete plugin (which supports containers).
Therefore, everything is usually isolated in a container inside a tab and only white listed cookies are kept in the named containers.
I've never understood the thinking that went behind allowing one site to see the existence of another site's cookie in the first place. I don't think I'm even coming at this with the security hindsight of decades, it's just common sense, isn't it?
It's that multiple sites will serve content (ads, Javascript libraries, like buttons) from a common site (eg an ad network) that uses its own domain.
That domain is allowed to get the cookie for itself because it is referenced by multiple site, that's how this type of tracking works.
If you go to bbc.com, it still won't be able to see cookies from cnn.com, but say if advert.com is included by both sites, then it will see that you visited them both.
That's the power and great danger that things like facebook and google sense represent.
The owner of the sites get some stats for free by using these services, but the biggest benefit is for google and facebook to be able to track what users are looking at accross the web. And you just need to be identifiable on one site that you visit (say, FB or gmail) for them to know exactly who you are.
From what I understand, Firefox will only allow advert.com to get the cookie it created when being loaded as part of bbc.com, but it won't be able to read its own cookie from cnn.com, it will have to create a new, separate one, thus breaking the link tracking you between sites, or at least making it harder to connect the dots.
Sites A and B both include content from the spying website S, which sets some cookies. Now S can correlate your visits to A and B because it's able to read its own cookies.
This change makes it so that requests A -> S (requests from A to S) and B -> S are treated as A -> S1 and B -> S2 instead.
Now S1 cannot read cookies from S2 and vice versa, even though they are the same site.
Sites can't see the existence of other sites' cookies. They can, however, request resources from other sites. Those requests, in turn, would send third-party cookies, if any, to the third-party server _and_ save new third-party cookies in response. "Tracking beacons" abuse this behavior to correlate user behavior across many web sites.
I never understood it (third party cookies getting external information) either. Same thing with the referer request header, or user agents, or disabling the right-click menu, or editing the browser history, or opening new windows, or changing scroll behavior, or replacing the cursor icon, or autoplaying videos. There are reasons to want to do these things. In some cases it's difficult for the browser to prevent them. But I'd sure like it if the standards and browsers were on my side, not the side of those nefarious web developers.
It depends on the specific third party login service. Some rely on third party storage-sharing, and there are web compatibility measures built into Total Cookie Protection to allow those to keep working.
One is that the login service can request access from the user using a new web API (requestStorageAccess). Another is heuristics which apply when the user interacts with the page in a way which implies a login might be taking place.
I don't think they rely on third party cookies. You are redirected to the SSO provider which then issues a token which it transports back to the requesting site through other means than cookies (i.e. post body / query string)
Depends on the specific implementation, but in theory this doesn't limit any functionality for SSO. Data can be shared via mechanisms other than cookies.
This feature protects domains, not sessions. SSO relies on passing tokens over redirects, not cookies. As long as your redirected, the SSO uses their own first party cookies. You would be logged in to the SSO provider no matter who redirected you there.
And can someone explain how I'm supposed to implement SSO? We have a bunch of subdomains that support SSO by communicating with an iframe that has the logon status stored, but it appears that the iframe wouldn't have access to its own data anymore. Is that right?
I wonder why Microsoft doesn't make Edge a privacy-oriented browser. I'm surprised they think they can make more from the data economy than they would gain by seriously hurting Google et al.
I remember losing a bet a while back, because I was naive enough to think that was how cookies worked in the first place. Why did other sites ever have access to cookies they didn’t create was beyond me.
If anyone wonders how bad the situation RE cookies is there is a local newspaper owner in the UK called reach PLC who own 100+ newspaper websites.
Their cookie allow dialog has over 700 data share partners, not including their own "legitimate interest" cookies. The dialog looks like this [1] and cannot be resized and is lazy loaded (i.e. you have to manually scroll to have the page load all of them with a few visible each scroll). And its slow so it takes a while and doesn't play well with the mouse in the iframe. There are even ones not in english or latin characters [2]
I know Firefox has a small market share, but this is the sort of feature other browsers may adopt. Maybe not the big boys like Chrome or Edge, but I could see all the niche privacy focused browsers implementing it and maybe even Safari given Apples claims to support user privacy. If a certain percentage of browsers started to use similar functionality I could tracking companies starting to develop countermeasures.
In fact I've already encountered one site that gave me a popup telling me to enable third party cookies. It was one of those dodgy sites that scrapes and copies Stack Overflow content and the JavaScript that enabled it was very clunky - but it worked. I'm surprised there aren't more websites already doing something similar.
[+] [-] agluszak|3 years ago|reply
[+] [-] tyingq|3 years ago|reply
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.
[+] [-] dahart|3 years ago|reply
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.
[+] [-] ravenstine|3 years ago|reply
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.
[+] [-] dec0dedab0de|3 years ago|reply
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.
[+] [-] pwg|3 years ago|reply
[1] https://en.wikipedia.org/wiki/Browser_cookie#History
[+] [-] pas|3 years ago|reply
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).
[+] [-] Xylakant|3 years ago|reply
[+] [-] Thorrez|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] c0balt|3 years ago|reply
[+] [-] zagrebian|3 years ago|reply
[+] [-] letmeinhere|3 years ago|reply
[+] [-] wisniewskit|3 years ago|reply
Total Cookie Protection is about isolating third party cookies/web storage, without breaking as much of the web as simply blocking third party cookies does.
[+] [-] mello151|3 years ago|reply
I think Cookie Protection does solve the problem that I used the containers for. I wasn't really using it to keep accounts separate, per se, but more to keep companies like Google from snooping and sneaking peeks at my other cookies.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] madmax108|3 years ago|reply
Asking this since I know friends working at companies that were DRASTICALLY affected by the Apple advertising changes in terms of user targetability (and hence revenue) and I'm wondering if this change will be similar.
[+] [-] unicornporn|3 years ago|reply
[+] [-] YetAnotherNick|3 years ago|reply
[+] [-] tamha|3 years ago|reply
[+] [-] jalk|3 years ago|reply
[+] [-] dev_tty01|3 years ago|reply
https://support.apple.com/guide/safari/prevent-cross-site-tr...
It appears Safari is just blocking the cookies, while Firefox is isolating the cookies. I guess Safari has to keep track of who to block while Firefox just isolates everybody. Are there other benefits to the Firefox approach?
Frankly, I have a hard time understanding why this Cookie Sandbox approach wasn't implemented a long time ago. I get that 25 years ago we weren't concerned about privacy, but there has been plenty of time to fix this. Advertiser influence?
[+] [-] bitwrangler|3 years ago|reply
But have each tuple listed still be isolated from the other, only domains listed together in a single list could share a cookie container.
[+] [-] GRBurst|3 years ago|reply
It is still a lot of effort to have clear separations in every browsern...
I am using Firefox containers with the temporary containers plugins (with history deletion enabled) as well as cookies auto delete plugin (which supports containers).
Therefore, everything is usually isolated in a container inside a tab and only white listed cookies are kept in the named containers.
[+] [-] ghusto|3 years ago|reply
[+] [-] Renaud|3 years ago|reply
It's that multiple sites will serve content (ads, Javascript libraries, like buttons) from a common site (eg an ad network) that uses its own domain. That domain is allowed to get the cookie for itself because it is referenced by multiple site, that's how this type of tracking works.
If you go to bbc.com, it still won't be able to see cookies from cnn.com, but say if advert.com is included by both sites, then it will see that you visited them both. That's the power and great danger that things like facebook and google sense represent.
The owner of the sites get some stats for free by using these services, but the biggest benefit is for google and facebook to be able to track what users are looking at accross the web. And you just need to be identifiable on one site that you visit (say, FB or gmail) for them to know exactly who you are.
From what I understand, Firefox will only allow advert.com to get the cookie it created when being loaded as part of bbc.com, but it won't be able to read its own cookie from cnn.com, it will have to create a new, separate one, thus breaking the link tracking you between sites, or at least making it harder to connect the dots.
Everyone should use FF.
[+] [-] feanaro|3 years ago|reply
This change makes it so that requests A -> S (requests from A to S) and B -> S are treated as A -> S1 and B -> S2 instead.
Now S1 cannot read cookies from S2 and vice versa, even though they are the same site.
[+] [-] ComodoHacker|3 years ago|reply
[+] [-] ajvs|3 years ago|reply
[+] [-] mdavidn|3 years ago|reply
[+] [-] aimor|3 years ago|reply
[+] [-] flipbrad|3 years ago|reply
[+] [-] rdsubhas|3 years ago|reply
[+] [-] wisniewskit|3 years ago|reply
One is that the login service can request access from the user using a new web API (requestStorageAccess). Another is heuristics which apply when the user interacts with the page in a way which implies a login might be taking place.
In these cases, specific third parties can be granted access to allow the login. There are some more details here: https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage...
[+] [-] jalk|3 years ago|reply
[+] [-] Strom|3 years ago|reply
[+] [-] kayodelycaon|3 years ago|reply
[+] [-] ezfe|3 years ago|reply
[+] [-] three14|3 years ago|reply
[+] [-] bityard|3 years ago|reply
Which one do they think is the most private and secure browser for Linux?
[+] [-] Animats|3 years ago|reply
[+] [-] legalcorrection|3 years ago|reply
[+] [-] eslaught|3 years ago|reply
[+] [-] kuon|3 years ago|reply
This is great news. I really hope we will not lose firefox. I'm not saying it is better than chromium, but I think it is important that it exists.
[+] [-] lucasyvas|3 years ago|reply
That setting breaks a few things, but mostly works OK. I'm confused which protection level this new capability corellates to.
[+] [-] mastermedo|3 years ago|reply
[+] [-] easytiger|3 years ago|reply
Their cookie allow dialog has over 700 data share partners, not including their own "legitimate interest" cookies. The dialog looks like this [1] and cannot be resized and is lazy loaded (i.e. you have to manually scroll to have the page load all of them with a few visible each scroll). And its slow so it takes a while and doesn't play well with the mouse in the iframe. There are even ones not in english or latin characters [2]
[1] https://imgur.com/a/ciuRWSx [2] https://i.imgur.com/4yc6Flo.png
Anyway i lazy loaded all of them and there are 753 (the html just to display it is > 1 megabyte
It's crazy[+] [-] xnorswap|3 years ago|reply
[+] [-] DoubleGlazing|3 years ago|reply
In fact I've already encountered one site that gave me a popup telling me to enable third party cookies. It was one of those dodgy sites that scrapes and copies Stack Overflow content and the JavaScript that enabled it was very clunky - but it worked. I'm surprised there aren't more websites already doing something similar.
[+] [-] dmw_ng|3 years ago|reply