Re:From Asm.js to WebAssembly
by pcwalton on Wednesday June 17, 2015 @03:05PM
(#9734470)
Those language features aren't relevant to Pepper vs. the Web APIs: JavaScript supports integers, tagged unions, and so forth, if you compile a language that supports them down into JS. As for the library features, aside from a few I don't understand/agree with (how is WebGL not equivalent to OpenGL ES, and how is WebGL/Canvas not a low-level rendering API?), a bunch of those are forbidden for security reasons (like raw file access and raw TCP and UDP sockets), so you wouldn't want pages to just have access to them in the manner that a PNaCl-using Chrome extension does anyway.
[ Parent
| on HN ]
Re:From Asm.js to WebAssembly
by JoshTriplett on Wednesday June 17, 2015 @03:12PM
(#9734522)
> a bunch of those are forbidden for security reasons (like raw file access and raw TCP and UDP sockets), so you wouldn't want pages to just have access to them in the manner that a PNaCl-using Chrome extension does anyway.
Sure I do, with explicit permission granted. For instance, consider a web-based VNC client, without needing a server-side WebSocket proxy.
And there are far more where those came from.
Also, the advantage of making low-level web APIs is that any new high-level APIs built on top of them run inside the sandbox, so their implementation is not part of the attack surface.
Considering that people already are installing apps on their smartphones and nod away all the checkboxes
[x] share all my contacts
[x] rummage through my images
[x] tap into microphone and camera at any time
[x] set my house on fire
Ideally they should be designed in a way that those feature unlocks get delayed randomly, so that they always "break" any code relying on those APIs by default. I.e. stuff should still work if the user doesn't give you the key to the city.
Re:From Asm.js to WebAssembly
by smitherfield on Friday June 19, 2015 @02:23PM
(#9746666)
We had this, it was called "Java applets" (also, DirectX), and it sucked.