Half of the websites using WebAssembly use it for malicious purposes | Hacker News Reader

Half of the websites using WebAssembly use it for malicious purposes

zdnet.com

44 pointsvictorbojica29 comments

This is not fundamentally different than the previous generation of JS miners. The root cause is "people who's websites serve miners", not WASM per se.

With the difference that you can turn off JavaScript.

Can you not disable wasm? That seems like an oversight that should be fixed if so.

It's depressing that the web has become such a race-to-the-bottom, but here we are. Maybe we need a WASM permission opt-in like what we have for notifications, geolocation, etc.? It'll be hard to communicate what it means to regular users, but I don't see another solution.

Full opt-in for wasm will become as impractical as disabling JS. What we'll need are better resource-level controls, so you could at least be prompted earlier if a site's using high CPU for prolonged periods. Could even help get devs to take site perf more seriously and stop draining the batteries of every visitor on an unplugged laptop or phone.

> will become as impractical as disabling JS

No, because that's not the same thing:

1) JS opt-in is an advanced setting, not a prompt dialog that appears when a page tries to run it and gets remembered on a site-by-site basis.

2) Until (unless) WASM gets full reign of web APIs, which is a long way off, it will continue to have very sparse legitimate use-cases. Are you trying to play a game, use Photoshop-the-web-app, or use an encrypted messaging service? Click "Yes". Otherwise, it's probably safe to say you don't want whatever-it-is running. It's rare that the average user would want to disable JS on a given site. It's much more likely that they'd want to disable WASM (just like it's much more likely that they'd want to disable geolocation, or push notifications).

What wide and varied legitimate use cases did we honestly expect to see? What wide and varied legitimate uses to we see for JS now?

There admittedly aren't many for "intensive number-crunching that needs to happen in the client even though a server is almost definitely available, and which also can't directly interact with the DOM".

Games and cryptography are the only big ones that come to mind right now (for example, services like ProtonMail that do client-side decryption).

Hopefully the DOM limitation (and general API limitations) will be lifted over time, in which case there could be a huge use-case for client-side rendering which can be a bottleneck right now.

Lifting the API limitations could also allow the web to become truly multi-lingual; you could ditch JS entirely.

But other than the above, you still have the question of "what computation really needs to be done in the web client when you have a server on-hand?" Even in Electron, you have the ability to spin up other processes on the host machine.

I think WebAssembly is super cool but it still needs a killer-app. Ironically, one of the places it's really getting some interesting traction is on the server. It's like a JVM without a garbage collector. I look forward to seeing where that goes.

> What wide and varied legitimate use cases did we honestly expect to see?

For one, I'm currently experimenting with compiling Kaldi to WebAssembly for local (in-browser) speech recognition.

I'm fully behind WASM - I think it will serve as the backbone for the next generation of web apps for a decade or two.

But the downside to its flexibility is that it is far easier to use for nefarious purposes. I don't think that should poison the well for legitimate use-cases though.

ML for resource-intensive apps. Client-side word vectorization would be a nice-to-have -- early classificatiton and sentiment analysis happening client-side opens up a ton of use cases.

What I'm more excited for, is it also lets you write highly-optimized apps which would use less power, and possibly be served in smaller filesizes. This is great for mobile devices. e.g. managing and comparing 128-bit uints is a big headache in JS, so you rarely see UUIDs handled as anything but strings. There are a few optimizations around that, but ultimately it's going to be a lot easier on memory and run faster matching if you can store it directly as 16-bytes. Trivial in rust compiled to wasm, but not worth your time in JS.

There are also still a lot of programs being compiled to windows/osx/linux target binaries, that could run just as well in a browser with wasm. It's easier to picture what you _don't_ run in browser now as a possibility, instead of simply imagining how the current web will look in wasm.

>What wide and varied legitimate use cases did we honestly expect to see?

It's just a bytecode spec, it wasn't created by the mafia or anything. Many people have already used it for porting software to the web, and for math-intensive operations. You can see plenty of such projects by searching HN.

>What wide and varied legitimate uses to we see for JS now?

Are you implying that most JS is currently used for malicious purposes?

I would guess the vast majority of JS is currently used to render content in the browser as part of a frontend framework, or JQuery, which is probably still widely in use in legacy sites. Also for Google Analytics, which I suppose some people might consider malicious. But then half of HN considers javascript illegitimate and malicious by default anyway.

>Are you implying that most JS is currently used for malicious purposes?

I classify most ads as malicious, so yes.

I guess the uMatrix and NoScript will add an option to block/unblock WebAssembly.

    WebAssembly = undefined;

is all you need.

That didn't take long. Anyone know how to disable it in the major browsers?

    WebAssembly = undefined;

inside `run_at` `document_start` extension does it for Chrome.

Disabling JS should disable WebAssembly. Otherwise there is also `javascript.options.wasm` in Firefox.

Emscripten can target non-WASM JavaScript just fine, and the malicious use cases are just as happy to burn your power at any efficiency. Disabling WASM is a knee-jerk reaction and will not protect you. (Disabling all scripting will, as long as no site you whitelist or addon you install gets hacked.)

How's that a solution? The same websites were simply using JS prior to WASM.

And disabling JS is a popular thing on HN, so is asking how to disable WASM really that unexpected or out of the ordinary?

Popular doesn't necessarily imply correct. Modern Single Page Applications rely on JS for everything. Unless HN prefers static documents, simply insisting on an anachronistic expectation of functionality without JS, however righteous, isn't fruitful.

And time and time again, those "Modern" single page applications are utilizing javascript to provide a LOWER quality of product than the previous version. Atlassian spent the last year or so SPAing all of their apps, and every single update is less usable, slower, less discoverable, and uglier than the previous. I would literally be more productive by simply using a 5 year old version of their sites, and changing nothing else.

> Unless HN prefers static documents

Have you looked at HN lately, or read any of the submissions? Shit, we'd go back to using Gopher if possible.

Static sites with a sprinkle of optional JS to enhance usage (votes in HNs case, although inline JS replies would be a good idea as well) is the way to go for most sites.

SPAs are meant for _large applications_, where the majority of functionality derives from JS, and would be cumbersome to manage otherwise. There are very few of these in comparison.

Gopher protocol would be preferred!

We enable JavaScript selectively, and it would need to be the same for WASM. Enabling for everything just to support the rare pages I find it useful is nuts.

Have you considered the inverse, to allow by default, and disallow flagged domains?

There isn't much point to the inverse. You load pages, including all the stuff you don't want, then disallow it. Closing the barn door after the horse has bolted so to speak. You also have to remember to check every site you visit, which nobody is going to do consistently. With disallow by default, it is obvious you need to look because the site isn't working. While I was required to do this for work, I found myself doing it on my personal systems too, because things are in general more pleasant. A surprising amount of sites work just fine for the purposes of browsing, and many more just requiring one or two domains added to the whitelist. Often leaving out large amounts of crap from several ad servers and metrics collectors and video streaming I usually don't want to bother with and popup banners telling me to disable my adblocker and font tweaks because I'm obviously incapable of configuring my browser to be most usable to me and 'tagmanagers' which apparently do absolutely nothing and widget for forms I'm not interested in filling out. I've more than once found enabling JavaScript makes problematic pages worse.

HTML 5 + CSS 3 already provides quite a rich experience, in what visuals are concerned.

WASM is the new ActiveX. People were warned

Reply on news.ycombinator.com