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

681–690 of 786 posts

Re: Firefox 85 cracks down on supercookies

#681

Post by tuna-piano »

bigiain wrote: post #578
kortilla wrote: post #539

Earlier quoted context omitted.

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...)

It would be easy to check that...

Re: Firefox 85 cracks down on supercookies

#682

Post by andrewflnr »

scrollaway wrote: post #644
andrewflnr wrote: post #590

Earlier quoted context omitted.

That's an entirely different question to whether it should be on by default for random sites, which is what GP is actually talking about. I would go farther and say that there was never a time that it looked reasonable.

Don't you think JS being so available is part of what made it so popular, and thus what made it accessible, and what brought programming to millions who wouldn't have done it otherwise?

I think that asking users "do you want to let this site run JavaScript?" would have been an acceptable trade-off in availability.

Re: Firefox 85 cracks down on supercookies

#683

Post by scrollaway »

andrewflnr wrote: post #682
scrollaway wrote: post #644

Earlier quoted context omitted.

Don't you think JS being so available is part of what made it so popular, and thus what made it accessible, and what brought programming to millions who wouldn't have done it otherwise?

I think that asking users "do you want to let this site run JavaScript?" would have been an acceptable trade-off in availability.

Look up alert fatigue.

Re: Firefox 85 cracks down on supercookies

#684

Post by scrollaway »

emptyparadise wrote: post #675
scrollaway wrote: post #586

Earlier quoted context omitted.

> 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…

Applications can exist outside of the web too.

That's not my point. You wouldn't have had the development speed we've had the last 30 years. You wouldn't have had the same amount of devs. The same pickup on the web. The same worldwide connectivity.

Javascript is one of the, if not the, most influential technologies of the past 100 years. It changed the course of history. Can you say the same of, like, wxWidgets or whatever UI toolkit you'd be using for your native app?

Re: Firefox 85 cracks down on supercookies

#685

Post by yc12340 »

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

ETags and Last-Modified headers can be used for long-term user tagging, but without Javascript they provide a lot less value in terms of tracking.

Suppose, that you are visiting a web site with Evil Embedding (an iframe tag or script, that loads Evil Resource on behalf of advertiser). If your browser requests Evil Resource without telling advertiser the name of top-level site, the advertiser gets little. They get to know, that user 9062342154 is online and they are asking for Evil Resource X, but that's all. They can't even tell, which specific website is being visited!

The real problems start, when the top level web site cooperates with advertiser by running a Javascript "bridge", that acts both as an arbiter and a communication channel for siphoning your information. In addition to transferring information, the bridge acts as anti-fraud measure to confirm, that there is no foul play on the part of web site operator. Since the script is Turing-complete and can be updated anytime, there is no way to restrict it's actions.

Re: Firefox 85 cracks down on supercookies

#686

Post by varenc »

letitbeirie wrote: post #328
varenc wrote: post #239

Earlier quoted context omitted.

I just have my network block outgoing DNS queries that aren’t from the gateway. But you’re so right that DoH is going to throw a wrench in this.

If an ad can use DoH to sidestep a firewall, so can an employee. If Google and Facebook were cunning (and nefarious, but that much is presumed), they would be aggressively developing a product that solves this problem for corporate networks, but at an enormous cost. Otherwise, when corporate networks solve this (and they will), home users who hate ads will just follow whatever pattern they settle on.

Encrypted DNS is going to upset a lot of corporate network management/monitoring... But the switch to HTTPS for everything caused similar frustration for IT admins awhile ago.

In the corporate world, I think the future is managing your network by managing every single device on your network. Only let authorized/corp devices in and all those devices must be enrolled in an MDM solution that enforces all sorts of policy and includes monitoring traffic/DNS queries. Of course that's a lot more work than just monitoring things at the network level.

Re: Firefox 85 cracks down on supercookies

#687

Post by opensmtpd »

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…

JS brought both problems and benefits. The fact that it brought benefits doesn't prove that it didn't bring problems.

I think we could have done better if we knew what we were doing.

Re: Firefox 85 cracks down on supercookies

#688

Post by Ice_cream_suit »

"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. To prevent this possibility, Firefox 85 uses a different image cache for every website a user visits. That means we still load cached images when a user revisits the same site, but we don’t share those caches across sites.

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."

Clever !

Re: Firefox 85 cracks down on supercookies

#689

Post by 6nf »

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.

Bad actors is how we discover these vulnerabilities in the first place!

Re: Firefox 85 cracks down on supercookies

#690

Post by [deleted] »

leesalminen wrote: post #579
warent wrote: post #561

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN