2617: pdfjs.disabled

[Thorin-Oakenpants]

earthlng

I also think 2617 (pdfJS) would be better if we change the value and the title (to: disable) and comment it out. It currently enforces the default value (=enable pdfjs) which I think is weird in a file that aims to enhance security. Idc whether we enable or disable pdfJS by default btw

---

Sorry for the repost. This is best discussed as a separate topic

2617 (pdfjs).

We have four options:

1. enforce default value (false) <- currently what we have
2. inactive default (false)
3. enforce using an external app (true)
4. inactive use an external app (true)

FALSE

• Option 1 = current
• Option 2 seems reasonable at first glance. Change 2617: enable pdf.js... wording to 2617: enforce pdf.js... and make the pref inactive. This means that the default is still observed, and the js no longer meddles with experienced users' who have switched to a possibly more secure pdf reader.

TRUE

• Option 3 should not be a no no IMO. Enforcing an external app, we have no idea what app they use, might be a 2 yrs old adobe acrobat. They might not even have a pdf reader on their system. Not a responsible thing to do.
• Option 4 seems problematic. Suggesting an external app. It would encourage users to use an external app, but we provide no help with that. IMO 99% of users are best off with the internal viewer.

[Atavic]

Option 4 here, see: #20 (comment) (the ending part)

[Atavic]

Yes, I always have to answer yes by clicking another time to open pdf files.

[earthlng]

What I'm suggesting is something like this:

/* 2617: disable pdf.js as an option to preview PDFs within Firefox - EXPLOIT risk
 * blablabla - would probably need to adjust the original text here slightly ***/
   // user_pref("pdfjs.disabled", true);

I guess that would be option 4 (?). pdfjs is still enabled that way, and as far as I understand, is consistent with your "title + pref relationship logic" ie. title says disable and the pref (when un-commented) does disable it.
And I think we also have a pref that disables "open with" anyway, don't we? can't remember right now, but it wouldn't really matter because pdfjs is still enabled by default (because FF's default is "use pdfjs" and our pref is commented out)
On Windows sumatraPDF seems like a good light-weight pdf reader, so we could also recommend that, fe
when you disable pdfjs you should use a "secure" and up-to-date pdf reader like sumatrapdf

[earthlng]

I think I caused some confusion by only writing "default value". Maybe we should start using "default value in Firefox" vs "user.js default value" or something like that.

Your concerns are all valid and I agree that pdfjs is definitely preferable if the alternative is an outdated Adobe reader or similar. But pdfjs vs something like sumatrapdf, the latter is always way better IMO.
sumatrapdf is a very "simple/lightweight" pdf reader that is more than enough to read pdfs downloaded from the internet, and I've so far never heard about an exploit for it. But other Adobe alternatives like Foxit reader or whatever it's called had exploits before because it supports a wider range of features. (forms, javascript in pdfs, etc)
BUT I don't want to disable pdfJS in the user.js, only change the wording and the value, to make it easier to disable it without needing to change the prefs value as an end-user.

[earthlng]

you're right, and I never really liked the 0400 Quiet Fox title because of it.

[RoxKilly]

I tested Firefox 53 using this US Constitution PDF. Besides the 2 prefs mentioned, there is also the UI option (don't know which pref it corresponds to) below:

If I set:

pdfjs.disabled = true
browser.download.forbid_open_with = true
Options >> Applications >> Acrobat Document = Always Ask (or Save File)

I'm forced to save to disk (or cancel). If I leave the prefs the same but set:

Options >> Applications >> Acrobat Document = Specific Program

Then that program is automatically launched when I click on the PDF

[earthlng]

a pdf link that does not explicit state via js that pdfjs be use

I don't think that's possible ie. JS can't state to use pdfjs. Idk where you got that information.
If pdfjs is enabled then Firefox itself will trigger it and open the pdf link with pdfjs, otherwise it won't.

Then that program is automatically launched when I click on the PDF

I think you can stop that behavior if you want, with the network.protocol-handler.* prefs.
Based on your testing it seems that network.protocol-handler.warn-external-default;true is broken

are you forced to save it to disk?

I use

pdfjs.disabled = true
browser.download.forbid_open_with = true
Options >> Applications >> PDF file = Always Ask

... and same as @RoxKilly, I'm forced to save to disk or cancel. I don't have an external app linked in FF for pdf. You can remove the linked App by clicking on "Use other..." and delete it from there.

there is also the UI option (don't know which pref it corresponds to)

it's not a pref afaik, everything under Options >> Applications is stored in mimeTypes.rdf
It's a plaintext file so if you're careful you can edit it and clean out the things you don't want.

[earthlng]

bump. We only need to change "enable" to "disable", change the value to TRUE and comment it out. The rest of the description can remain the same IMO. PDFjs would still be enabled because FF's default value is FALSE.

[earthlng]

But would the inexperienced/non-knowledgeable perps really change the default via Options>MIME types? I don't think so. But okay, I can change my own user.js to be a more logical item. We can close this then.

[earthlng]

@Atavic, yeah you don't have to tell me, Pants is the one who thinks we should make this idiot-proof.

Go to https://github.com/cmatskas/PdfJsSample/ and click on the pdf.pdf and watch it display in your browser

After I allow several domains and things in noScript + uMatrix the pdf is rendered as HTML5 but that's because they use a copy of pdfjs. That's very different from triggering the built-in PDFjs.

PK's user.js also disables pdfjs btw

Yes, mozilla will certainly fix stuff quickly but they would first need to be made aware of it.
According to wikipedia pdfjs was first introduced in 2012, enabled in 2013 and was then first publicly exploited 2 years (!!) later. Mozilla didn't find that bug in those 2 years. Instead of making some cash in 2015 the guys who found it could have sold it on the black market and we would possibly still don't know about it today.

[earthlng]

do we make this active or inactive?

I don't think it's necessary to force-enable pdfjs and IMO we can make the pref inactive

[earthlng]

If you want to keep the item as "enable" and with the value "false" you might as well keep the pref active

[earthlng]

for all the pdf reader experts

no need to be passive aggressive buddy.

If that's as far as you're willing to go ie. only make the pref inactive but keep the item as "enable" then yeah, keep the pref active. I already said I'm okay with that and even closed the issue at one point myself, so be my guest. I can understand your reasons and am okay with keeping it that way. nuff said

[earthlng]

I don't like the re-write at all but whatever. Apparently you're the only "PDF security expert" around here:

pfdjs is ... as secure as any pdf reader out there, certainly better and more vetted than most

"When you point one finger, there are three fingers pointing back to you." :)

ps: pfdjs (sic)