1999126 - Protect whether PDF.js is enabled/disabled to improve fingerprinting protection

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, enhancement)

Description

[celenity [:celenity]]

Currently, when PDF.js is disabled (via the pdfjs.disabled pref), Navigator.pdfViewerEnabled is set to false, and Navigator.mimeTypes + Navigator.plugins are modified to return an empty list. This is problematic, as it can aid fingerprinting.

For reference, we (IronFox) have a patch that prevents these values from being modified when PDF.js is disabled.

Ideally, I think Firefox should consider also adopting this approach - but, if there's concerns for ex. compatibility, I think it'd at least make sense to add a target to protect this with RFP/FPP. This would allow users to safely disable PDF.js if desired (ex. if they prefer using an external PDF Viewer), but without compromising privacy by aiding fingerprinting.

Comment 1

[Emma Zühlcke [:emz]]

The navigator field pdfViewerEnabled is standardized and adopted across all major browsers: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/pdfViewerEnabled so there is a compatibility risk here if we made it always return true. How high of a risk this is, I'm not sure. I'm also curious how many users have the PDF viewer disabled and whether this a supported configuration / whether this is exposed anywhere.

Comment 2

[Emma Zühlcke [:emz]]

After some quick code search, the only place where I see this pref exposed is enterprise policy. So the pdf reader can be disabled via policy.

Tom, is this additional fingerprinting surface worth looking into? Should we "lie" to the website about the pref state?

Comment 3

[Tom Ritter [:tjr] (OOTO until April)]

With a Firefox hat on, I would say that this is not a situation I think meets the bar for addressing. From our data collection: .05% of people (~5k out of 11.3m) have disabled the pref.

With a Tor hat on, I would point to this document which basically says "We can't protect the user from every pref they flip, there's just too many to try to fix and maintain."

