search

privacytools / privacytools.io

🛡🛠 You are being watched. Protect your privacy against global mass surveillance.
https://www.privacyguides.org
Creative Commons Zero v1.0 Universal
3.12k stars 386 forks source link

cleanup of the about:config section #1212

Closed nitrohorse closed 5 years ago

nitrohorse commented 5 years ago

Description

Currently we have a section dedicated to Firefox about:config adjustments: https://www.privacytools.io/browsers/#about_config

We also list at the bottom of that section links to user.js templates that go above and beyond this list of our own. I've also noticed that our list can give the impression to users that Firefox isn't "secure" or "private" by default without these tweaks which isn't necessarily true for the majority of users (from my perspective).

My suggestion is to potentially remove our list and rely on the linked user.js template repositories for about:config adjustments which are appear to be maintained actively.

However, we may want to think about moving the network.trr adjustments to the DNS section or simply link to the rules under network.trr there.

Mikaela commented 5 years ago

Firefox: Privacy Related "about:config" Tweaks This is a collection of privacy-related about:config tweaks. We'll show you how to enhance the privacy of your Firefox browser.

I think we might want to change this notice to say something about Firefox being OK by default and that for anonymity you should use Tor Browser and these settings are just for geeks(?) or people who are midlly concerned on their privacy, but not enough to use Tor Browser.

privacy.firstparty.isolate = true

I like

privacy.resistFingerprinting = true A result of the Tor Uplift effort, this preference makes Firefox more resistant to browser fingerprinting.

I think this should explain more and say that it has side effects like breaking audio captcha with Google and getting more captchas (link) etc., possibly also affecting TTS and changing everything to English.

browser.cache.offline.enable = false Disables offline cache.

What for?

dom.event.clipboardevents.enabled = false Disable that websites can get notifications if you copy, paste, or cut something from a web page, and it lets them know which part of the page had been selected.

I ignore this, because it breaks etherpad and NextCloud etc. without even thinking about Google Docs.

geo.enabled = false Disables geolocation.

That many not-so-privacy-concious users including me do use for legitimate purpouses like weather information or local store opening hours (even if I use Mozilla Location Services and it puts me to wrong neighbourhood)

media.eme.enabled = false Disables playback of DRM-controlled HTML5 content, which, if enabled, automatically downloads the Widevine Content Decryption Module provided by Google Inc. Details DRM-controlled content that requires the Adobe Flash or Microsoft Silverlight NPAPI plugins will still play, if installed and enabled in Firefox. media.gmp-widevinecdm.enabled = false Disables the Widevine Content Decryption Module provided by Google Inc., used for the playback of DRM-controlled HTML5 content. Details

and break Netflix etc.?

media.navigator.enabled = false Websites can track the microphone and camera status of your device.

Does this break WebRTC based tools?

network.cookie.cookieBehavior = 1

Isn't this reduntant and something to configure in the normal settings?

network.cookie.lifetimePolicy = 2

so Facebook requires logging in every time

network.http.referer.trimmingPolicy = 2

I think this breaks things

webgl.disabled = true WebGL is a potential security risk. Source

I don't know about that, but aren't we more focused on privacy?

extensions.pocket.enabled = false

I like, while not related to privacy that much, I guess

network.IDN_show_punycode = true

nice to know, but not privacy related

We have so much of those tweaks that I think it would be easier to comment on everything by just having X PRs and comparing them.

Thorin-Oakenpants commented 5 years ago

[RFP] and changing everything to English

It doesn't. It prompts

[RFP] possibly also affecting TTS

text-to-speech?

geo.enabled = false

Once again.. this is a useless setting. Geo is already behind a prompt. Even RFP does not fiddle with this. Firefox is not Tor Browser., and TB sets this as a defense in depth because it's very risky given their user-base (whistle blowers, etc) - i.e they need to look out for all threat models

ProgressiveArchitect commented 5 years ago

The about:config tweaks section is important. Many users I talk to from all over find it to be an extremely helpful resource, both in understanding the options they have for hardening but also enabling them to learn what some of the browser side points of compromise are.

I highly recommend that the service admin leave this section in place and continue adding privacy tweaks as they become available, as well as removing old ones that become redundant or no longer available via the about:config interface.

Mikaela commented 5 years ago

[RFP] possibly also affecting TTS

text-to-speech?

Yes, however this may have been user error. I am using https://clozemaster.com/ and it was complaining about my browser not supporting TTS for Czech, but after disabling privacy.resistfingerprinting I noticed that I only had the English language pack installed so installing it may have fixed it regardless of RFP, but I never restored RFP.

RFP breaks Google's Audio Captcha, so I wouldn't close it affecting TTS out, or maybe it's tied to language preferences and having everything in English hides the CZ capability?

