Live data from Hacker News

Making WebAssembly a first-class language on the Web

hacks.mozilla.org

91–100 of 287 posts

Re: Making WebAssembly a first-class language on the Web

#91

The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues. And it turned out that this was insane: we endured 20 years of serious browser security bugs caused chiefly by JavaScript. I'm not saying it wasn't worth it, but it was also crazy. And now that we're getting close to have the right design princi…

>20 years of serious browser security bugs caused chiefly by JavaScript

I think you may be confusing Javascript the language, with browser APIs. Javascript itself is not insecure and hasn't been for a very long time, it's typically the things it interfaces with that cause the security holes. Quite a lot of people still seem to confuse Javascript with the rest of the stuff around it, like DOM, browser APIs, etc.

Re: Making WebAssembly a first-class language on the Web

#92

[flagged]

Another example of a top comment that was definitely written by an LLM.

And to be clear, style isn't the only problem. This comment can be summarized as "WebAssembly can now interact with the DOM directly instead of through JavaScript, making it the better choice for more types of problems". One sentence instead of a paragraph of cliches ("...change how people think about this...chicken-and-egg loop..."), uncanny phrases ("...the hot-path optimization niche"), and inaccurate claims ("...the only viable use cases were compute-heavy workloads like codecs and crypto").

(For anyone who doesn't believe me, check the user's comment history)

Re: Making WebAssembly a first-class language on the Web

#93
post #91

The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues. And it turned out that this was insane: we endured 20 years of serious browser security bugs caused chiefly by JavaScript. I'm not saying it wasn't worth it, but it was also crazy. And now that we're getting close to have the right design princi…

>20 years of serious browser security bugs caused chiefly by JavaScript I think you may be confusing Javascript the language, with browser APIs. Javascript itself is not insecure and hasn't been for a very long time, it's typically the things it interfaces with that cause the security holes. Quite a lot of people still seem to confuse Javascript with the rest of the stuff around it, like DOM, browser APIs, etc.

That’s not entirely true. Security issues in the JIT of V8 are found every now and then. See https://v8.dev/blog/sandbox

Re: Making WebAssembly a first-class language on the Web

#94

I'd really like to be able to run _any_ language in the browser. WASM is a great first step.

Internet Explorer used to support any language that Windows Script Host could run. By default, that was JScript and VBScript, but there were third-party engines for Python, Perl, Ruby, Lua, and many others.

Possibly disabled now as they announced VBScript would be disabled in 2019.

Re: Making WebAssembly a first-class language on the Web

#95

[flagged]

Generated comments are not welcome here. Please respect the guidelines of the community.

https://news.ycombinator.com/newsguidelines.html#generated

>Don't post generated comments or AI-edited comments. HN is for conversation between humans.

Re: Making WebAssembly a first-class language on the Web

#96

[flagged]

Another example of a top comment that was definitely written by an LLM. And to be clear, style isn't the only problem. This comment can be summarized as "WebAssembly can now interact with the DOM directly instead of through JavaScript, making it the better choice for more types of problems". One sentence instead of a paragraph of cliches ("...change how people think about this...chicken-and-egg loop..."), uncanny phr…

Woah, you're right. The account was created a day ago and writes walls of text everywhere (sometimes multiple on the same thread!)

Re: Making WebAssembly a first-class language on the Web

#97
The phrase "first-class" matters here because most developers do not reject a platform over peak performance, they reject it over friction. If the happy path still requires language-specific glue, generated shims, and a mental model of two runtimes, then WebAssembly remains something you reach for only when the pain is already extreme.

What would really change perception is not just better benchmarks, but making the boring path easy: compile with the normal toolchain, import a Web API naturally, and not have to become a part-time binding engineer to build an ordinary web app.

Re: Making WebAssembly a first-class language on the Web

#98

[flagged]

Another example of a top comment that was definitely written by an LLM. And to be clear, style isn't the only problem. This comment can be summarized as "WebAssembly can now interact with the DOM directly instead of through JavaScript, making it the better choice for more types of problems". One sentence instead of a paragraph of cliches ("...change how people think about this...chicken-and-egg loop..."), uncanny phr…

What do you think is the incentive to LLM post on HN (or any site?)

Re: Making WebAssembly a first-class language on the Web

#99

Earlier quoted context omitted.

That would be more true if WebAssembly didn't share so much sandboxing infrastructure with JS. If anything, I'd argue that WebAssembly is a much smaller surface area than JavaScript, and I think that will still be true even when DOM is directly exposed to WebAssemly.

I don't think it's "much smaller" once you aim for feature parity (DOM). It might be more regular than an implementation of a higher-level language, but we're not getting rid of JS. By the same token, was Java or Flash more dangerous than JS? On paper, no - all the same, just three virtual machines. But having all three in a browser made things fun back in the early 2000s.

It is much smaller.

WASM today has no access to anything that isn't given to it from JS. That means that the only possible places to exploit are bugs in the JIT, something that exists as well for JavaScript.

Even WASM gets bindings to the DOM, it's surface area is still smaller as Javascript has access to a bunch more APIs that aren't the DOM. For example, WebUSB.

And even if WASM gets feature parity with Javascript, it will only be as dangerous as Javascript itself. The main actual risk for WASM would be the host language having memory safety bugs (such as C++).

So why was Java and Flash dangerous in the browser (and activex, NaCL).

The answer is quite simple. Those VMs had dangerous components in them. Both Java and Flash had the ability to reach out and scribble on a random dll in the operating system or to upload a random file from the user folder. Java relied HEAVILY on the security manager stopping you from doing that, IDK what flash used. Javascript has no such capability (well, at least it didn't when flash and Java were in the browser, IDK about now). For Java, you were running in a full JVM which means a single exploit gave you the power to do whatever the JVM was capable of doing. For Javascript, an exploit on Javascript still bound you to the javascript sandbox. That mostly meant that you might expose information for the current webpage.

Re: Making WebAssembly a first-class language on the Web

#100
post #89

Earlier quoted context omitted.

What about obfuscated WASM blobs? At least obfuscated JS is still basically source code being interpreted, with WASM we will be running proprietary obfuscated binaries in the browser.

I'd rather deal with an obfuscated WASM blob than obfuscated JS.

Why is that? With obfuscated JS you can instantly create ASTs, easily patch and preview the results. We have codemodding tools for mass patching and analysis. With WASM, you can theoretically have a future anti-tamper corporation with a solution to actively obfuscate binaries and antagonize reverse engineers, like we have today with desktop binaries.
Post reply on HN