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

101–110 of 786 posts

Re: Firefox 85 cracks down on supercookies

#101

Post by pradn »

warent wrote: post #83
ogre_codes wrote: post #48

These advertising networks are destroying web performance. Most of these "Supercookies" are optimizations to improve performance. By abusing them, advertisers have turned what should be a great performance tool into a liability. I know FF suggests this won't significantly affect most websites performance, but web advertising and trackers are already responsible for a huge chunk of performance issues already. Of cours…

I run a network ad-block dns (pihole) and consistently 25-33% of all my network traffic is blocked as ads. It's much more than I ever imagined. Now I'm used to a different internet, when I'm using internet off the network it's like WTF is this?

Question about pihole: is it possible to turn off blocking for a website? Do you have to log into the pihole web interface to do that? I often go to websites where some crucial functionality is blocked by my adblocker (ublock origin), where I have to turn it off for that site.

Re: Firefox 85 cracks down on supercookies

#103

Post by ff4lyfer99 »

f430 wrote: post #77

is it just me or more people switching to Firefox these days?

I switched in late 2017 when they released quantum or neutrino or whatever they called it, a huge performance release.

As a backend dev and security focused eng I have little reason to test drive changes in all browsers.

FF has been smooth and stable for me across desktop OSs. Having no reason to alternate between that and Chrome, I’ve been confused by people saying it’s slow.

It’s been, to my memory, a flawless experience for 3+ years.

On the flip side, Chrome is a spy app, and a cognitive perception of web devs it’s faster does little to move me to use it.

Re: Firefox 85 cracks down on supercookies

#104

Post by chromaton »

danShumway wrote: post #81
chromaton wrote: post #16

Is this really important given that browser fingerprinting can almost always identify a web browser?

In a parallel reality: "Firefox 85 Cracks Down on Fingerprinting" "Is this really important given that supercookies can almost always persist between sessions and across domains?" ---- If you want to fix a problem, there are going to be points during that process where the problem is partially fixed. This only becomes an issue if we're headed in the wrong direction, or focusing on a sub-problem that would be better a…

You're right, of course. But let's not forget that fingerprinting exists and is going to be tough to eliminate.

Re: Firefox 85 cracks down on supercookies

#106

Post by Pet_Ant »

NelsonMinar wrote: post #64
cyberpro007 wrote: post #52

Doesn't NoScript do the same job?

Perhaps you are trolling? NoScript is a giant hammer that smashes 90% of the functioning parts of most modern web pages. This new feature in Firefox partitions caching in a way that mostly won't affect how a site works but will block one nefarious tracking technique.

It takes time to tune, but I find after a month of usage I rarely need to tweak things. The tweaking itself is eye opening as it really makes you more aware of what is going on.

Re: Firefox 85 cracks down on supercookies

#107

Post by amenod »

Good job Mozilla! Do what Google never will - put users' privacy front and center.

On a sidenote, I might now re-enable cache that I kept disabled (well - cleared on exit) because of supercookies. I don't care that much if a single page tracks me, but I _really_ don't want Google to track me across sites. If Firefox protected me against that.. they would have one very grateful user. :)

EDIT: this also highlights why Google is so invested in Chrome - they can make sure that privacy doesn't interfere with their money-making machine. They really are brilliant. Brilliantly evil.

Re: Firefox 85 cracks down on supercookies

#109

Post by guilhermetk »

pradn wrote: post #101
warent wrote: post #83

Earlier quoted context omitted.

I run a network ad-block dns (pihole) and consistently 25-33% of all my network traffic is blocked as ads. It's much more than I ever imagined. Now I'm used to a different internet, when I'm using internet off the network it's like WTF is this?

Question about pihole: is it possible to turn off blocking for a website? Do you have to log into the pihole web interface to do that? I often go to websites where some crucial functionality is blocked by my adblocker (ublock origin), where I have to turn it off for that site.

Yes, you can do that via whitelist/blacklist: https://docs.pi-hole.net/guides/misc/whitelist-blacklist/

Re: Firefox 85 cracks down on supercookies

#110

Post by tyingq »

nixpulvis wrote: post #85

I'm still trying to imagine the way one exploits a lack of partitioning in the DNS cache... 1. It seems like client web pages cannot directly view the DNS information for a given domain name. So I would think embedding identifying information in something like a CNAME or TXT record directly wouldn't work. 2. I suppose a tracker could try to create unique records for a given domain name and then use request/responses…

"I'm still trying to imagine the way one exploits a lack of partitioning in the DNS cache."

There's a PDF here: https://www.ndss-symposium.org/wp-content/uploads/2019/02/nd...

Basically timing based. See https://www.audero.it/demo/resource-timing-api-demo.html for a demo of what's available in the browser's navigation and resource timing API. For example, I get this on a cached reload:

domainLookupStart: 52.090000128373504

domainLookupEnd: 52.090000128373504

The PDF explains some enhancements that make it more reliable, like publishing multiple A records and watching order, etc. Also, the demo link isn't really showing what you would do...the resource being downloaded would be marked as non-cacheable so that you would be measuring "DNS lookup was cached or not" instead of "Entire Asset was cached, therefore no DNS lookup happened".

Post reply on HN