I think this is a WONTFIX, sorry. (I haven't forgotten about Bug 1965677 but also not sure when I can get to it.)

Comment 4

[Emma Zühlcke [:emz]]

Thanks, I think WONTFIX makes sense here (unfortunately!).

Comment 5

[celenity [:celenity]]

Thanks for taking a look at this folks.

While I can understand/respect the rationale here, I think this should be reconsidered for a few reasons:

• There are currently existing RFPTargets that protect against prefs that aren't default or exposed in the UI. Here are a few examples:
  • NetworkConnection depends on dom.netinfo.enabled (which is false by default, and not exposed in the UI)*.
  • HttpUserAgent goes out of its way to override the value of general.useragent.override (Not only is this pref not exposed in the UI, it's also hidden).
  • JSLocale depends on privacy.spoof_english (which is disabled by default and isn't exposed in the UI, unless RFP is enabled - though the target works independently of RFP).
• I'm not sure how useful the telemetry data is here, since I suspect that the users likely to disable PDF.js are probably the ones who are more likely to disable telemetry - but that's just a guess, I could be wrong.
• In terms of risk for web compat/breakage, FWIW: Since introducing our patch several months ago, we (IronFox) haven't encountered a case of breakage caused by protecting these values. Of course, we have a smaller user base than Firefox, so it's possible that protecting these values causes breakage somewhere and it just hasn't been reported to us yet, but this at least provides a baseline.
• In general, being able to disable PDF.js is a useful feature for users depending on their use case (I'm surprised this isn't user-facing, Chromium does have a UI setting to disable their PDF Viewer for reference), and it's really unfortunate that there's not a way for users to take advantage of it without compromising their privacy/aiding fingerprinting (Though, I think we do agree on this point).

For a possible compromise: would you please consider at least adding a separate pref to protect these values? IDK what this would look like, maybe something like privacy.spoof_pdfjs (I'm thinking similar in name to privacy.spoof_english)? It could be off by default, but enabled by users who do wish to spoof/protect these values from fingerprinting. I think this would also help solve any compat concerns, since, this way: it'd be an opt-in, non-standard protection.

I'm curious to hear thoughts here. In general, I think this is still worth considering, and I appreciate your time/support.

Comment 6

[Emma Zühlcke [:emz]]

Thanks for the detailed writeup. What are use cases for disabling PDF.js?

If the overhead of maintaining a pref to spoof PDF reader enabled state is low, e.g. because the patch is quite small, I wouldn't be opposed to accepting a patch for that. Though we'd probably check in with the DOM team about that.

Comment 7

[celenity [:celenity]]

What are use cases for disabling PDF.js?

Here are some examples:

• Users might prefer to use a separate/dedicated PDF Viewer for security reasons.
  • For example, GrapheneOS maintains a hardened PDF Viewer for Android.
  • This is not to say that PDF.js is insecure; I believe it is indeed secure (For reference, GrapheneOS actually uses PDF.js as a base for their secure PDF Viewer...), but I don't think that PDF.js in a browser, like Firefox, offers the same level of security as a dedicated, specialized solution, such as the GrapheneOS PDF Viewer.
• Users might need to use a separate/dedicated PDF Viewer for accessibility reasons.
• Users may need/prefer features or functionality of a separate/dedicated PDF Viewer that PDF.js in Firefox currently lacks.
• In general, I think it also comes down to personal preference: Users may just simply prefer to use a separate/dedicated PDF Viewer over PDF.js in Firefox for whatever reason. As it's one of Mozilla's core principles to provide users with freedom and control over their browsing experience, I think this is something important to keep in mind.

If the overhead of maintaining a pref to spoof PDF reader enabled state is low, e.g. because the patch is quite small, I wouldn't be opposed to accepting a patch for that.

I suspect a patch here would be trivial. I believe that all we'd need to do is (assuming the pref is a boolean value, named privacy.spoof_pdfjs):

• In Navigator.cpp, we'd want to modify this line, from:
  • bool Navigator::PdfViewerEnabled() { return !StaticPrefs::pdfjs_disabled(); }, to something like:
  • bool Navigator::PdfViewerEnabled() { return (!StaticPrefs::pdfjs_disabled() || StaticPrefs::privacy_spoof_pdfjs()); }
• In nsMimeTypeArray.cpp, we'd want to modify this line, from:
  • bool nsMimeTypeArray::ForceNoPlugins() { return StaticPrefs::pdfjs_disabled(); }, to something like:
  • bool nsMimeTypeArray::ForceNoPlugins() { return (StaticPrefs::pdfjs_disabled() || !StaticPrefs::privacy_spoof_pdfjs()); }
• In nsPluginArray.cpp, we'd want to modify this line, from:
  • bool nsPluginArray::ForceNoPlugins() { return StaticPrefs::pdfjs_disabled(); }, to something like:
  • bool nsPluginArray::ForceNoPlugins() { return (StaticPrefs::pdfjs_disabled() || !StaticPrefs::privacy_spoof_pdfjs()); }

So, the DOM team would probably know best here, but, I'd be surprised if this change required any notable overhead.

Comment 8

[celenity [:celenity]]

For a slight correction, the lines at nsMimeTypeArray.cpp and nsPluginArray.cpp would need to be modified to use && instead of ||, that was my mistake.

Comment 9

[Emma Zühlcke [:emz]]

Thanks! If the change is that small it might be okay to support. But since this is all in DOM code I'll move the bug there for consideration.

Comment 10

[Tom Ritter [:tjr] (OOTO until April)]

Attachment: Bug 1999126: Hide the value of the pdfjs pref from being disabled when RFP is enabled r?timhuang

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/3c75fa7e4427
https://hg.mozilla.org/integration/autoland/rev/843b29f3d831
Hide the value of the pdfjs pref from being disabled when RFP is enabled r=timhuang

Comment 12

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/843b29f3d831

Comment 13

[Thorin [:thorin]]

We used to protect this - added in FF100 Bug 1756280 but unfortunately it got ripped out (without consultation AFAIK - edit: It was removed in FF116 in Bug 1838415) when everything moved to RFPTargets - and it has been on my list of (many) things to tighten that users like to change that hurt the Tor Browser crowd [1]. Whilst we can't ultimately protect against user changes, we can and should harden against common misconceptions (or causes on entropy in studies), the UI, and make about:config have a per-session-sticky warning.

[1] It's in most scripts [2] It's listed in many "hardening" guides - e.g. use a dedicated pdf with no JS yada yada yada

nfi piero for backport to TB, unless someone wants to backport to ESR