pdfjs.disabled used to be part of RFP until Bug 1838415; lock pref to false in stable

in FF116 1838415 in Don't spoof explicitly disabled pdfJS RFP no longer ignores the pref pdfjs.disabled. The original RFP protection was done to help against disk leaks and to provide a uniform fingerprint [1]

Given these two aspects, we should just lock the pref in stable release

[1] There are only two possible values for combined plugins, mimeTypes and pdfViewerEnabled

added Disk Leak Fingerprinting labels

marked this issue as related to #42240

added Backlog label

mentioned in issue #42289 (closed)

added Task label

added All Platforms label

added 14.0 stable label

marked this issue as related to #42752 (closed)

mentioned in issue #42752 (closed)

removed Backlog label

added Next label

assigned to @pierov

added Needs Information label

removed Next label

make sense to lock this one?

We can probably do it.

I should check whether you can still tell the browser not to open a PDF immediately.

(And maybe this can be even fingerprinted on the server side...).

What would be a bad impact on users?

1. They will have to open a PDF in browser even to download it. Maybe bad for some people, but eventually you'll be still able to download the PDF
2. Shall there be a 0-day in pdf.js, users won't be able to disable it. I hope this won't happen, and the pros are above the cons

Reasons to do it:

• we already lock RFP, and RFP took importance over this pref, so as a matter of fact it was like this pref was already locked
• it'd be trivial to fingerprint, and it looks like something users could disable not thinking about fingerprintability
• also disk leak protection? (somehow connected to my work on #42220, where I found also a pref to ignore PDF attachments and open them inline)

Curious: @tjr do you recall why you did this change?

I think... we were removing Unknown and we needed to decide what to do with this situation. I believe I had recently written a proposal for how I felt RFP should behave, which included overriding User Settings available on the preferences page but not trying to override user preferences in about:config because there are so many of them that we would either always be in a partial-execution where we override some but not others with no clear explanation why or we would have to spend a ton of continuous work to be comprehensive and consistent. And given that thinking, we removed it.

I'd also note that overriding user preferences would blow us way past our 64 bits of RFPTarget and we'd need to refactor that architecturally to be expandable and performant.

I believe I had recently written a proposal

https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/wikis/RFP-Behavior

I see, thanks. It probably makes sense for us to follow Thorin's suggestion and lock it in this case.

We should also open an issue about reviewing that change, in case there are similar changes we missed.

I'd also note that overriding user preferences would blow us way past our 64 bits of RFPTarget and we'd need to refactor that architecturally to be expandable and performant.

I think that problem is going to arrive sooner rather than later .

removed Needs Information label

added Doing label

assigned to @morgan and unassigned @pierov

mentioned in merge request !1181 (merged)

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

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

changed title from lock pdfjs.disabled to false in stable to pdfjs.disabled used to be part of RFP until Bug 1838415; lock pref to false in stable

marked this issue as related to #43126 (closed)

mentioned in issue #43126 (closed)

closed