The browser maker described the built-in PDF viewer as more secure and safer than proprietary PDF viewing plug-ins, like those installed by Adobe Reader or Foxit Reader. However, several security experts noted that it probably won't be free of vulnerabilities.
"For a number of years there have been several plugins for viewing PDFs within Firefox," Mozilla Engineering Manager Bill Walker and Mozilla Software Engineer Brendan Dahl said Friday in a blog post. "Many of these plugins come with proprietary closed source code that could potentially expose users to security vulnerabilities. PDF viewing plugins also come with extra code to do many things that Firefox already does well with no proprietary code, such as drawing images and text."
Since the viewer uses standard HTML5 APIs (application programming interfaces) it can also run in different browsers and on different platforms, like tablets and mobile phones. A live demo of the viewer running as a Web application is available on the PDF.js website.
"The PDF.js powered viewer in Firefox Beta is the first step to it becoming a fully integrated feature within the release version of Firefox so its benefits can be enjoyed by all Firefox users," the Mozilla software engineers said.
Mozilla did not clarify whether this viewer will be used by default even in cases when a third-party PDF viewing plug-in is installed. The company did not immediately respond to a request for comment.
Security experts believe that the built-in PDF viewer will provide more security for users, but not necessarily because it won't be prone to vulnerabilities as third-party PDF viewer plug-ins are.
Such an implementation might provide more security to the end user because its user base will be smaller compared to that of Adobe Reader and cybercriminals will continue to focus on exploiting the most popular pieces of software, Stefan Tanase, a senior security researcher at antivirus vendor Kaspersky Lab, said via email. "While I am excited to see Firefox giving extra thought to the security of its users, what worries me is that even the technologies on which PDF.js is based can be vulnerable."
This vulnerability is not the exception, but rather the rule, Tanase said. "Similar ones are discovered every year, in mostly every product version and they can all be used by attackers to run code and install software, requiring no user interaction beyond normal browsing."
However, this doesn't mean that it's not prone to vulnerabilities, he said. "If new functionality has been added to the browser or the PDF reader otherwise becomes privileged in the browser, then it may be vulnerable and become a new vector to exploit these vulnerabilities in the browser."
In general, the less code there is on a system, the less exposed it is to potential attacks, Eiram said. Using this built-in PDF viewer component instead of installing a separate a PDF reader application that often includes features many users don't really need and which can be vulnerable, reduces the system's overall attack surface, he said.
Tanase also agrees with this theory. "There's a clear benefit for using the same rendering engine for both Web pages and PDFs which needs to be pointed out: the code base is smaller, therefore the attack surface and potential risk is lowered," he said.
Fortunately, if such vulnerabilities are found, the job of fixing them falls to the browser vendor. Browser makers, especially Mozilla and Google, have a very good track record of managing vulnerabilities and historically have had better updating mechanisms than third-party plug-in vendors, Tanase said.