Add option to automatically allow opening of PDF links

[MachFour]

I decided not to comment on #147 because it was already closed, so I've made a new issue.

I'd also like to see an option to always allow opening of linked PDFs. If we wanted to see the PDF anyway, it's not going to be any more secure if we have to click an extra button to 'temporarily allow' the domain. than if there were a rule to do this for us. And it would remove an unnecessary inconvenience.

Is it possible to detect whether the PDF file to be opened was one that the user deliberately opened the link to (as opposed to a hidden/embedded PDF element that might be more untrustworthy)?

Cheers, Max

[AykutCevik]

As a user you can't always determine the content behind an URL so you may be phished this way. No resource must end on its original file extension. So a PDF locally called foobar.pdf can also be served by an url like http://example.org/samplesite/this/is/not/a/pdf/doc. So allowing PDFs globally will cause the problem @andryou described in #147.

[MachFour]

Hmmm... how is it that if I enable the 'always use system viewer' in the Chrome preferences, then I don't run into this issue? In other words, PDF links are always downloaded to my computer and opened externally without me having to allow the domain.

What I'm getting at is that there should be a distinction between the JS that is Chrome's internal PDF viewer, and the JS that is served from websites.

The option to always use the system PDF viewer has been my workaround so far, but I'd really rather just view PDF files in my browser (without having to enable each one explicitly in ScriptSafe) and only download them if I want to.

I appreciate this is a subtle issue though.

[stupid-genius]

ScriptSafe didn't used to have this PDF blocking behavior and it really should not have been added. ScriptSafe isn't a "security solution". The uninitiated have plenty of other vendors for that; ScriptSafe should stay focused on one thing: letting the user manage the execution of JavaScript in their browser. If you go down the route of shoving more and more cruft into it, you're going to start losing users (such as myself).

[Kn0wnWho]

In my opinion it is a great addition to ScriptSafe to block PDF opening because during the previous years I have stumbled upon way too many infected pdf documents from websites, and it is great that I had ScriptSafe enabled otherwise I would have conducted an infection. And with the expansion of Website APIs say WebVR coming in it is great to have that little extra help towards newer malware / viruses.

[ghost]

I often do a google research, and see .pdf pages in the returned google list. I read the link, the short description, and choose to open them with ctrl+click -- with the intention that the pdf document will load by the time I finish selecting several links. But when I go to the respective tab, I have to allow the tab and wait more to load the pdf. This is a WASTE OF TIME (slow computer.) Please help me understand:

1. With my use case, how is having pdf-s blocked by default protect me?
2. How will it endanger me if I were to have in Options a special box to tick to allow opening .pdf-s , just like I have the option to allow img and other things?
3. Is there a work-around / hack I could use and I don't know of? Maybe a way to specify regular expressions (not just wild cards)? Thanks.

[w-barath]

This behaviour needs to be optional, since otherwise a site can host a PDF file that you want to view without permitting the domain to run scripts, but the only way to view that PDF it to allow that domain to run scripts.

Yes a PDF is a kind of script. No, it doesn't have the same capabilities as Javascript to scrape the browser for identifying data.

Tying the two together is in fact a reduction of security, because it encourages users to permit a site's Javascript in order to view a PDF, effectively granting that website the ability to scrape the browser, when there's no real need to grant such permission.