Comment by pissedffuser | Hacker News Reader

Comment by pissedffuser | Hacker News Reader

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.

1. https://wiki.mozilla.org/Fingerprinting

Apparently the bugs weren't in pdf.js, but in Firefox, and could be exploited through pdf.js and possibly other extensions.

https://news.ycombinator.com/item?id=10023517

Let's not give the project a bad name for someone else's bugs.

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.

Please have a look at the following comments: https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c5 and https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c7

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.

Yeah, and that feature was only used in the Firefox deployment of pdf.js.

https://github.com/mozilla/pdf.js/commit/4f3f983a214867011dd...

Not sure who's to blame, but like he said, there was no vulnerability in the web version.

That's correct. I don't think we should blame the PDF.js devs either.

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.

pdf.js was quite slow when it was first released. But have you tried it lately? It's a lot faster and less memory-hungry than it used to be. E.g. see https://blog.mozilla.org/nnethercote/2014/02/07/a-slimmer-an... and https://blog.mozilla.org/nnethercote/2014/06/16/an-even-slim..., and there are plenty of other optimizations have occurred as well. It's PDF conformance has also improved greatly.

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.

> pdf.js was quite slow when it was first released. But have you tried it lately?

Not really. Even though I also do web development from time to time, I tend to favour native applications.

And as you acknowledge, it is still slower.

> 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 overwhelming majority of Firefox users are on Windows, so statistically this doesn't result in the conclusion you think it does.

Yes it does. Statistically, all Linux users running Firefox have been adversely affected when they needn't have been.

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.

Reply on news.ycombinator.com