The second half of this post chronicles the author's Herculean efforts to make everything work well in the cases you describe.

> One of the big things that blocked this shipping for so long was not having an escape hatch of some kind to allow clients that disable WebAssembly by policy to get through the gate. [...] This combination of factors means that there would need to be another implementation of the proof of work code in JavaScript that would actually execute the number crunching.

Thanks. You're right; it was a very thorough article and I trailed off about halfway through. I still say there are many improper uses of Webassembly out there, but I credit the developer for a highly thoughtful approach to the project. I really wonder if Cloudflare et al. does as much due diligence?

> because I dislike things running in the background without my knowledge

Point of order: WASM doesn't let things run in the background. To do that you need WebWorkers (a javascript feature, not WASM-specific).

Two different kinds of "background". GP is talking about what indications they get a page is running arbitrary code as they load it, (some of) web workers is about persisting running that code after it's loaded. It can be in the "background" for both or neither, depending on the context, and both meanings are valid.

> GP is talking about what indications they get a page is running arbitrary code as they load it

I mean, you get the same indicators as when the page runs arbitrary Javascript on load? WASM assembly may be (slightly) harder to read than typescript compiled to JS, but the source is all there, it calls the same APIs, etc.

They are not saying:

  js on any site -> okay, I enable permanently
  wasm on any site -> not okay, will never enable

But rather:

  js disabled -> I often get a fallback warning message letting me know a site needs it to work
  wasm disabled -> I'd like a similar kind of message

So they don't have to guess at the cause(s). I.e. they don't mind Anubis moved to WASM over JS in itself, they mind there is no fallback warning message letting them know that's the missing requirement. In general, I agree with the problem trend. Most users get pushed along auto-update tracks these days and so fallback behavior has often fallen out of mind with the newer technologies even though it's so easy to implement. That's almost expected with "normal" pages and the lack of time to put into them but when you push something which will affect many sites it's probably worth the reminder for a fallback message.

Right, but the base assumption here is unfounded. Disabling WASM isn't in any way equivalent to disabling Javascript - you are just kneecapping your own browser performance, rather than closing off a large attack surface.

It's amusing (although disheartening to me as someone who builds online games) that wasm is now being treated like a flash plugin by sysadmins. You're not entirely wrong, but it's just funny to me that we took a full ten years to get back to roughly the same place. Now with Ruffle running Flash in wasm, no less! We build shit that doesn't work in the DOM, search engines hate it, walled gardens try to block it, admins fear it, they shut it down and the whole thing starts over.

I don't mean to be rude, but please search "wasm2js" in the article.

Some times it's okay to mean it.

This is not one of those times.

Isn't the WASM attack surface absolute minuscule when compared to JS? Do you also disable web workers?

I disable workers.

I forgot to do so on my phone. I noticed Firefox had slowed to a friggeb crawl when opening pages. Disabling web workers fixed that.

I haven't disabled web workers, but am playing with the concept. T-Mobile's payment portal screams and then bans my IP (something like that) if try. I have disabled service workers globally, and so far no fallout.

"I disable things and expect others to do things for me, in their own time, without being paid, to bring solutions to my paranoia"

You do see how selfish it is, right? While the author did introduce such a solution, it's such a massive waste of time.

I really don't see why you'd disable WebAssembly and allow JavaScript instead. Expecting developers to make a fallback for a baseline-supported feature for any reason but backwards compatibility with runtimes that do not so support WASM is extremely silly.

I also have JS disabled in Firefox on my phone. It's on by default on my laptop, as I apparently visit different sites when my butt is planted in a chair.

My wish is actually for the days of NPAPI where Webassembly would be just another plugin (like Flash) and browsers clung to mainly HTML, JS, and CSS. Then developers wouldn't be quite so keen to rely on it and the web would be much less bloated. Yes, those days are long gone... As a tradeoff, I'd settle for a simple toolbar icon that lit up when Webassembly is running, and/or a high level UI (just like Location, Camera, and Microphone) so I can enable it for just those sites that need it. I tried selling Mozilla on the idea once but they apparently weren't interested.

Baselines aren't entirely universal. I remember the days when the Mozilla (or early Firefox) browser was the only viable web client for Linux, but some sites still opted to run behind ActiveX. Today I don't think you'll find a Haiku or Amiga browser with Webassembly support, nor Firefox for Linux on IBM Power motherboards. It's easy to forget that just because most any 'nix or BSD OS has a plethora of choices, that others aren't still dealing with the "ActiveX" situation and feeling like everybody's out to get them.