geo.enabled = false

Once again.. this is a useless setting.

Thanks (again), I will PR it away now, so it will hopefully stop haunting us.

Thorin-Oakenpants commented 5 years ago

Re TTS: https://bugzilla.mozilla.org/show_bug.cgi?id=1333641 - RFP disables it

Edit: Some history on geo & RFP. The third bug first comment explains why geo is not necessary better than I could

blacklight447 commented 5 years ago

I also do not feel comfortable removing this, I vote for slapping an "advanced user tweaks" label on it and removing redundant/outdated options.

Thorin-Oakenpants commented 5 years ago

Did you mean uncomfortable with removing the geo.enabled pref? There's nothing advanced about it: the consequences of disabling it are the same for everyone and it does not offer any extra protection.

The default of geo enabled, and permission prompt is more than sufficient for most people. Fiddling with it just makes you stand out: not only is the geo API fingerprintable (enabled, disabled), but so is the default permission setting for it (deny, prompt, allow) - see TZP at the bottom of the language/locale section

PS: The prefs are shown in the [i] tooltips

Mikaela commented 5 years ago

I think they meant the about:config section in general.

I am going to PR moving TRR to the DNS page soonish.

blacklight447 commented 5 years ago

@Mikaela I indeed meant the about config section.

Mikaela commented 5 years ago

Good bye geo.enabled

Mikaela commented 5 years ago

First mentioned at https://github.com/privacytoolsIO/privacytools.io/issues/339#issuecomment-526275495, now at Reddit,

Hi Team, Any chance that you could add beacon.enable = false to the list. REASON: Sends data to Servers when leaving pages.

blacklight447 commented 5 years ago

I renamed the issue to be more up to date. @thorin-oakenpants , are you still interested in helping us clean up the about:config section?

Thorin-Oakenpants commented 5 years ago

absolutely: I was going to type something up and take over one of the firefox issues: I might do it tomorrow, or in a week. hang ten!

blacklight447 commented 5 years ago

Excellent, I look forward collaborating together. :)

Thorin-Oakenpants commented 5 years ago

The goal here is to provide a small list of the most impactful settings for end-users. Small, short and sweet (including short descriptions and removal of immaterial info). This makes it easy, less intimidating, and users can then move onto looking at a more definitive source

step1: clean out the rubbish step2: add some missing gems (e.g beacon) step3: clean up / fix descriptions (shorter, less jargon etc if needed: remove immaterial things like default in FF4). Also clean up and/or improve sources (e.g use EFFs link about DRM). Re-evaluate recommended settings (e.g referrers are way too much breakage: I doubt anyone keeps them like that) step4: re-organize into sections based primarily on breakage

This is just about step 1; I'll add a checklist here for you guys to tick off, and then move onto step 2: feel free to add a comment as an edit. Either you can clean them out in a separate commit, or just confirm they are good for me to remove in my re-write of the section. Once agreed upon, I'll move onto step2. Here's the first batch (I might convince you to remove others)

🚑 Step 1: items to remove

🔻 browser.cache.offline.enable

