Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox 85 cracks down on supercookies

blog.mozilla.org

Post reply on HN
Print view View original

601–610 of 786 posts

Re: Firefox 85 cracks down on supercookies

#601

Post by 3gg »

dazbradbury wrote: post #515

Worth pointing out that Chrome has been partitioning cache by domain since chrome 86 (released Oct 6th 2020). https://developers.google.com/web/updates/2020/10/http-cache... Does anyone know if these protections go further or differ significantly?

That was the first thing that came to mind when I read this article. It looks very similar, though Firefox seems to be addressing more than just resource caching, like addressing the HSTS tracking scheme. Also, I would not be surprised if Chrome eventually did partitioning for anything but Google resources; they surely won't do anything that hurts their surveillance schemes?

Re: Firefox 85 cracks down on supercookies

#602

Post by dkarl »

scrollaway wrote: post #586
simias wrote: post #422

Earlier quoted context omitted.

Note that the root of all evil here is Javascript being opt-out instead of opt-in (and effectively mandatory for a big chunk of the internet these days). Letting any website and their friends (and the friends of their friends) run turing complete code on the client PC probably sounded reasonable when the web was created but it seems incredibly naive in hindsight. It's not as bad as ActiveX and other plugins, but it's…

> it seems incredibly naive in hindsight Oh stop with the dramatics, please. JS has brought us an immense amount of innovation on the web. It has lowered the barrier of entry to programming and introduced tens of millions of people to the world of development. If you're on HN the odds are that directly or indirectly, JS is one of the reasons you have a job today, and that you can execute it remotely. And today specif…

It can have been incredibly naive and have brought great benefit at the same time. In the 1990s did we foresee that in 2021, tracking our individual web activity and building profiles of our behavior would be a pillar of the business model supporting most of the online economy? Did we foresee that we would be looking to government regulation to prevent comprehensive profiles of our individual web browsing activity from being sold by private companies, and bought not only by other private companies but by government agencies as well? No? Then I think we were, in hindsight, naive. I'm not denying any of the benefits of Javascript by saying that. We did not foresee all of the upside of Javascript, but we were naive about the costs, too.

Re: Firefox 85 cracks down on supercookies

#604

Post by CogitoCogito »

Daho0n wrote: post #519
CogitoCogito wrote: post #510

Earlier quoted context omitted.

Regulation seems appropriate.

So different website features per country? Or do you mean regulation decides how a browser implements it? Either way I don't see how that would ever work.

You are aware there are country-specific (or even more local) regulations covering companies today right? In fact essentially all regulations are. So why are you acting like my proposition is somehow unprecedented?

Re: Firefox 85 cracks down on supercookies

#605

Post by danielheath »

CydeWeys wrote: post #595

> In fact, there are many different caches trackers can abuse to build supercookies. Firefox 85 partitions all of the following caches by the top-level site being visited: HTTP cache, image cache, favicon cache, __HSTS cache__, OCSP cache, style sheet cache, font cache, DNS cache, HTTP Authentication cache, Alt-Svc cache, and TLS certificate cache. (emphasis mine) This has negative effects on security, as has been po…

Aren't most CDNs (at least, the ones likely to have popular resources on several sites) using the hsts preload list already?

Re: Firefox 85 cracks down on supercookies

#606

Post by arendtio »

aembleton wrote: post #556
arendtio wrote: post #471

Is there any reason to keep the Same Origin Policy after this change? I mean, shouldn't this change defeat CSRF attacks?

No, this won't defeat CSRF attacks. All this does is create a separate cache for each site, so that they can't infer that a user has already been to another site. It makes no changes to POST/PUT/PATCH requests to an endpoint. They will still be going there.

Okay, I thought it would also keep the browser from sending cookies/authentication data, it received via another origin.

Re: Firefox 85 cracks down on supercookies

#607

Post by peteretep »

ghayes wrote: post #325
Jonnax wrote: post #18

"In the case of Firefox’s image cache, a tracker can create a supercookie by “encoding” an identifier for the user in a cached image on one website, and then “retrieving” that identifier on a different website by embedding the same image." Clever. And so frustrating that optimisations need to be turned off due to bad actors.

I'm curious how bad disabling this caching feature would be. Specifically, how often do you load the same image on two different domains?

It answers this question in the article; negligible performance hit

Re: Firefox 85 cracks down on supercookies

#608

Post by asddubs »

avodonosov wrote: post #581
asddubs wrote: post #546

Earlier quoted context omitted.

this exists on safari, edge and FF https://developer.mozilla.org/en-US/docs/Web/API/Document/re... https://developer.mozilla.org/en-US/docs/Web/API/Storage_Acc... on safari, it's basically the only way to get access to third party cookies in an iframe since safari 13. I wish other browsers (chrome) would also enable this when third party cookies are disabled. On FF I think the rule is that you have to interact with t…

Wow, interesting. So, to access 3rd party cookies I need to access a document DOM object that has that 3rd party origin? But such a document is not always available, is it... Looks like the use cases targeted by that proposal are limited to an embedded iframe that wants to access its own domain cookies. I was thinking also about arbitrary doman. Like requestStorageAccess(targetOrigin, keys...)

Yeah, it's useful for e.g. embedded like buttons or comment forms on external sites or sites with user hosted content (on a different TLD)

Re: Firefox 85 cracks down on supercookies

#609

Post by a1369209993 »

mikem170 wrote: post #588
xg15 wrote: post #508

Earlier quoted context omitted.

And how would you address this problem?

I browse in firefox with javascript turned off, in ublock, with a bunch of other restrictions [0], and temporary containers. I make exceptions for a couple dozen sites, like my bank, open street maps, etc. Youtube is my only soft spot here, the rest of google I keep blocked. I can make one-off exceptions to read a tab in front of me, but that's not routine, it's not hard to find sites that support this. [0] https://g…

> Youtube is my only soft spot here

http://youtube-dl.org/

Re: Firefox 85 cracks down on supercookies

#610

Post by dozzman »

bigiain wrote: post #582
jimmydorry wrote: post #565

Earlier quoted context omitted.

It makes sense from a $$ and resource usage stand point. I have to assume the best here and believe that the people arguing on there being no merit to CDN hosting of shared libraries all forgetting the two most important things a business must consider. Every byte sent will cost the business. If you can save that 2MB per user per cache life, you pay that much less on the internet bill for your hosting. Every byte sen…

> If your site is 10KB and you rely on 2MB of javascript libraries and fonts, ... then you're doin' it wrong.

> ... then you're doin' it wrong.

100%. Its mind blowing that this could possibly be considered without batting an eyelid.

Post reply on HN