What's the long term? We're not going give up on PDFs anytime soon, and having a JavaScript-based viewer will make people who just want to consume PDFs much more secure. One less vector of attack.
>It was meant to be a document platform.
SO WHAT? Computers were never meant to be carried around in your pocket, the internet wasn't designed to propagate kitten memes, and Columbus never meant to land in America, yet here we are.
>That has involved making browsers huge complex beasts that have to be written in low level unsafe languages to achieve acceptable performance
As opposed to which safe languages? Java? .NET?
>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.
And what was the security price for running standalone programs to read PDFs? What's the security price for ActiveX, Flash, Silverlight, Java applets?
The long term is a platform that can feasibly be implemented in higher level, safer languages and still give acceptable performance. We sacrificed that when we decided to put millions of dollars of resources into making web standards run faster instead of creating something new. What we did was probably the 'easier' route at the time, but there is a cost.
>SO WHAT?
Go and browse the source code of one of the main browsers. The cost of the complexity of web standards is plain to see in the ridiculous lengths browsers have to go to if they want to achieve decent performance. I gave you a list of recent security holes. The browser you are using right now almost certainly contains undiscovered buffer overflows, use after free and similar memory safety bugs. It's not just that we have created a situation where we are using big piles of unsafe code, it's that we are trapping ourselves into relying on this code for the foreseeable future because we are building a platform out of it and have made the specification of that platform so baroque that currently only C or C++ is flexible and low level enough for all the crazy performance hacks required.
Your argument seems to boil down to 'anything can be anything if we just want it hard enough', which might be true to an extent, but it does come with real costs, which was my point.
>As opposed to which safe languages? Java? .NET?
.NET isn't a language, but assuming you meant C#, then yes those are safer than C or C++. I gave you CVEs for various remote execution vulnerabilities in Firefox in just the last few weeks alone that would not have been possible in memory safe languages.
>And what was the security price for running standalone programs to read PDFs?
A web browser is a standalone program that reads PDFs. If it can be done 'safely' in Javascript in a web browser then it could be done in other memory safe languages as a standalone program. To answer your question though, the number of security vulnerabilities in the unsafe C code I generally use to view PDFs is quite small compared to the number of vulnerabilities in web browsers. Not surprising since browsers are orders of magnitude larger. I don't know why you want to make that comparison since it's not particularly meaningful.
>What's the security price for ActiveX, Flash, Silverlight, Java applets?
You seem to just be listing technologies that are unfashionable among the web developer community. The technologies you listed all (as far as I know) had implementations written in C or C++, for performance reasons, in an era when desktop computers were far slower than even phones are today. The fact that they all had bad security records really just reenforces my point that we shouldn't be writing platforms for running remote software in C or C++ (or at least, it should be a heavily audited core with most of the implementation in something safer).
Additionally, you can't really compare the Java applet situation where Oracle clearly don't give a shit about patching in a timely manner with web browsers that are automatically updated nearly weekly by teams that take security very seriously. The Java applets security situation is what browsers would be like if they didn't have very well resourced hyper vigilant teams trying to keep them patched.
>In the short term PDF.js makes sense.
What's the long term? We're not going give up on PDFs anytime soon, and having a JavaScript-based viewer will make people who just want to consume PDFs much more secure. One less vector of attack.
>It was meant to be a document platform.
SO WHAT? Computers were never meant to be carried around in your pocket, the internet wasn't designed to propagate kitten memes, and Columbus never meant to land in America, yet here we are.
>That has involved making browsers huge complex beasts that have to be written in low level unsafe languages to achieve acceptable performance
As opposed to which safe languages? Java? .NET?
>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.
And what was the security price for running standalone programs to read PDFs? What's the security price for ActiveX, Flash, Silverlight, Java applets?