Hacker News Reader

Comment by unethical_ban | Hacker News Reader

I won't ask for a complete audit, but is there one example from the wizard that could break stuff, that is NOT called out by the wizard itself?

View on HN

That might be true for a technical user, but is the average user going to know that discord is broken because they disabled webrtc? Also, resistfingerprinting is going to significantly increase the difficulty of recaptcha challenges you encounter.

ResistFingerprinting is currently known to break Google's Recaptcha v3. Here is the Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1503872

I wonder just how much security relies on tracking. I know my VPN makes captchas an absolute nightmare.

I always have a hard time using some services when in incognito mode; I get the captchas, and either they are wrong or are really hard, and it can take several tries to get through them.

Because an error message should be displayed then.

I used to run Firefox with resist fingerprinting enabled. I believe it was causing chat time stamps on websites like WhatsApp to be incorrect, which was annoying but I don’t know if you consider that broken.

Yes I discovered that when viewing the TV guide on plex. Everything was an hour out (UK). I think with resist fingerprinting the timezone is set to UTC0. In the end I had to turn that setting off.

Ironically, checking for UTC+0 JavaScript time from an obviously-not-UTC+0 IP geolocation might give additional hints for fingerprinting, as does everything else that looks non-default, like odd language preferences or even a DNT header.

Good point. I'm pretty sure this component of resistFingerprinting is derived from Project Fusion, which uplifts privacy/anonymity-related changes from Tor Browser into Firefox. In the Tor Browser threat model, the idea is that you can't avoid looking like a Tor user, so the goal is to make all Tor users indistinguishable from each other. Flipping this pref as a regular Firefox user is incompatible with its primary intent/threat model, so it fails to deliver and may even make you _more_ identifiable in some circumstances.

This is a great example of why I'm generally skeptical of these scattershot approaches to making users more secure by changing default settings in mainstream browsers. Security and privacy features always entail tradeoffs and should be designed and implemented holistically for best results.

> should be designed and implemented holistically for best results

This is why I, a privacy-conscious individual, don't follow any of these guides in my Firefox. If you follow the discussion on Bugzilla, the weekly team meeting notes, and occasionally ask respectful questions on Mozilla IRC, you come to a similar conclusion to me in that the Firefox development community is doing the right thing in not enabling this by default.

It also breaks add-on compatibility because it sets your user agent to the last ESR version of Firefox, which may be several versions behind the version you're actually running.

That is resolved with 60.x ESR. First released in the early summer and has been the default since September. 52 had no support for webextensions

That's the compatibility issues for webextensions at all, but the bug still exists for extensions that declare compatibility ranges between the latest version and the previous ESR: https://bugzilla.mozilla.org/show_bug.cgi?id=1394448

Reply on news.ycombinator.com