Hacker News Reader

Comment by eridius | Hacker News Reader

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.

View on HN

Js code is sufficiently dynamic where I wouldn’t be confident in anyone using this defense, even with a debugger open.

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

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

That’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.

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

Maybe the code wraps querySelector and getAttribute for wasm, or similar. Or maybe its underhanded code, designed to do something different than it seems to.

Thats neat, cool, given that, we are at least only as susceptible as we were before.

Wouldn't the network tab still record any network requests from wasm

I would assume so, but if the request is encrypted you wouldn't know what's in it.

Reply on news.ycombinator.com