undefined | Better HN

0 pointsweinzierl8y ago0 comments

> The goal for WASM is to enable browsers to run untrusted code in a trusted environment. Our approach is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent code from inspecting or changing files on the client file system. Also, the intent is to prevent code from using network connections to circumvent file protections or people's expectations of privacy.

> WASM provides the basic technology for loading and authenticating signed code. This enables browsers to run trusted code in a trusted environment.

Sounds familiar? This is straight from 1998 [1](ha!) with JDK replaced by WASM and applet/classes by code;-) I hear you and I hope this is enough for WASM to succeed. Still I don't see the killer argument why I should believe it will.

[1] https://web.archive.org/web/19980214233937/http://java.sun.c...

0 comments

DiThi8y ago

"functionality" in this case means APIs. WASM won't have any APIs that JS doesn't already have. So "conservative" means "just a few APIs", not "just communication with code in an already battle-proven VM". And AFAIK there are no plans for "loading and authenticating signed code" in WASM. It's always untrusted unless you run it with a runtime that provides the privileged APIs (such as node.js). Java always had both unprivileged and privileged APIs in the same place.

j / k navigate · click thread line to collapse

0 pointsweinzierl8y ago0 comments

> WASM provides the basic technology for loading and authenticating signed code. This enables browsers to run trusted code in a trusted environment.

[1] https://web.archive.org/web/19980214233937/http://java.sun.c...

0 comments

DiThi8y ago

j / k navigate · click thread line to collapse