
Configuring and hardening Firefox privacy, security and anti-fingerprinting - dcassett
https://github.com/ghacksuserjs/ghacks-user.js
======
clouddrover
Firefox 67 beta exposes some of these settings (like blocking cryptominers and
fingerprinters) in the UI:

[https://blog.mozilla.org/futurereleases/2019/04/09/protectio...](https://blog.mozilla.org/futurereleases/2019/04/09/protections-
against-fingerprinting-and-cryptocurrency-mining-available-in-firefox-nightly-
and-beta/)

~~~
PantsyWantsy
Hi, I created this one-time account to address some comments in this news item

I'm Thorin-Oakenpants, the creator and maintainer of the ghacks user.js. I
don't want to get into a long discussion, if you want that then bring it up in
the github repo.

\---

The FF67+ changes that introduce cryptomining and fingerprinting protection
have nothing to with anything in the user.js (except Tracking Protection
preferences - which we have not included, and the TP prefs that are there are
all inactive and not applied - we're happy to leave the defaults up to
Firefox). TP's fingerprinting is about blocking fingerprinting __scripts __,
whereas actual anti-fingerprinting in terms of privacy.resistFingerprinting or
disabling WebGL etc are about stopping JS etc leaking too much entropy in the
first place.

------
jeroenhd
Very interesting concept, although not very usable for me as it stands right
now. This collection of settings disables features like HTTP/2 and websockets
for some reason.

Furthermore, if you're the only person in your city using Firefox with very
different behaviour, that just makes you easier to fingerprint. If you want to
resist fingerprinting, wait for Firefox's fingerprint protection to advance
and keep everything as close to default as possible instead.

~~~
lorenzhs
It also disabled IPv6, form auto filling, and automatic updates of Firefox.
Like 99% of these projects, lots of questionable choices here. I never
understand why people would recommend applying hundreds of settings without
understanding what they do. It’s registry cleaner-level of irresponsible
(breaks tons of things for little to no benefit). To be fair, in the
“Implementation” page (???) of the project wiki, the authors state _“ULTRA
UBER IMPORTANT. Do not just take the user.js and use it with your profile.
There are some considerations to make first that concern your online security
etc”_ , but nothing of the sorts is in the readme or even the overview wiki
page.

~~~
shabbyrobe
The file is liberally annotated with explanatory comments though. It's really
useful if you want to cherry-pick the things that matter to you.

~~~
acdha
The problem is that those comments are often speaking from a position of
unwarranted authority - for example, the section on HTTP/2 is simply wrong but
if you didn’t understand the technology the tone would make you think the
author is making a reasoned trade-off.

~~~
PantsyWantsy
I refer to you my earlier comments about my background (for your info: take it
or leave it), and about HTTP2 in particular.

I agree with you that OFTEN the web is full of shit and bullsitters, but I
would just like to say, that I am NOT one of them. I'm not always right, so
please, if you can correct me in any way, I am more than willing to listen and
correct my mistakes. Thanks

------
acdha
This has a bunch of dangerous advice such as disabling updates, protection
against unsafe downloads, disabling saved passwords, and things which make the
web worse for users such as disabling IPv6, HTTP/2, caching, etc. with a
rationale which is basically “I don’t understand what this does so it must be
bad”.

Using the default Firefox with the suggested privacy features enabled is much
safer than installing something like this.

~~~
PantsyWantsy
Last reply. sorry for bombarding you guys and gals.

It doesn't disable updates, it only disabled the auto-installing of updates.
Bit of a difference. However, I was reminded/prompted to change our default on
extension auto-installing their updates. APP updates you get repeated
notifications from Firefox, in your face. So I do not consider this a risk,
especially given our user base. I also updated the wiki to make all of this
clear. Of course users should update - I've never said otherwise

Safe Browsing has never been disabled, except the real time binary checks with
Google. And this has always been pointed out. And the user.js itself says not
to mess with TP or SB any further - i.e at your own risk. And we even had
Francois from Mozilla who worked on all of this, to give us the inside scoop
and correct details on exactly how all of these work. The header says that
there are no privacy or security issues (outside the real time binary checks).
Given the user-base, this has never been an issue as far as I can see. But as
a default, I can see it maybe putting someone at risk - but I'm not here to
babysit the internet - the end user has to take some responsibility of where
they get binaries and so on.

The user.js has NEVER ever disabled password saving.

IPv6, HTTP2 have been commented on elsewhere. There are reasons for them being
disabled - 50/50 call on those really. The thing is, that they don't break
anything.

Cache is a lot trickier. There are certainly tracking/privacy issues with
cache, but usually you also need to disable memory cache - we only disable
disk cache. It's also not really a speed factor - I've browsed like this for
nigh on 8 years. Most content isn't pulled from cache: it's dynamic. Cache is
almost a throwback to dial up days. What is pulled from cache, is usually
tiny, the js libraries, css, nav sections, footers. The big content is media
and images, and that's usually distinct per page. That's a pretty broad
generalization. Yes, you will get a speed boost, and it may be worthwhile for
you.

One of the reasons these very few issues all you guys have brought up (cache,
http2 etc) have come up, is because, while this project is not trying to be
the Tor Browser (we actively tell people to use that if it fits their needs),
it does follow it's design: such as disk avoidance, app isolation (e.g not
leaving MRUs in external places), and more, and even going as further with
shoulder surfing issues - but I've relaxed that quite a bit in the default
user.js, as I believe this should be in the hands of the end-user: e.g encrypt
your device, don't allow shoulder surfers, and just basic safe OpSec.
Otherwise all it does is reduce functionality.

I never just disable things because "I don't understand it therefore it must
be bad", in fact I do the opposite. There must be a benefit: enhances
security, privacy etc. And it's always weighed against breakage, how much the
API is used, risk assessment, etc. There's almost always pros and cons. For
example, we don't disable geo, because that's behind a prompt, and the user is
already protected. But you'll find hundreds of other "lists" doing just that.
I could name dozens more that we don't do - because while they sound good,
actually achieve nothing and only create barriers for those who actually use
them (gamepads, vr instantly spring to mind: default for permissions is
another)

Anyway, thanks guys. Got to say what I needed to. And made changes thanks to
your comments - 1 pref change (so far, maybe another) and a revamped cleaner
wiki page. Hope you now see this project in a different light.

------
fulafel
Does it work on mobile?

~~~
jeroenhd
With some effort, yes: [https://github.com/ghacksuserjs/ghacks-
user.js/wiki/1.6-Fire...](https://github.com/ghacksuserjs/ghacks-
user.js/wiki/1.6-Firefox-Android)

It doesn't work on iOS because Firefox on iOS isn't really Firefox but just a
Safari webview with a bunch of extra features and a different logo.

