I wish webassembly was already here. I honestly can't wait for more language choice for targeting the browser DOM.
I believe this will bring a revolution in client side apps on the browser. Ultimately fulfilling the goal Java aimed for, but never succeeded at reaching.
Somehow, I think we'll regret this. Running low-level programs in the browser hasn't gone well in the past.
We got rid of Flash. We got rid of Java applets. Now this. Especially since the use cases are weak. Even WebGL doesn't get used much. Yes, you can do (cool thing) in the browser. But that will be rare.
There were definitely major problems with Flash and Java. WebAssembly has learned from those, though:
* WebAssembly is an open standard, unlike Flash
* WebAssembly has multiple compatible open source implementations, unlike Flash (and Java, back in the day)
* WebAssembly is optimized for very fast startup, unlike Java
* WebAssembly is designed to integrate with JavaScript and the web in a proper way, unlike Flash and Java
* WebAssembly is designed to have the same security model as JavaScript and in fact to reuse existing hardened code as much as possible, minimizing the security risk.
Not that WebAssembly is perfect, nothing is, but it's aimed to fix the huge issues that previous related technologies had.
And the use cases are very important: things like games, photo editing, etc., all can benefit from high-speed execution of code on the web. WebAssembly is a response to developer requests.
It certainly isn't integration with JavaScript that held Java back, as Java and JavaScript are about equally old. If I have to believe Wikipedia, both are from May 23, 1995, but I don't trust that date for JavaScript, as Wikipedia also says JavaScript was designed in two weeks in May 1995. Internet time is fast, but not that fast.
For me that is the believable part; it's easy to hack together something JavaScript-like using lex and yacc and also probably not too hard to bolt it onto your own browser. It would be reasonably bug-free, too, as there was no standard to test it against.
I do find it hard to believe that Netscape managed to decide this was a (minimal) viable product, produce a press release, and present it to the world in the remaining (at most 21, including Memorial Day, but according to Wikipedia at most 13) days in May.
On the other hand, Netscape may have heard rumors about Sun announcing Java (quite possible if Sun wanted to have a Netscape plugin to demo at launch) and decided they had to have something on the same day. I can't find that on the web, though.
I think you're right that being "high"/"low" level is basically irrelevant for theoretical security; only the primitive IO instructions matter, and if some combination of those instructions is a security risk, then it doesn't really matter how that combination comes about (via functional programming and monads, via OO service architectures, via actors, via bit-twiddling and gotos, etc.).
On the other hand, I can imagine "low level" (i.e. low abstraction) programs having a harder time implementing their own security models; e.g. trying to segregate third-party code, etc. simply because it's harder to reason at a level so much removed from your application domain. Having security-conscious higher level languages compile into WA would alleviate this though.
It tends to be the opposite. Low level is far easier to secure. Far easier to make a VM guaranteed to be secure : you only have to prove a few instructions don't result in privilege escalation and you're done.
What really matters is contact points between the inside and the outside of the security container, and how complex they are. The fewer and simpler, the better.
But, large performance advantages can be had by violating these rules.
The security issues with things like Flash and Java is that they increase the attack surface drastically. Furthermore, they come from different companies from the web browser, and often with their own updating mechanisms.
Even if your browser developers are professional and strict about security and update rollouts, the plugin developers of plugin X might be pretty lax and slow to roll out a fix when there is an exploit dropped. Even if you shame them into getting better, the problem can start over with plugin Y instead, and so on.
It's entirely possible that WebAssembly will also increase the attack surface, but I seriously doubt it will be at the same scope as the third party plugin providers. It will be developed by the same developers who developed the JavaScript engine of the browser.
14 comments
[ 3.1 ms ] story [ 28.6 ms ] threadI believe this will bring a revolution in client side apps on the browser. Ultimately fulfilling the goal Java aimed for, but never succeeded at reaching.
https://github.com/WebAssembly/design/blob/master/GC.md
A VM + Canvas is the primary use case, from what I had gathered.
Has the first WebAssembly exploit come out yet?
* WebAssembly is an open standard, unlike Flash
* WebAssembly has multiple compatible open source implementations, unlike Flash (and Java, back in the day)
* WebAssembly is optimized for very fast startup, unlike Java
* WebAssembly is designed to integrate with JavaScript and the web in a proper way, unlike Flash and Java
* WebAssembly is designed to have the same security model as JavaScript and in fact to reuse existing hardened code as much as possible, minimizing the security risk.
Not that WebAssembly is perfect, nothing is, but it's aimed to fix the huge issues that previous related technologies had.
And the use cases are very important: things like games, photo editing, etc., all can benefit from high-speed execution of code on the web. WebAssembly is a response to developer requests.
JavaScript seems to have shipped as LiveScript in September 1995, but https://en.m.wikipedia.org/wiki/JavaScript#Version_history also has March 1996 as date for the first version. Java seems to have been shown to the world in beta form in May 1995, with the first JDK available on January 23, 1996 (https://en.m.wikipedia.org/wiki/Java_version_history), so Java seems a tad older than JavaScript.
I think a few important 'features of WebAssembly', compared to Java are that WebAssembly is going to come out at a time when:
* machines are cheap and fast enough.
* bandwidth is cheap and plenty enough.
* the world knows you need open standards to conquer the world (or, cynically, that getting hold of data is the primary objective nowadays)
1. https://www.w3.org/community/webed/wiki/A_Short_History_of_J...
I do find it hard to believe that Netscape managed to decide this was a (minimal) viable product, produce a press release, and present it to the world in the remaining (at most 21, including Memorial Day, but according to Wikipedia at most 13) days in May.
On the other hand, Netscape may have heard rumors about Sun announcing Java (quite possible if Sun wanted to have a Netscape plugin to demo at launch) and decided they had to have something on the same day. I can't find that on the web, though.
EDIT: http://www2.ldc.lu.se/temadag95/javascript.txt and http://www.phase3.net/sun-announces-java-at-sunworld/ seem to show that the May 23 date in Wikipedia is correct for Java, but incorrect for JavaScript. That date should be December 4, 1995.
Is there any security sense in which this is lower level than javascript (asm.js)?
On the other hand, I can imagine "low level" (i.e. low abstraction) programs having a harder time implementing their own security models; e.g. trying to segregate third-party code, etc. simply because it's harder to reason at a level so much removed from your application domain. Having security-conscious higher level languages compile into WA would alleviate this though.
What really matters is contact points between the inside and the outside of the security container, and how complex they are. The fewer and simpler, the better.
But, large performance advantages can be had by violating these rules.
Even if your browser developers are professional and strict about security and update rollouts, the plugin developers of plugin X might be pretty lax and slow to roll out a fix when there is an exploit dropped. Even if you shame them into getting better, the problem can start over with plugin Y instead, and so on.
It's entirely possible that WebAssembly will also increase the attack surface, but I seriously doubt it will be at the same scope as the third party plugin providers. It will be developed by the same developers who developed the JavaScript engine of the browser.