JavaScript is a bad programming language, but one of the benefits of it is that at least it’s high-level and interpreted, so we get at least some idea of what the website is doing, which privacy oriented browser extensions can take advantage of to block code and try and prevent the website from doing something the user doesn’t want it to do. Even things like specific event handlers and APIs can be blocked by extensions. With WebAssembly being a lower level language, could browsers and extensions end up with reduced ability to monitor and block website behavior? Especially if actions that normally require a call to the browser’s API can be compiled into standalone WebAssembly code, potentially making it impossible to completely block. There’s also the question of whether extensions will even be able to affect the WebAssembly code on websites.
Another concern I have is that WebAssembly is relatively new and there doesn’t seem to be any privacy software designed to keep WebAssembly sites in check, compared to the many browser extensions designed for JavaScript sites. This will probably get better with time, but it’s still an issue as of right now.
Should we be worried about any of this?
Javascript already can be heavily obfuscated and I’m not sure if webassembly provides more obfuscation.
Here’s an interesting paper I found on this subject: https://www.virusbulletin.com/virusbulletin/2018/10/dark-side-webassembly/
Most of it’s argument boils down to:
I’m not sure why couldn’t security products inspect
.wasm
file here? If anythingwasm
only environment seems like a more efficient and secure environment as the.wasm
file only needs to be scanned/analyzed once (since it’s being cached and reused) while page source constantly needs to be analyzed for malicious JS code.The thing I wasn’t able to figure out is whether you can deliver binary “undecodable” wasm code to the client? Seems like you can decompile and deobfuscate everything very easily, in fact it looks more readable than obfuscated+minimized js.