Even if PDF.js is in general more secure than certain external PDF readers, it now provides a common attack surface for potentially every platform FF runs on, and therefore, it could make FF less secure on certain platforms than it would be if it simply delegated to whatever PDF reader the platform or users prefer. Instead of having to find 0-days for Adobe Reader on Windows, Evince/Okular on Linux, and others, they only had to find a flaw in PDF.js itself.
The PDF.js project was started largely because Adobe Reader has a horrible security track record and Windows users don't keep it up to date. Well, Linux users don't generally use Reader, and they benefit from package management, so they were just needlessly put at risk to protect others.
I have changed FF to open all PDFs with Evince, and I couldn't be happier. It's faster and has a better UI. I've added it to the ever-growing checklist of things to do after installing FF, which includes installing multiple plug-ins to partially mitigate browser fingerprinting, something that Mozilla has known about at least since 2010 but has done virtually nothing to prevent[1] and something that I and many other users would prefer they work on instead of PDF.js or Pocket integration.
The original blog post from Mozilla explicitly stated versions of Firefox without pdf.js were unaffected and a Mozilla employee confirmed disabling pdf.js would be enough to protect against the exploit. Mozilla was also extremely cagey about the nature of the exploit, its severity, and who might have been affected by it.
If people were misled into thinking pdf.js was completely to blame, then that's Mozilla's fault.
As far as I understand PDF.js used the 'PlayPreview' feature (Playpreview is the overlay you get to see to confirm you want to activate a plugin) as a 'hack' to inject PDF.js HTML content (resource://pdf.js/web/viewer.html) into the page because the plugin architecture was not flexible enough. So, even though technically PlayPreview is not part of PDF.js, the combination of PDF.js and PlayPreview specifically made it possible to inject content into PlayPreview and bypass the CSP.
I cannot cope with PDF.js, always making sure an external viewer is used.
It doesn't matter how beefy a machine is, the world freezes when a PDF is being open. Then there is the slow pagination, zooming and lots of boxes instead of characters.
It's still not as fast as a native PDF reader, and probably never will be. When I'm dealing with really large PDFs (e.g. the Intel x86 docs, which are 1000+ pages) I still use a native PDF reader. But I find that pdf.js does just fine on documents of up to a few hundred pages. Which is, y'know, most of them.
And having PDFs open in the browser is so convenient -- I get a happy feeling every time I open a PDF and I don't get a dialog asking me to save this file and/or open it in an external application.
Linux users of Firefox are a tiny minority of Firefox users. The overall diversity, when considering the ecosystem as a whole, doesn't change much with the addition of pdf.js.
Compared to the large improvement in security that the JS sandbox provides (and yes, sandboxes do improve security despite sometimes having holes) compared to (say) unsandboxed Evince, the security benefit from diversity is minimal.
I don't care that much about fingerprinting. For example, the problems with navigator.plugins fingerprinting is small compared with the problems in the plugins themselves.
The PDF.js project was started largely because Adobe Reader has a horrible security track record and Windows users don't keep it up to date. Well, Linux users don't generally use Reader, and they benefit from package management, so they were just needlessly put at risk to protect others.
I have changed FF to open all PDFs with Evince, and I couldn't be happier. It's faster and has a better UI. I've added it to the ever-growing checklist of things to do after installing FF, which includes installing multiple plug-ins to partially mitigate browser fingerprinting, something that Mozilla has known about at least since 2010 but has done virtually nothing to prevent[1] and something that I and many other users would prefer they work on instead of PDF.js or Pocket integration.
1. https://wiki.mozilla.org/Fingerprinting