2 ms·
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 ab
by zamadatix 1mo 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 1mo 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 1mo agoThey 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 1mo agoRight, 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.