15 ms·

Configuring and hardening Firefox privacy, security and anti-fingerprinting

110 points by dcassett 8y ago

clouddrover 8y ago
Firefox 67 beta exposes some of these settings (like blocking cryptominers and fingerprinters) in the UI: https://blog.mozilla.org/futurereleases/2019/04/09/protections-against-fingerprinting-and-cryptocurrency-mining-available-in-firefox-nightly-and-beta/ https://blog.mozilla.org/futurereleases/2019/04/09/protectio...
- PantsyWantsy 7y ago
  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.
fulafel 8y ago
Does it work on mobile?
- jeroenhd 8y ago
  With some effort, yes: https://github.com/ghacksuserjs/ghacks-user.js/wiki/1.6-Firefox-Android https://github.com/ghacksuserjs/ghacks-user.js/wiki/1.6-Fire... 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.
jeroenhd 8y ago
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.
- PantsyWantsy 7y ago
  Hi, Read my first comment at the top. I'm the owner, creator and maintainer of the ghacks user.js --- I understand it's not very usable for most people out of the box - but it's not aimed at most people. I have never gone out of my way to promote this AT ALL (this is my first time posting here, I also do not post anywhere else: I simply have just let word of mouth and the quality of work/reputation do it's thing) - those who find it are usually knowledgeable enough to handle the gist of it (no pun intended). It's a niche product, but it IS a TEMPLATE. No one size fits all. It's a fairly hardened setup (it could be a LOT harder, trust me) and every decision has solid research and considerations behind it. I've gone out of my way to make it as responsible as possible, while still adhering to the users. And I've tried to make it as easy as possible, with setup tags, a wiki and more. Always happy to hear things that can help make it better (more on that in another reply), and I've always been mindful of breakage and inconvenience - but it cannot be avoided if you want to "harden" things. The internet was never designed for privacy, anonymity or security. Everything has a trade-off. A little background, I'm basically retired, and have spent the last 8 years doing this as my "hobby". But to be honest, I actually spend more than a full-time job on it. It's like being a full time Ph.D student, 365 days a year. All free and voluntary. It's my passion. I'm not sure how much I want to share here, but lets just say that you are benefiting from my input at the Tor Project (a little, especially upcoming changes), and Firefox (quite a fking lot: RFP in particular). Do I know everything? Hell no, no-one can. That's why I have contacts, that's why I research everything to the nth degree, and validate it. And of course, I am always happy to be corrected (because no-one is right all the time). I share this little background, not trying to sound all important (I'm not), but because of some comments further down. Of course, I could be lying - that's up to you to decide, not me. HTTP2 I will address below, but websockets aren't disabled. The preference for that network.websocket.enabled was removed in FF35, There is a websocket pref for HTTP2 which is not needed but included for practical reasons. The master pref for HTTP2 alone would disable http2 websocket. Perhaps this is what you are referring to. I agree with you that changes to FF's behavior absolutely can make you stand out. Fingerprinting is the one area that I would consider myself VERY (extremely) knowledgeable in. Server side entropy such as HTTP2 is still entropy, and the effectiveness of that depends on how widespread end-user uptake is. I'll expand this to include AltSvc and IPv6. Also note that the uptake is always changing (HTTP2 use is massively up from a couple of years ago), and we are always happy to revisit, and we do. Such as keeping an eye on what Tor Browser do (they too had HTTP2, AltSvc, and SSL Session IDs disabled until the last release, i.e TB8. - they do that for a reason you know). We (I say we, because I do make most decisions after talking with a few other people) don't just turn things off because we don't understand them - there are always solid reasons (and considerations). I have always said IPv6 should be handled at an OS level, and we only flipped that pref to active about 6 months ago for several reasons. Worldwide, IPv6 is not enabled at an ISP level at the levels you may think they are (even I was surprised). It's hard to get actual stats. I'm in a rich, western, almost want for nothing country, and none of our ISPs have it (telco's may be different story, and the js is aimed at the desktop, especially once Fennex is released). The setting doesn't break any web pages or connections, but does provide POSSIBLE protection (in case a VPN drops: and not all VPNs are equal, there are a lot of shit ones that don't even cover this), and then there is of course the documented issue of how IPv6 can be a privacy nightmare (why do you think top VPNs make a point of this). At worst, IF (and that's a big IF) this was used to facilitate fingerprinting, then at my best guess, I would say it's 50/50. There's also an assumption here that you're using masking your IP, otherwise you're already giving away much more commonly used tracking data. So VPN users, this setting does not hurt, it actually helps. Non VPN users, the setting might make them stand out more (e.g the only user in the IP range with no IPv6), but the threat model is not there. Fingerprinting and tracking companies have far more lucrative and easier ways to do what they desire. And of course, we say in the readme at github, and the readme in the user.js, that users should consider using Tor Browser first. HTTP2 is also not that widespread. It's around 50/50 of the web now. But every modern web browser supports it. So anyone falling back to HTTP1.1 on an HTTP2 website would stick out, a lot. We do disable this, and it's contentious, but there are privacy issues with it. There's even a study and proof of concept, that shows it leaks entropy/data: sorry for being so vague, but I don't have the information super handy right now. Disabling it does not break anything - no harm, no foul..But it really is a 50/50 call on enabling or disabling it. The threat probably just really isn't there for most people. The PoC etc is not entirely convincing. And I seriously doubt anyone is bothering to use it (to track etc - easy and cheaper ways to do that, etc). We followed Tor Browser's lead on this, and have debated it to death yet again (and unearthed more info, including the "PoC"). In the end the consensus was, no breakage, so lets leave it disabled for now. Just to clarify something before I continue, the user.js is only concerned with issues that can improve privacy, security, anonymity, anti-tracking, anti-fingerprinting - but does try to balance the trade-off with usability and functionality. Speed is not considered. So yes, HTTP2 does speed things up, more than likely imperceptibly, but isn't really a factor. Don't get me wrong, if a pref caused things to be really bogged down, janked, etc, then that would be a usability issue. AltSvc also gets a lot of flack (usually lumped in with HTTP2). I'll just leave you to read the actual link provided in the user.js. It has serious privacy and security issues. If this threat doesn't apply to you, then comment it out. It's that simple. It's a template Thanks for putting up with my long ass reply, and thanks for the criticisms (I do listen, and learn). More replies below to follow.
acdha 8y ago
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 7y ago
  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.

110 points by dcassett 8y ago

Firefox 67 beta exposes some of these settings (like blocking cryptominers and fingerprinters) in the UI: https://blog.mozilla.org/futurereleases/2019/04/09/protections-against-fingerprinting-and-cryptocurrency-mining-available-in-firefox-nightly-and-beta/ https://blog.mozilla.org/futurereleases/2019/04/09/protectio...

PantsyWantsy 7y ago
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.

fulafel 8y ago

Does it work on mobile?

jeroenhd 8y ago
With some effort, yes: https://github.com/ghacksuserjs/ghacks-user.js/wiki/1.6-Firefox-Android https://github.com/ghacksuserjs/ghacks-user.js/wiki/1.6-Fire... 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.

jeroenhd 8y ago

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.

PantsyWantsy 7y ago
Hi, Read my first comment at the top. I'm the owner, creator and maintainer of the ghacks user.js --- I understand it's not very usable for most people out of the box - but it's not aimed at most people. I have never gone out of my way to promote this AT ALL (this is my first time posting here, I also do not post anywhere else: I simply have just let word of mouth and the quality of work/reputation do it's thing) - those who find it are usually knowledgeable enough to handle the gist of it (no pun intended). It's a niche product, but it IS a TEMPLATE. No one size fits all. It's a fairly hardened setup (it could be a LOT harder, trust me) and every decision has solid research and considerations behind it. I've gone out of my way to make it as responsible as possible, while still adhering to the users. And I've tried to make it as easy as possible, with setup tags, a wiki and more. Always happy to hear things that can help make it better (more on that in another reply), and I've always been mindful of breakage and inconvenience - but it cannot be avoided if you want to "harden" things. The internet was never designed for privacy, anonymity or security. Everything has a trade-off. A little background, I'm basically retired, and have spent the last 8 years doing this as my "hobby". But to be honest, I actually spend more than a full-time job on it. It's like being a full time Ph.D student, 365 days a year. All free and voluntary. It's my passion. I'm not sure how much I want to share here, but lets just say that you are benefiting from my input at the Tor Project (a little, especially upcoming changes), and Firefox (quite a fking lot: RFP in particular). Do I know everything? Hell no, no-one can. That's why I have contacts, that's why I research everything to the nth degree, and validate it. And of course, I am always happy to be corrected (because no-one is right all the time). I share this little background, not trying to sound all important (I'm not), but because of some comments further down. Of course, I could be lying - that's up to you to decide, not me. HTTP2 I will address below, but websockets aren't disabled. The preference for that network.websocket.enabled was removed in FF35, There is a websocket pref for HTTP2 which is not needed but included for practical reasons. The master pref for HTTP2 alone would disable http2 websocket. Perhaps this is what you are referring to. I agree with you that changes to FF's behavior absolutely can make you stand out. Fingerprinting is the one area that I would consider myself VERY (extremely) knowledgeable in. Server side entropy such as HTTP2 is still entropy, and the effectiveness of that depends on how widespread end-user uptake is. I'll expand this to include AltSvc and IPv6. Also note that the uptake is always changing (HTTP2 use is massively up from a couple of years ago), and we are always happy to revisit, and we do. Such as keeping an eye on what Tor Browser do (they too had HTTP2, AltSvc, and SSL Session IDs disabled until the last release, i.e TB8. - they do that for a reason you know). We (I say we, because I do make most decisions after talking with a few other people) don't just turn things off because we don't understand them - there are always solid reasons (and considerations). I have always said IPv6 should be handled at an OS level, and we only flipped that pref to active about 6 months ago for several reasons. Worldwide, IPv6 is not enabled at an ISP level at the levels you may think they are (even I was surprised). It's hard to get actual stats. I'm in a rich, western, almost want for nothing country, and none of our ISPs have it (telco's may be different story, and the js is aimed at the desktop, especially once Fennex is released). The setting doesn't break any web pages or connections, but does provide POSSIBLE protection (in case a VPN drops: and not all VPNs are equal, there are a lot of shit ones that don't even cover this), and then there is of course the documented issue of how IPv6 can be a privacy nightmare (why do you think top VPNs make a point of this). At worst, IF (and that's a big IF) this was used to facilitate fingerprinting, then at my best guess, I would say it's 50/50. There's also an assumption here that you're using masking your IP, otherwise you're already giving away much more commonly used tracking data. So VPN users, this setting does not hurt, it actually helps. Non VPN users, the setting might make them stand out more (e.g the only user in the IP range with no IPv6), but the threat model is not there. Fingerprinting and tracking companies have far more lucrative and easier ways to do what they desire. And of course, we say in the readme at github, and the readme in the user.js, that users should consider using Tor Browser first. HTTP2 is also not that widespread. It's around 50/50 of the web now. But every modern web browser supports it. So anyone falling back to HTTP1.1 on an HTTP2 website would stick out, a lot. We do disable this, and it's contentious, but there are privacy issues with it. There's even a study and proof of concept, that shows it leaks entropy/data: sorry for being so vague, but I don't have the information super handy right now. Disabling it does not break anything - no harm, no foul..But it really is a 50/50 call on enabling or disabling it. The threat probably just really isn't there for most people. The PoC etc is not entirely convincing. And I seriously doubt anyone is bothering to use it (to track etc - easy and cheaper ways to do that, etc). We followed Tor Browser's lead on this, and have debated it to death yet again (and unearthed more info, including the "PoC"). In the end the consensus was, no breakage, so lets leave it disabled for now. Just to clarify something before I continue, the user.js is only concerned with issues that can improve privacy, security, anonymity, anti-tracking, anti-fingerprinting - but does try to balance the trade-off with usability and functionality. Speed is not considered. So yes, HTTP2 does speed things up, more than likely imperceptibly, but isn't really a factor. Don't get me wrong, if a pref caused things to be really bogged down, janked, etc, then that would be a usability issue. AltSvc also gets a lot of flack (usually lumped in with HTTP2). I'll just leave you to read the actual link provided in the user.js. It has serious privacy and security issues. If this threat doesn't apply to you, then comment it out. It's that simple. It's a template Thanks for putting up with my long ass reply, and thanks for the criticisms (I do listen, and learn). More replies below to follow.

acdha 8y ago

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 7y ago
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.