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

571–580 of 786 posts

Re: Firefox 85 cracks down on supercookies

#571

Post by appleflaxen »

avodonosov wrote: post #541

We need to acknowledge also that recognising the user as he moves across pages and domains is sometimes needed to provide valuable services to the user. Therefore, I believe, browsers have to provide a volunteer "tracking" functionality - when a web page reqests 3rd party cookies, a popup is shown to the user with the cookie values, description (as set by the owning domain), the list of domains already permitted to a…

Perhaps, but that mechanism doesn't need to persist in the browser across termination of execution.

Re: Firefox 85 cracks down on supercookies

#572

Post by austincheney »

simias wrote: post #422
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.

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…

> Note that the root of all evil here is Javascript

Not exactly.

The root of all evil here is HTTP. You don’t need any JavaScript to plant cookies or other tracking assets. As a proof this technique is used to track users in email, such as embedding a 1 pixel image in an email retrieved via HTTP.

Re: Firefox 85 cracks down on supercookies

#573

Post by tannhaeuser »

philote wrote: post #330
mikl wrote: post #216

Earlier quoted context omitted.

I think you’re overestimating the impact of this. Most web site content these days are served from the web site owner’s own domain. It’s only if a.com and b.com have (for example) the exact same image URL (c.com/img123.jpg) embedded, and you visit both sites, that this cache partitioning will make a difference. In essence, there’s very little legitimate Internet traffic that would be effected by this change, but lots…

What about JS libraries or CSS hosted by a CDN? I'm thinking jQuery, Bootstrap, etc etc. I learned that using a common CDN was the way to go because the content would likely already be in the user's cache and often not need to be loaded.

CDNs are/were not only or even primarily used for caching but to minimize bulk traffic to your site and prevent hitting max concurrent per-domain HTTP request limits and HTTP/1.1 head-of-line blocking.

Re: Firefox 85 cracks down on supercookies

#574

Post by goflyapig »

simias wrote: post #422
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.

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 sounds like they're talking about ETags [1] here. I don't think JavaScript has anything to do with it.

[1] https://en.wikipedia.org/wiki/HTTP_ETag#Typical_usage

Re: Firefox 85 cracks down on supercookies

#575

Post by tannhaeuser »

derefr wrote: post #42
iscrewyou wrote: post #5

Earlier quoted context omitted.

Google websites work better on chrome. Not sure if it’s because google is doing something nefarious or if Firefox is just not keeping up with google website technologies. So, I’ve trained my brain to use chrome as an app only for google websites. When I need to check gmail or YouTube or google calendar, I use chrome. Otherwise I’m on Firefox or safari. It’s worked pretty well. I found I was only really unhappy with F…

It’s the latter, but I would describe it less as Firefox not “keeping up”, and more as Google deploying pre-standard protocols (like SPDY) into Chrome first , before ever documenting the protocol; let alone trying to get it turned into a standard (like HTTP/2.) Chrome had SPDY support not just before any other web browser did, but before any open web server did—because Chrome had SPDY support before Google ever docum…

It's also relevant under an antitrust PoV.

Re: Firefox 85 cracks down on supercookies

#576

Post by viraptor »

whalesalad wrote: post #569
viraptor wrote: post #559

Earlier quoted context omitted.

Sign-in cookies are always first party. That's completely out of context here where we're taking about tracking cookies.

I’m not familiar with a distinct “sign in cookie” either. Do you mean a server side cookie / HttpOnly?

It's basically a cookie holding your session id, scoped only to the site and used only for auth purposes (or holding the session vars if you're doing client-side sessions)

Re: Firefox 85 cracks down on supercookies

#577

Post by surround »

avodonosov wrote: post #541

We need to acknowledge also that recognising the user as he moves across pages and domains is sometimes needed to provide valuable services to the user. Therefore, I believe, browsers have to provide a volunteer "tracking" functionality - when a web page reqests 3rd party cookies, a popup is shown to the user with the cookie values, description (as set by the owning domain), the list of domains already permitted to a…

Which valuable services? I’ve had 3rd party cookies entirely disabled for a while now, and I haven’t noticed any services break, not even cross domain logins.

Re: Firefox 85 cracks down on supercookies

#578

Post by bigiain »

kortilla wrote: post #539
callmeal wrote: post #389

Earlier quoted context omitted.

Instead of thinking "same image on different domains, think "hidden uniquely-named single pixel image".

That’s the same thing. In order for that tracking method to work, this uniquely named pixel has to be loaded while visiting multiple sites. So it ends up being multiple domains referencing the same image from some tracker resource.

So a Facebook like button? Or a Twitter logo link?

I suspect you'll find this is _way_ more common than you expect.

(Also, if you thing Goog aren't doing this with their font CDN or various javascript library coaches, even (or especially) for sites without Google Analytics... I've got a bridge to sell you...)

Re: Firefox 85 cracks down on supercookies

#579

Post by leesalminen »

warent wrote: post #561
pkulak wrote: post #161

Earlier quoted context omitted.

I run Pi-Hole on my network as well; it's wonderful. I'm terrified that it will stop working soon though, as companies start to use their own DNS servers, which I've heard is happening.

I'm not sure I understand how this is related to pi-hole. Your computer sends the raw domain name to pi-hole (e.g. ads.google.com), and pi-hole returns 0.0.0.0 if it's on the block list. There's nothing Google or anyone can do to make pi-hole stop working.

IoT devices are starting to use hardcoded DNS servers instead of using the one provided by DHCP, which negates the benefits of Pi-Hole on those devices.

For now, I've configured my router to force all UDP port 53 traffic to my Pi-Hole which overrides what I mentioned above.

But, in the future we may start to see IoT Devices hard-code DoH servers which will be harder to force over to the Pi-Hole.

Re: Firefox 85 cracks down on supercookies

#580

Post by simias »

goflyapig wrote: post #574
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 sounds like they're talking about ETags [1] here. I don't think JavaScript has anything to do with it. [1] https://en.wikipedia.org/wiki/HTTP_ETag#Typical_usage

Ooh, that's interesting. The way it was described made me think that you needed some JS to check if the data was in cache or not.

I guess it's probably a bad idea to let the browser send this type of potentially unique info to the server by default, but I understand how it makes sense from a performance perspective.

As far as I'm concerned privacy should always trump performance, but I realize that not everybody shares this point of view.

Post reply on HN