5 ms·
Since wasm (currently) requires js to interact with the DOM, you could still read the js code to see if it's passing any sensitive data into wasm.
by eridius 9y ago
Since wasm (currently) requires js to interact with the DOM, you could still read the js code to see if it's passing any sensitive data into wasm.
- mattnewton 9y agoJs code is sufficiently dynamic where I wouldn’t be confident in anyone using this defense, even with a debugger open.
- eridius 9y agoThe complaint here is that moving from js to wasm means you can't tell if a package is maliciously exfiltrating your sensitive data. That presupposes that you can read and understand the js code. If your argument here is that you can't be confident in your ability to read and understand the js code, then moving to wasm is no longer a problem.
- bzbarsky 9y agoYou can read the JS code. If it's trying to be sneaky, you _cannot_ understand it, in general. If you think you can, that is false confidence that is best gotten rid of.
- mattnewton 9y agoThat’s probably true, but I do think that the addition of wasm complicated things. Imagine a js bridge that calls window objects by strings built in the wasm blob, or does anytning using eval. Now the wasm code can call anything js can through this bridge.
- eridius 9y agoI suppose that's true, but you can also tell that the JS is trying to obfuscate what it's doing and just generally distrust it at that point.
- mpolichette 9y agoThats neat, cool, given that, we are at least only as susceptible as we were before.
- darepublic 9y agoWouldn't the network tab still record any network requests from wasm
- eridius 9y agoI would assume so, but if the request is encrypted you wouldn't know what's in it.
- fulafel 9y agoMaybe the code wraps querySelector and getAttribute for wasm, or similar. Or maybe its underhanded code, designed to do something different than it seems to.