What is pdf.js for ?

[Suppacrew]

Hi,

I was wondering, what is there to gain in allowing pdf.js ? I can view all PDF files just fine if I allow only the website they're on (or nothing at all if they are from my HDD).
I think the PDF format supports JavaScript. Is it what pdf.js is for ? Allowing the in-PDF JavaScript to be ran ?

Thanks

[barbaz]

Your question is ambiguous.
If you mean the pdf.js that shows up in the NoScript menu when you view PDF using Firefox's built-in PDF viewer, that is "resource://pdf.js" and you can leave it not Allowed because it should be Allowed anyway. Don't mark it Untrusted, just leave it alone. It's internal to that PDF viewer.

If you mean the "PDF.js viewer" - well, that's the name of Firefox's built-in viewer, and it's also available as an extension. It's for viewing PDFs and rendering them using web technologies.

[Suppacrew]

Sorry, I meant what you said in your first paragraph. pdf.js is listed without the resource:// bit because of my NoScript configuration, but now that I know it's resource://pdf.js I understand that it has never been blocked since the resource:// is whitelisted by NoScript. And if it has never been blocked, then that resource is the actual PDF viewer code and not something separate such as NoScript's way to allow/disallow in-PDF JavaScript.

In that case, the way it appears in the menu is a little misleading. When pdf.js is effectively allowed because resource:// is allowed, the menu item should display "Forbid pdf.js" or something rather than "Allow".


I wonder though, how does vanilla Firefox deal with in-PDF JavaScript ? Does it run it or does it ignore it ? In Adobe Reader, most PDF files work just fine with JS disabled and so, it would be nice if NoScript could intervene in some way to reproduce this behaviour. Currently and assuming vanilla Firefox does run in-PDF JS, then it's either "PDF is not displayed" or "PDF is displayed with in-PDF JavaScript".

[barbaz]

the way it appears in the menu is a little misleading. When pdf.js is effectively allowed because resource:// is allowed, the menu item should display "Forbid pdf.js" or something rather than "Allow".

Or not appear at all, it should only appear as the greyed out "Forbid resource:". Yes, I agree that's an inconsistency/bug.

I wonder though, how does vanilla Firefox deal with in-PDF JavaScript ? Does it run it or does it ignore it ? In Adobe Reader, most PDF files work just fine with JS disabled and so, it would be nice if NoScript could intervene in some way to reproduce this behaviour. Currently and assuming vanilla Firefox does run in-PDF JS, then it's either "PDF is not displayed" or "PDF is displayed with in-PDF JavaScript".

I don't use Firefox but here is how you can find out: create a new, clean test profile, disable the built in PDF.js viewer through about:config (I think it's pdfjs.enabled -> false ?), grab the latest dev build of PDF.js from https://github.com/mozilla/pdf.js, and try that out with some test PDF that contains harmless JS such that you will be able to just see if it executes or not. I say to try the dev build because it will have more features and fixes than whatever is built into Firefox, so more likely to even support PDF javascript if they're going to.
IMO if javascript in PDFs is going to be executed at all in PDF.js viewer, it "should" execute when the site hosting the PDF is Allowed, and not when it isn't (you shouldn't need to allow the site hosting the PDF to get it to display in PDF.js). Doesn't mean it will or even can work that way though..

[Suppacrew]

you shouldn't need to allow the site hosting the PDF to get it to display in PDF.js

I agree if it's no more risk than basic HTML+CSS webpages. I don't know what the PDF format includes though, aside from JavaScript.

IMHO PDF should ideally be treated by NoScript the same as a regular webpage, with safe parts displayed by default like images, text and layout information. PDF JavaScript should be tied to the host presence in the whitelist, custom fonts to fonts, etc. But as you say, I'm not sure Firefox's PDF viewer is made in such a way that NoScript can have such fine-grained control.

Either way, thanks for your replies!

[barbaz]

you shouldn't need to allow the site hosting the PDF to get it to display in PDF.js

I agree if it's no more risk than basic HTML+CSS webpages. I don't know what the PDF format includes though, aside from JavaScript.

I meant that is the way it is now, but it didn't used to be that way - so not sure why you are needing to allow the site unless you are using a very old version of PDF.js viewer.

IMHO PDF should ideally be treated by NoScript the same as a regular webpage, with safe parts displayed by default like images, text and layout information. PDF JavaScript should be tied to the host presence in the whitelist, custom fonts to fonts, etc. But as you say, I'm not sure Firefox's PDF viewer is made in such a way that NoScript can have such fine-grained control.

Either way, thanks for your replies!

+1, and you're welcome.

[Suppacrew]

not sure why you are needing to allow the site unless you are using a very old version of PDF.js viewer.

Odd. I'm using Firefox 38 with NoScript 2.6.9.22 and it has always been that way for me. Unless the PDF comes from file:///, I can't see it without allowing JS on the website. I thought it was working as expected by Giorgio.

My NoScript config is rather tough, the whitelist is empty except from the grey items and I forbid everything that NoScript can deal with; applied to trusted sites too.

My profile is rather clean as is my fresh Win 7 64bit install.

[barbaz]

You might try experiment with a new profile as above, disable the builtin pdfjs viewer, install the dev build extension, see if you still have to allow the site. I've never used the built-in PDF viewer, always some version of the extension.

Or you can create the new profile, completely shut down Firefox, copy your entire current profile into the new profile, start Firefox in the new profile, then disable built-in pdf viewer replace it with the dev build extension, see if you have to allow the site then.

[Thrawn]

But as you say, I'm not sure Firefox's PDF viewer is made in such a way that NoScript can have such fine-grained control.

I doubt it. PDF.js renders binary PDF data using JavaScript and HTML5. All the usual points where NoScript would intercept traffic don't apply.

However, PDF.js is already a much more limited subset of PDF functionality than eg Adobe, and thus much less attack surface.