After all, pdf.js has no more or less permissions than any other JS you might encounter in the wild
Are we sure about this? JS loaded from localhost can do some dangerous stuff because CORS doesn't apply anymore to local resources such as the filesystem. What context does pdf.js run in? If Mozilla didn't carefully sandbox it, and if it executes PDF Javascript embeds (does it?) then it could potentially have filesystem access? This would mean that the closed-source spyware platform from Google might actually be safer in this case. But I don't know; pdf.js might be injected into the remote resource and therefore have CORS restrictions tied to the source domain. It's all implementation.. I'd be inclined to use pdfotext for textual data or GIMP as Steve recommended. You can probably use some combination of common PDF utils, headless GIMP, and ImageMagick to make a script to do the same thing instantaneously. On 10/06/15 23:01, Riad S. Wahby wrote:
Seth <list@sysfu.com> wrote:
Curious if the advice given above is still relevant and also what other on the list recommend for safe viewing of PDFs.
If your web browsing habits don't include NoScript, then you're likely no worse off using pdf.js to view PDFs than you are browsing arbitrary websites. After all, pdf.js has no more or less permissions than any other JS you might encounter in the wild; and since pdf.js is bundled with modern versions of Firefox, you might be inclined to think that it's likely non-malicious even if it's exploitable by rogue PDFs. But that's no worse than some JS malware you were fed via DNS poisoning or CDN hijacking.
(This can be seen either as an implicit endorsement of pdf.js or of NoScript.)
-=rsw
-- Scientific Director, IndieBio Irish Programme Now running in Cork, Ireland May->July Learn more at indieb.io and follow along! Twitter: @onetruecathal Phone: +353876363185 miniLock: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM peerio.com: cathalgarvey