policies.json not working for privacy.fingerprintingProtection.overrides

[Bingo90]

Hello,

I created a policies.json file to change some settings system wide for multiple profiles.
I'm using Fedora Linux 41 KDE, but I don't think this matters, because policies seem to be the same across operating systems. .

Here it is:

{
  "policies": {
    "Preferences": {
      "privacy.fingerprintingProtection.overrides": {
        "Value": "-FontVisibilityBaseSystem,-FontVisibilityLangPack",
        "Status": "default"
      },
      "browser.tabs.searchclipboardfor.middleclick": {
        "Value": false,
        "Status": "default"
      }
    }
  }
}

The "browser.tabs.searchclipboardfor.middleclick" one works. It usually defaults to true on Linux, but this way, it defaults to false.

The privacy one doesn't work though - it's still empty in about:config. I need to change this, as some fonts (like on Microsoft's login page) don't display correctly.

Is there any way to make this work?

[celenityy]

I really hope support for this pref gets added - as well as for privacy.fingerprintingProtection.remoteOverrides.enabled & privacy.fingerprintingProtection.granularOverrides - the latter of which may actually be more suited for your case (For instance, you could disable just those 2 protections for the Microsoft login page, and leave everything else enabled elsewhere if desired, etc...).

[mkaply]

I'll probably just allow privacy.fingerprintingProtection

Someone (maybe you?) opened a bug. It will happen fairly quickly.

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

[celenityy]

Great! 😉

If possible, to go along with this, I wouldn't mind seeing support for these fingerprinting-related preferences as well:

• privacy.resistFingerprinting.block_mozAddonManager
• privacy.resistFingerprinting.letterboxing
• privacy.resistFingerprinting.target_video_res
• privacy.window.maxInnerHeight
• privacy.window.maxInnerWidth

Despite what the naming suggests, the first 3 prefs work independently of RFP. Very appreciative of your time, consideration, and work here @mkaply :)

[mkaply]

I've added privacy.window to the bug

[mkaply]

From the team:

"These preferences control some behaviors that are intended for Resist Fingerprinting and Tor Browser. While privacy.fingerprintingProtection.overrides could make them take effect, we do not recommend adding targets to overrides as the fingerprinting protection provided is not well understood and is likely to cause website breakage. We are adding the privacy.fingerprintingProtection pref and subprefs to enable enterprises to unbreak particular websites if necessary, and would appreciate better understanding what and why you needed to do, but can not support configurations that add fingerprinting targets."

[celenityy]

@mkaply Thanks for the update, and again for your time looking into this. To confirm, this is specifically referring to privacy.resistFingerprinting.block_mozAddonManager, privacy.resistFingerprinting.letterboxing, & privacy.resistFingerprinting.target_video_res?

Assuming that is the case, I'd appreciate elaboration from the team, particularly regarding:

the fingerprinting protection provided is not well understood and is likely to cause website breakage.

I don't see how either of these 3 preferences could cause website breakage.

• privacy.resistFingerprinting.block_mozAddonManager disables the mozAddonManager API. This exposes details regarding installed extensions, which could be used for fingerprinting. AFAIK this API is only used by addons.mozilla.org, meaning it isn't of use to organizations who self-host or distribute their own add-ons, block installation of add-ons from addons.mozilla.org, or block the installation of add-ons completely. The AMO will also fallback if mozAddonManager is disabled, meaning extensions can still be installed from addons.mozilla.org as expected.
• privacy.resistFingerprinting.letterboxing dynamically rounds content dimensions, meaning you'll just see dark bars around your Firefox window. This provides stronger protection against fingerprinting, and I fail to see how it could cause breakage, due to the nature of this feature.
• privacy.resistFingerprinting.target_video_res is useful for changing the preferred resolution for video playback. This could be desirable for organizations to configure so that videos on the web play as expected, at their proper resolution. At the time I requested this above, I was under the impression that this was still set to 480p by default - but it appears that Firefox is now instead using 1080p, which is a far more reasonable value. For that reason, I can understand if this isn't considered - but I still think it would be beneficial for enterprise use cases as described, and I also don't understand how it could cause breakage.

To clarify, I'm not asking for privacy.resistFingerprinting itself or all of its subprefs to be made available, as I would agree with the team that these are not well understand, not desirable in most cases, and will cause breakage. I'm specifically asking for these 3 preferences, as they are well understood, don't cause breakage (at least AFAIK, I hope the team will correct me if I'm wrong...), improve privacy & protection against fingerprinting, and could be desirable for organizations to configure to meet their needs.

