There are several posts on this page touting the security benefits of PDF.js, and it's almost certainly true that PDF.js is more secure than a new pdf implement

There are several posts on this page touting the security benefits of PDF.js, and it's almost certainly true that PDF.js is more secure than a new pdf implementation in C or C++ would have been[1]. In the short term PDF.js makes sense. I think there are longer term considerations here though. Web standards (HTML/CSS) and language (Javascript) were not designed to be used as a compilation target for complex programs. It was meant to be a document platform. PDF.js is fast enough to use (just about) because a massive amount of engineering time has been put into making browsers very performant. That has involved making browsers huge complex beasts that have to be written in low level unsafe languages to achieve acceptable performance[2]. By choosing to use standards that are very complicated, high level and inefficient we have made the implicit choice to require any competitive browser implementation to be highly optimised and low level. That huge pile of very complex low level code has a real security cost. Buffer overflows, dangling pointers, out of bounds reads. These things are common in browsers today[3] and will remain so while browsers have to be implemented in C++ to remain competitive performance wise. We often engage in debates about whether Javascript/the web stack is fast enough to use for various types of software. Performance improvements are treated as an inevitability; "if it isn't fast enough today it will be tomorrow". Similar attitudes hold for missing APIs and functionality. Most people don't seem to really question what it really means for browsers to become more and more performant and more and more complex. The answer seems to be millions of lines of very complicated and low level C++. I'm aware that Rust is one attempt to extricate ourselves from this hole, but that is years away from ever making it into a production browser, if it ever does. Meanwhile standards continue to increase in complexity and browsers continue implement those additions with large amounts of potentially unsafe C++. I don't have any solutions to this, it's too late, we are already committed to browsers being full operating systems. But while we are all running around patting each other on the back over how 'advanced' browsers are now I do think it's worth considering the security price we are paying to make things like PDF.js possible. [1] I think there is a bit of a false dichotomy here though. If performance is acceptable with Javascript then it presumably would have been acceptable with native languages safer than C/C++ (Java, Haskell, Go, Python, etc, take your pick). [2] For example Chrome seems to have basically a virtual memory system implemented in the browser, with pages, heaps and pagination logic so they can use relative 32 bit pointers. ( http://article.gmane.org/gmane.os.openbsd.misc/186107 http://article.gmane.org/gmane.os.openbsd.misc/186107 ) [3] I don't intend to pick on Firefox specifically here since these types of issues exist in all browsers, but here are some recent Firefox issues form the last month or so: CVE-2014-1518 Various memory safety bugs leading to possible code execution. CVE-2014-1523 Out of bounds read leading to crashes when viewing jpeg images. CVE-2014-1524 Buffer overflow when using non-XBL object as XBL leading to possible code execution. CVE-2014-1531 Use after free when resizing images resulting in a potentially exploitable crash.