This is appCache, which has been on the deprecation gravy train for four years. Mozilla telemetry last time I checked, from memory aww shit .. let me look that up.... go here and change selected item (it's underlined) in the distribution: in the pic below this is GC_MS telemetry

Here is a very recent (August 22nd) update on the intent to unship appCache: https://groups.google.com/forum/#!msg/mozilla.dev.platform/5JqnS_PnKqU/87hJ99JpDgAJ ... here is the gist of it

In Firefox 70, Remove the previous preference browser.cache.offline.insecure.enable and related code, forcing all of the APIs to only ever be available over Secure Contexts despite user choice. Due to the insecure nature of insecure context AppCache it is a good time now to remove this fully.

Create a new preference that disables only the storage and use of AppCache data whilst permitting access to the dom property window.applicationCache and the “OfflineResourceList” interface

Disable access in Nighty and beta for 70 for two releases before disabling for all other releases in 72.

Once storage is disabled in all releases: Disable the API access in Nightly and beta via the existing preference (browser.cache.offline.enable) in version 72

Wait two releases and then disable in all releases in Firefox 74

Summary: appCache is practically dead in the wild, and the pref will soon be deprecated. There is no need to have this pref for end users cluttering up the good stuff

🔻 dom.battery.enabled

This has been limited to privileged content only since FF52. web content cannot access this API. For the last time: get rid of it. I'm all about sources .. so here

🔻 extensions.blocklist.url

two parts to this

  1. remove the suggestion to "optionally disable it completely". This is not something that should be suggested at this level or point - leave it to a more detailed source (remember, I'm trying to make this short and most impactful - and there would a link to the ghacks user.js for those interested in more options). The blocklist is used for cert revocations: so this is a direct removal of a security feature.
  2. Sanitizing the pref itself has a super negligible (if any) benefit. It only impacts one item (updating of blocklists) - it's not worthy of being on the list. And you're only providing some normal info to one entity - i.e Mozilla, who make the damn application. I'm not an expert of the variables sent, but I bet its only used on their backend for technical reasons. There's no PII here. This is not a privacy issue. If you don't trust Mozilla by now, then you shouldn't be using Firefox (I'm not saying they shouldn't be held accountable, or scrutinized etc) but can we stop the over-zealous rubbish creeping in.

🔻 safe browsing

There are zero privacy issues here. I don't want to go over all of this again.. so some quick bullet points

Please advise.

blacklight447 commented 5 years ago

I must say you make a good case for the removal of these prefs. The sources also back up the claims. I am okay with their removal. Thanks for helping out, ill soon create a PR to get started with this.

Edit: PR created: #1262

Thorin-Oakenpants commented 5 years ago

also remove

🔻 network.http.referer.trimmingPolicy

0=send full URI (default), 1=scheme+host+port+path, 2=scheme+host+port

This is redundant, confusing for end-users, and is a global setting. You only need to worry about cross-origin referers, which are already covered in:

🔻 network.cookie.lifetimePolicy

Cookies and persistent local web data can get complicated. And I don't want to get all technical here (and even I'm not 100% knowledgeable on it, and it keeps changing). Cookies control more than just cookies: they also control access to sessionStorage, localStorage, IDB, sharedWorker, and serviceWorker. There are other better and cleaner ways to control "cookies" (which we can add in step 2)

Currently you have:

   0 = Accept cookies normally
   1 = Prompt for each cookie
   2 = Accept for current session only
   3 = Accept for N days

However, option 1 does not exist (not sure when it was removed: a long time ago), and option 3 was removed in FF63+ (I'll see if I can find the bugzilla for you: edit here it is). Additionally if you use option 2, this means the cookie is session only which blocks shared workers and service workers = site breakage.

The pref is now very limited, the only option (edit: from default) is one which breaks things, many other alternatives exist for controlling persistent web data. I wouldn't be surprised if this pref got made redundant soon.

Examples of other better methods

I have more prefs I would like to see removed.. will write them up when I get time

Thorin-Oakenpants commented 5 years ago

🔻 extensions.pocket.enabled

This was recently added in #784 - but it has nothing to do with privacy (out of the box).

The service: By default, it is an opt-in service. When a web page is loaded, there is a "save to pocket" icon at the far right of the urlbar, clicking on it displays an info panel saying sign up to use the feature. Unless you sign-up and start using it, nothing happens. On Firefox's home page (called Activity Stream), the highlights section has an option to display "pages saved to pocket". If you don't use Pocket, there is no problem.

pocket

The pref (99% sure) only applies to the service, not the next part about Activity Stream. It's a bit hard to test, since I have to wait in a new profile to see if pocket lists are downloaded. I don't really want to waste my time proving it - but if you want me to, then I will.

Edit go here and look at where the pref is called: it is not used for Activity Stream suggestions/sponsored stories, which makes all the stuff I wrote below immaterial anyway end edit

Activity Stream: There is also a "recommended by pocket" option. These suggestions and sponsored story links are calculated locally from general lists all users download. I've read about this on a technical level before several times (and all the Firefox code is open source), but the only thing I can quickly find is this

Emphasis mine

Importantly, neither Mozilla nor Pocket ever receives a copy of your browser history. When personalization does occur, recommendations rely on a process of story sorting and filtering that happens locally in your personal copy of Firefox.

By default, when recommendations from Pocket are displayed on your new tab, we collect information about how many times they appear and how many times they are clicked. However, this information is not associated with any of the technical and interaction information about you or your copy of Firefox.

There are no privacy concerns with the service as a default, you need to create an account. Users can already hide the icon (or ignore it). And AS already has a UI for tweaking what to show, which also doesn't actually have any privacy issues IMO, certainly not PII.

Thorin-Oakenpants commented 5 years ago

I have one more item to suggest removing, but it's a bit of a labyrinth to test: so give me a few days. After that, I suggest we push the commit to clean out the garbage, so I can start fresh (and not surprise end-users with too many changes all at once: i.e current-> end product)

Thorin-Oakenpants commented 5 years ago

@blacklight447-ptio -> https://github.com/privacytoolsIO/privacytools.io/pull/1262

Did you mean to remove the closing d1 tag?

blacklight447 commented 5 years ago

I have one more item to suggest removing, but it's a bit of a labyrinth to test: so give me a few days. After that, I suggest we push the commit to clean out the garbage, so I can start fresh (and not surprise end-users with too many changes all at once: i.e current-> end product)

I would be fine with this, the first PR could be used to clean up the mess, the second for adding new prefs.

@blacklight447-ptio -> #1262

Did you mean to remove the closing d1 tag?

Care to elaborate?

Thorin-Oakenpants commented 5 years ago

When I look at the file changes I see the very last line removed a closing </d1>, but I do not see a corresponding opening <d1> also being removed. So I thought I would point that out just in case :)

blacklight447 commented 5 years ago

@thorin-oakenpants any updates on the last pref that needs to be removed?

Thorin-Oakenpants commented 5 years ago

Haven't forgotten. Did a load of testing, all documented, etc: but got a contradictory result somewhere: and then have been busy the last 3 or 4 days. Sorry. I'll get something for you as soon as I can.

Once we decide on that last pref (for removal), then I guess we can open a new issue for steps 2, 3, 4: which I will simply do as a single draft: i.e add in new items, categorize them, clean up descriptions, intro, etc: all in one hit.

Thorin-Oakenpants commented 5 years ago

🔻 settle in for a while

Here's the summary: beer 🍺 with me, this could get slightly long winded. I will refer to this as RCT (recently closed tabs) and RCW (recently closed windows)

Session Restore (SR) recovery files are used in normal windows for recovery after a crash. They have to hold current tabs by default: you can't disable that. The extra recovery data is made up of RCT and RCW (there is also persistent storage of history in places.sqlite: but here we are only talking about session restore).

The SR recovery files are in profile\sessionstore-backups\ and are called recovery.jsonlz4 (live: every x seconds per a pref) and recovery.baklz4 (a backup). It's a pain in the ass to view them (they used to be json files): I used mozlz4-edit

There is only one no configuration where using this pref makes some any sense: but three configs that it affects: AFAIK. And it looks like one config might have just been patched in Nightly (what are the odds!)

🔻 configurations

PB mode does not touch the disk: there are no recovery files. Normal mode there are: if session resuming is enabled, these files are persistent. Otherwise they are not: they are destroyed on firefox closing.

So in these three configs, you would expect history to not be recorded in SR's recovery files, or displayed in the library history. But they partially are. In Config A (PB mode), RCTabs are displayed in the library and kept in memory. In normal mode, all current tabs and RCTabs are always written to recovery, current tabs are not displayed in the library but RCTabs are. RCW seem to do the right thing but I didn't test them that much.

This is where the pref comes in. It is the max number of RCTabs to keep in the recovery file (and display in the library). A sort of "whoops, didn't mean to close that: MRU short list". The default is 25 items.

It seems inconsistent that when you say don't remember history, or never remember history: that the SR does more than the current tabs. This is probably by design. And I'm not 100% sure that just because something is not visible in the library: it doesn't mean it wasn't written to the recovery file. And it's always changing: I saw changes in Nightly today that seems to fix config B.

Anyway: back to the configs. A and B are session only. A is the same as Tor Browser (pb mode), they have the same result. During a session, this is not a big deal: especially with disk avoidance. The risk is that a still-open app can reveal previous site visits. With disk writes, the risk is the same, but also that an app crash doesn't wipe the recovery files until next start. And with C, the risk is that the user doesn't want the recovery files wiped after each session.

All these risks come down to end user responsibility to ensure their own device security. Don't leave it unguarded, encrypt it, close apps, don't allow should surfers etc. At this level of pref flipping, the user should just be using Tor on Tails or something.

tl;dr

Personally, I would drop this. I have 220+ prefs for you guys. If I was picking 20 for max impact (and keeping an eye on breakage), it would woundn't be this one. I can do better.

Remember: the re-write will say something along the lines of here are some good prefs to start with" and end with "for more about:config options, check out ghacks user.js, but don't just blindly apply something: read about it first, and then decide (or test) if that pref works for you"

This is about the 20th re-write of this, and I left lots out. Hope it makes sense to you guys

blacklight447 commented 5 years ago

I agree with removing it, if we cannot make a good case for including it on the site, then it shouldn't be there at all.

After all, the about config section is only meant as a brief list of impact full preferences to give Firefox the small boost in privacy and security it can use, not become a gaint catalogue of prefs to completely lock it down. For that, people could indeed use ghacks.

Thorin-Oakenpants commented 5 years ago

FWIW, ghacks user/js has this pref as FYI: it's not even active

Thorin-Oakenpants commented 5 years ago

Anyway: it's good we have a direct line of contact now: use it if you feel the need.

Go ahead and make that change (or not). I will open a new ticket: cleanup of about:config: part 2 with my draft next (or start one for me so you can track it). I have learnt my lesson and won't give a timeline :)