[tomrittervg]

When I gave Mike that response, I was actually referring to privacy.window.maxInnerHeight and privacy.window.maxInnerWidth - these prefs won't do anything unless you enable RoundWindowSize in the overrides pref, and in general, we don't recommend adding overrides (more on why below).

You are technically correct about block_mozAddonManager and letterboxing. target_video_res is weirder - it's used for spoofing the video playback statistics as represented in the VideoPlaybackQuality API and some other related APIs - it affects parsed, decoded, presented, and painted frame counts. I don't believe it is used for anything else actually, nor have I ever seen or heard of a fingerprinter looking at these APIs at all.

That said - I don't particularly want to expose them. In the past we made RFP available to extensions, and that capability has really bit us in the ass in terms of user confusion and bug reports and I think it gives a false sense of security. The fact is, we as a browser community don't have a great idea of what makes a user more or less fingerprintable to real adversaries or how many users are unique and why - but logically, if you are applying some unusual protections but not all the protections[0] - you're going to be more fingerprintable - not less. We have been working on a data analysis project that will answer those questions (for Firefox users) and that will help us decide intelligently what is the best ways to make people less fingerprintable and will roll those behaviors out in FPP over time.

[0] And even then, there's an almost certainty that some users with RFP enabled will still be unique because one characteristic like resolution is very unusual, and then they stand out from the small RFP crowd. Not to mention IP address-based tracking.

While I respect that end users should have complete control over their software, I think making settings that are more likely to cause harm than help people is detrimental. The customization points for these sorts of behaviors should really be buried so they are possible to use, but difficult to use. As an extreme example, resetting the behavior on start so it needs to be enabled each time. These preferences you're referencing, as well as RFP, can be set by an end user and they can even be configured by an autoconfig script, so I don't think they need to be exposed via the policy engine.

[celenityy]

@tomrittervg Thank you for your insight and the detailed response here, very much appreciated. I’ve seen you around projects like Arkenfox & Tor Browser, thank you for the work you do. It’s always nice to hear from an expert like yourself. :)

I was actually referring to privacy.window.maxInnerHeight and privacy.window.maxInnerWidth

That also surprises me to hear. For similar reasons asprivacy.resistFingerprinting.letterboxing, I'm not really sure how these could cause breakage, due to the nature of the protection?

target_video_res is weirder - it's used for spoofing the video playback statistics as represented in the VideoPlaybackQuality API and some other related APIs - it affects parsed, decoded, presented, and painted frame counts. I don't believe it is used for anything else actually, nor have I ever seen or heard of a fingerprinter looking at these APIs at all.

Interesting, thanks for the info. I can see how this could be used as a fingerprinting vector in theory - but as you said yourself later in this response, it's extremely difficult to know what fingerprinters are actually using in the wild, and I would also be surprised if this specific API is being used...

In the past we made RFP available to extensions, and that capability has really bit us in the ass in terms of user confusion and bug reports

I can definitely see this. I think a lot of folks just blindly enabled RFP (or had extensions blindly enable it…) in the past without understanding RFP’s implications/what it actually does, and I can’t begin to imagine how exhausting that's been for support to deal with over the years...

and I think it gives a false sense of security. The fact is, we as a browser community don't have a great idea of what makes a user more or less fingerprintable to real adversaries or how many users are unique and why - but logically, if you are applying some unusual protections but not all the protections[0] - you're going to be more fingerprintable - not less.

This is where I think I (partially) disagree. I’ll start with:

and I think it gives a false sense of security

In terms of RFP specifically, this is probably a reasonable conclusion to come to for the subset of users who enabled it without understanding the implications. That being said, I do think historically RFP has been an important tool & effective at enhancing privacy & security for users. I note historically because IMO it’s become obsolete for Firefox users due to FPP (of course still useful for Tor Browser & co. though…), which I think is generally an all-around better option, that I only expect to improve with time… (So thanks for your excellent work on it ;)). This is all a little besides the point though, since I’m not asking for RFP to be configurable through policies, and in fact I’d agree it’s probably best not to allow it there in favor of FPP.

