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.