GPO wishlist: Fingerprinting

[arlt]

Please implement the following GPO settings:

lockPref("beacon.enabled", false);
lockPref("browser.send_pings", false);
lockPref("browser.search.geoip.timeout", 1);
lockPref("browser.search.geoip.url", "");
lockPref("device.sensors.enabled", false);
lockPref("dom.battery.enabled", false);
lockPref("dom.enable_performance", false);
lockPref("dom.enable_resource_timing", false);
lockPref("dom.enable_user_timing", false); // exists?
lockPref("dom.event.clipboardevents.enabled", false);
lockPref("dom.network.enabled", false);
lockPref("dom.min_timeout_value", 400);
lockPref("geo.enabled", false);
lockPref("geo.wifi.logging.enabled", false); // exists?
lockPref("geo.wifi.uri", "");
lockPref("media.video_stats.enabled", false);

(I am not sure if all these settings affect something with the newest ESR, but hopefully you can enlighten me :-).)

[mkaply]

We have a preferences that resists fingerprinting. I'll check into how many of these it affects.

We are looking into turning off geo completely. You shouldn't then need to set the other prefs since it is disabled.

I'm unclear as to why you would change timeout values?

Resist fingerprinting definitely turns off media.video_stats.enabled.

I think of lot of these options are changed via the fingerprinting pref and a lot are unnecessary.

[arlt]

All settings where collected over several years so maybe some are unnecessary over the years and some maybe not wise. I did not try to get to the bottom of all settings and recommendations.

The dom.min_timeout_values is from https://www.privacy-handbuch.de/handbuch_21n.htm

In addition, minimum values for timers can be increased to prevent high-precision time measurement for side channel handles

[jjurkus]

I previously set beacon.enabled to false. Years ago. I still don't know what it is for.

browser.send_pings? Never even heard of it :-(
Just like most of these settings. I really hope these policy templates will bring more clarity in what does what.

[Thorin-Oakenpants]

I'll check into how many of these it affects.

I've been following RFP closely for a long long time: arkenfox/user.js#7 is a handy list of everything RFP touches. Note: not all RFP patches are the same - their approach may differ (eg instead of disabling an API/feature as per a pref, instead they limit or spoof the returned values) etc. From the above list:

🔻 not needed / ignore

• dom.network.enabled was deprecated in FF31 1091016
  • it was replaced with dom.netinfo.enabled which I will include below since RFP touches on this
• dom.battery.enabled since FF52 this is limited to chrome/privileged code 1313580
• dom.enable_user_timing was deprecated in FF55 1352949
• geo.wifi.logging.enabled is a hidden pref (since you asked if it exists), the default is false so there is no need to enforce this
• geo.wifi.uri there is no need to blank this, as it is covered by the master pref geo.enabled
• browser.search.geoip.timeout is not needed if you have browser.search.geoip.url=blank

🔻 do not use if you have RFP=true

You can compromise RFP - i.e your fingerprint would differ. See this issue for a look at some of the earlier RFP items and how they can be affected by and/or differ from other prefs. Below I am just looking at the individual effects, not when you combine them. Each RFP patch would need to be looked at individually to determine which wins over the other (but disabling the API usually wins over RFP).

• dom.enable_performance & dom.enable_resource_timing - RFP sometimes spoofs. This is not the same as flat out disabling APIs in two prefs above
  • for example: dom.enable_performance=false disables the API, but RFP would return a value of zero
• media.video_stats.enabled - RFP spoofs the stats, the pref disables the stats entirely
• dom.netinfo.enabled - RFP spoofs the network info as unknown, the pref instead returns undefined

🔻 doesn't matter (same effect)

• device.sensors.enabled - RFP blocks the events, the pref disables the API
• geo.enabled - currently RFP blocks geo (same as if you deny a site permission). They plan to remove this 1441295 since it is behind a prompt.
  • So use this if you wish to lock geo as disabled for if/when RFP doesn't cover it
  • Note also that there is a new pref (since FF58 permissions.default.geo) to set the default: 0=always ask (default), 1=allow, 2=block

🔻 fyi: planned for RFP

• browser.search.geoip.url 1369299

🔺 leaves the following

• beacon.enabled - by disabling this, you can reduce additional analytics being sent to web servers, see https://developer.mozilla.org/docs/Web/API/Navigator/sendBeacon
• browser.send_pings - see http://kb.mozillazine.org/Browser.send_pings
• dom.event.clipboardevents.enabled - this disables website access to clipboard events/content
• dom.min_timeout_value - this has nothing to do with privacy/security/anti-FP'ing

Sorry for the long post, but OP made me do it :)

[mkaply]

I honestly don't see fingerprinting as something that interesting from a GPO perspective, so I won't be placing a high priority on this.

If anything, fingerprinting can create problems for enterprises. See:

https://bugzilla.mozilla.org/show_bug.cgi?id=1426232

AutoConfig will continue to be available to set these preferences.

[Thorin-Oakenpants]

If anything, fingerprinting can create problems for enterprises

It can create problems for any release branch. RFP is not front facing for reason.

AutoConfig will continue to be available to set these preferences.

Agreed. Otherwise you'll end up with a thousand policy items, and a PITA to maintain it all

I honestly don't see fingerprinting as something that interesting from a GPO perspective

I actually think it's a great pref to include (once it is front facing) as it reduces the need want for a lot of others (see next point)

We have a preferences that resists fingerprinting. I'll check into how many of these it affects.

Tried to save you some time. I was just pointing out the prefs in OP, that some were deprecated, that some (most) are not needed with RFP, and that some actually alter your fingerprint with RFP (even more reason to not use them).

Anyway, truck on. Hope my input helped

[mkaply]

Anyway, truck on. Hope my input helped

@Thorin-Oakenpants Your input was great. I really appreciate it. And yes, I will probably include the actual fingerprinting pref, but not any of the individual prefs.

My comments were more to the original reports.

And I appreciate the details you put into your ghacks user.js documentation.

[jjurkus]

Anyway, truck on. Hope my input helped

You certainly helped me! Would I be able to find out things like this myself? If one searches for a preference you mostly get outdated pages and documentation. Is there somewhere in the code I should look?

[Thorin-Oakenpants]

@jjurkus .. well, we just so happened to have someone come dump 564 prefs at us (please don't do this to us me!), so we gave him some pointers - see here and a few subsequent comments about using DXR

PS: we've mapped Mozilla's DNA multiple times, and dug out the important stuff for privacy/security/tracking/anti-FP'ing etc (excluding most of those that are best at default) - so anyway, out of FF60's 3261 prefs, we have 469 of those (i.e relevant to FF60, I've excluded everything else) documented/covered in our user.js, and over 250 links for those prefs to relevant docs etc

If you want any more help, start a new topic etc at our repo, rather than get OT here

[jjurkus]

Thank you so much. Now I can open some new issues with stuff that is in my autoconfig and still relevant.

our repo

That's the https://github.com/earthlng/FFprefs-diffs right?

[Thorin-Oakenpants]

@jjurkus - this repo: https://github.com/ghacksuserjs/ghacks-user.js

[mkaply]

I don't consider these enterprise specific features and hence not candidates for policies.

You can continue to set them via AutoConfig. I will look at adding the fingerprinting pref to policies.