For the specific prefs I referenced, I don’t think this is really a concern. Based on the naming alone, I’m not sure how it could be more obvious what they do… for example, it isn’t a shock that privacy.resistFingerprinting.letterboxing adds… letterboxing, it’s the point of the pref. I don’t think that’s the same as RFP itself - where you’ve got a highly complex feature changing a billion different things that users may or may not be aware of and may or may not understand the implications of. I feel like the prefs I mentioned are quite specific and narrow in scope, so I don’t think you’d see the confusion or the false sense of security like RFP itself can give.

The fact is, we as a browser community don't have a great idea of what makes a user more or less fingerprintable to real adversaries or how many users are unique and why - but logically, if you are applying some unusual protections but not all the protections[0] - you're going to be more fingerprintable - not less.

My understanding is that out of the box, every user/browser is already uniquely identifiable in some way, no? So, don’t you think it’d be better for users to at least have some protections vs. none at all? Is it really making matters worse?

For instance, if my monitor is an obscure size/resolution, (assuming size/resolution is being used for fingerprinting - like you said it’s incredibly difficult to know what metrics fingerprinters are using in the real world, and I look forward to seeing the results of this data analysis project + helping in any way I can…), that would cause a user to become fingerprintable. Yet, if I enable some form of letterboxing, now I’m mixing in more with the crowd of folks who for example also use letterboxing. This similar logic could be applied to other targets as well.

I’m definitely not saying people should go around randomly changing fingerprinting protections/targets if they don’t have a reason to - but I feel like there are plenty of legitimate cases where changing the prefs I mentioned can be beneficial.

It’s also worth taking into account that users already can configure these prefs and plenty of others on their own accord anyways, so all not making these available via policies is doing is hurting organizations who likely have legitimate, carefully considered uses for them…

While I respect that end users should have complete control over their software, I think making settings that are more likely to cause harm than help people is detrimental. The customization points for these sorts of behaviors should really be buried so they are possible to use, but difficult to use...

Due to the reasons I outlined above, I still don't really understand how the specific prefs I mentioned are causing harm.

I also want to empathize that I don’t think simply allowing preferences to be configured is the same as recommending or endorsing them. Would it not be feasible to just add some kind of Use at your own discretion warning for prefs like this if needed?

These preferences you're referencing, as well as RFP, can be set by an end user and they can even be configured by an autoconfig script, so I don't think they need to be exposed via the policy engine.

My understanding (based on what I’ve observed from @mkaply & others, please correct me if I’m wrong…) is that using autoconfig is generally recommended against nowadays in favor of policies. Policies are also far easier to deploy and maintain, and even more secure in some cases (For instance, to use autoconfig on macOS, you have to directly edit Firefox’s application contents - meaning you might have to grant your terminal or other software the permission to manage other applications… not exactly ideal for security reasons and this alone means it isn’t really an option for some organizations…).

@tomrittervg Thanks again to both you and @mkaply for taking the time to discuss and consider this, and I look forward to hearing your thoughts.

[tomrittervg]

Flattery will get you everywhere you know ;)

That also surprises me to hear. For similar reasons asprivacy.resistFingerprinting.letterboxing, I'm not really sure how these could cause breakage, due to the nature of the protection?

I don't think they would, no, I was referring to the general policy of "We don't recommend doing the thing that makes these relevant, so exposing them is tacitly encouraging use.

My understanding is that out of the box, every user/browser is already uniquely identifiable in some way, no? So, don’t you think it’d be better for users to at least have some protections vs. none at all? Is it really making matters worse?

No not necessarily. Many people, probably more than half, are - but some non-negligible percentage of people definitely share a fingerprint, especially when you limit the fingerprint-calculation to the parameters used by e.g. Sift Science or Akamai.

For instance, if my monitor is an obscure size/resolution...

As a nit I would say an obscure size/resolution is not likely to be fixed by letterboxing, but an unusual taskbar/dock height might be. Regardless I understand your point.

Ultimately, I still feel that allowing policies to control all the prefs you've mentioned is more likely to cause problems than help people, but if someone is actually using the policy engine, they are ten times or more likely to be intelligently address those problems if they arise than people randomly setting about:config prefs. Additionally, we have already acceded the greatest footgun of them all - the ability to add FPP overrides. (Which is necessarily if we want to allow people to remove overrides.)

I don't know if we have the ability to put a warning in the description, or if it's something we try not to do.