6 ms·

> 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 We

> 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).

zamadatix 9d ago
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.
- swiftcoder 9d ago
  > 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.
  - zamadatix 9d ago
    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.
    - swiftcoder 9d ago
      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.

zamadatix 9d ago

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.

swiftcoder 9d ago
> 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.
- zamadatix 9d ago
  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.
  - swiftcoder 9d ago
    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.