Remove 'Website Privacy Preferences' and ensure sensible default prefs

I'd like to enable Global Privacy Control by default in Mullvad Browser.

Since it's just a pref, it doesn't matter if it's always on or always off, as long as it's consistent. This pref could be locked as well.

This has been added to Firefox 120.

cc @thorin

changed the description

1848951 [meta] Support Global Privacy Control

It will happen automagically in 14 as it is default enabled in PB mode since FF120

You could consider making it also on in normal windows in prep for persistent mode

• privacy.globalprivacycontrol.enabled = true (default false)

You can't enable it in ESR115 as the code isn't there or at least not production ready - IIUIC

Ah nice that we get it for free in PBM.

Should we lock the pref and/or even maybe hide it in the settings?

privacy.globalprivacycontrol.functionality.enabled = the API (no UI for this) default true

privacy.globalprivacycontrol.pbmode.enabled default true (no UI for this)

privacy.globalprivacycontrol.enabled (default false) = the UI setting and affects all modes (e.g if pbmode was disabled)

We should nix that UI section IMO, but I don't think we should be locking prefs (we should make about:config scary with a sticky interstitial)

cc @pierov easy peasy for ESR128

@morgan since we want the same in base browser, should/can we move this to tpa/tor-browser (IDK how)

wfm

If we do want to hide the preferences, we should maybe one-off reset the preference values for privacy.globalprivacycontrol.enabled and privacy.donottrackheader.enabled. These technically existed in ESR 115, so we would be hiding the means for a user to return to our default.

DNT was already hidden in MB, so it'd be resetting something set in about:config, which normally we don't.

They only matter if we move to a persistent mode. In FF both are enforced in PB Mode. But in TB DNT is not enabled in PB Mode since we do not use ETP (I think this is the cause now, but I also think in the past it was with a patch - we should check that, and by we I mean Pier).

Personally I think we should lock anything we want in stable, as long as the UI is taken care of first - and we still need to make about config warning interstitial sticky and scary

There are two do not track boxes: legacyDoNotTrackBox and doNotTrackBox. They are toggled with privacy.globalprivacycontrol.functionality.enabled.

But I don't think they are gated by ETP first.

So the work here is to disable is to always disable these checkboxes?

added FF128-esr label

added UX label

added All Platforms label

added 14.0 stable Roadmap::Future labels

changed title from Enable Global Privacy Control by default to Remove 'Website Privacy Preferences' and ensure sensible default prefs

added Task label

mentioned in issue #42772 (closed)

moved from mullvad-browser#315 (moved)

marked this issue as related to #42752 (closed)

This pref could be locked as well.

Why?

I think removing the UI would be enough. Locks should be reserved to preferences that are real footguns (this one doesn't seem to be: toggling the default will be fingerprintable, but I guess the default shouldn't be a big deal to anyone).

We still have some time before 14.0a1 gets built, I think we could do it immediately, not to think about migrations (theoretically, when we hide UI elements we should also migrate to the new default).

I'm happy to just hide it.

I guess I said this because if users don't gain anything from switching a pref (and in this case will actually make them more fingerprintable), then we might as well lock it, but it's a weak opinion not grounded on any maintenance reality or existing policy.

mentioned in issue #42772 (closed)

marked this issue as related to #42772 (closed)

removed Roadmap::Future label

added Desktop Next labels

removed All Platforms label

assigned to @henry

Set privacy.globalprivacycontrol.enabled and privacy.donottrackheader.enabled to false and hide the UX which modifies them please :)

privacy.globalprivacycontrol.enabled (which is the normal window control since we use privacy.globalprivacycontrol.pbmode.enabled = true) is already false

privacy.donottrackheader.enabled is also already false (it's only enabled in ETP Strict by default) but I guess defense in depth, although TBH it's not an issue if it did change and everyone is still the same (besides the fact it's a useless header)?

In that case, just hide the UX please @henry

mentioned in merge request !1184 (merged)

removed Next label

added Doing label

marked this issue as related to tor-browser-build#41225 (closed)

marked this issue as related to tor-browser-build#41226 (closed)

closed

Re-opening this. I realised that we need to make sure that privacy.globalprivacycontrol.enabled and privacy.globalprivacycontrol.pbmode.enabled have the same value. Otherwise non-private windows are fingerprintable using the request headers.

I would vote for setting privacy.globalprivacycontrol.enabled to true to keep it the same as the private browsing (majority) default.

@morgan and @pierov what do you think?

non PB mode is not supported. non PB mode is already fingerprintable without this distinction (albeit this is passive) .. that said, and I will quote myself

You could consider making it also on in normal windows in prep for persistent mode

• privacy.globalprivacycontrol.enabled = true (default false)

edit: just to clarify .. we should do this for FPing as well, as one day we will be able to blur the lines between PB vs all mode

also, we should try and be consistent moving forward with all these *pbmode prefs - where normally the non pbmode pref means all windows and overrides the pbmode setting

So I did a quick check in windows. RFP overrides pbmode, so we're good. All the rest except GPC are also fine (assuming ETP strict doesn't do something, but we don't use that)

so yup: make privacy.globalprivacycontrol.enabled = true

mismatch

• privacy.globalprivacycontrol.pbmode.enabled true
  • privacy.globalprivacycontrol.enabled false
• privacy.resistFingerprinting.pbmode false
  • privacy.resistFingerprinting true

mismatch (but we don't use them in TB)

• network.http.referer.disallowCrossSiteRelaxingDefault.pbmode.top_navigation true
  • network.http.referer.disallowCrossSiteRelaxingDefault.top_navigation false
• privacy.annotate_channels.strict_list.pbmode.enabled true
  • privacy.annotate_channels.strict_list.enabled false
• privacy.fingerprintingProtection.pbmode true
  • privacy.fingerprintingProtection false

non-pbmode matches pbmode

• network.cookie.cookieBehavior.optInPartitioning.pbmode false
• network.cookie.cookieBehavior.pbmode 1
• network.http.referer.defaultPolicy.pbmode 2
• network.http.referer.defaultPolicy.trackers.pbmode 2
• network.http.referer.disallowCrossSiteRelaxingDefault.pbmode true
• privacy.partition.network_state.ocsp_cache.pbmode true
• privacy.query_stripping.enabled.pbmode true
• privacy.trackingprotection.emailtracking.pbmode.enabled false
• privacy.trackingprotection.pbmode.enabled false
• security.insecure_connection_text.pbmode.enabled false

Yes, please, let's set this also for non-PBM.

Thank you!

reopened

added Fingerprinting label

mentioned in merge request !1205 (merged)

mentioned in issue #43144 (closed)

closed

mentioned in issue #42054 (closed)