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?

  • @wraptile
    1•4 years ago

    I think javascript has already ruined privacy for everyone, can webassembly do worse?

    The problem is the browser — it gives away way to much information about itself making it really easy to fingerprint users. Firefox is trying to address that but unless you go through the trouble of installing and configuring dozen addons you’ll be fingerprinted and tracked.

    The idea that the server can execute code remotely on user’s machine implicitly is just so messed up when you think about it. Imagine going to a shop and having to hand over partial control of your body to Walmart lol

    • @AgreeableLandscapeOP
      2•4 years ago

      Good points, but I feel like WebAssembly could very well make a very bad situation even worse by being harder to analyse the code.

      I normally disable JavaScript for websites if it’s usable without it, and I really hope I can do the same with WebAssembly.

      • @wraptile
        1•4 years ago

        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:

        security products will only see the compiled Wasm file rather than the JavaScript source code

        I’m not sure why couldn’t security products inspect .wasm file here? If anything wasm 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.