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?

  • ReK2
    2•4 years ago

    I just dont know why people want to use stupid javascript or fake system apps like electron to act as a “browser” and having a “middle man” taking care of things you should be doing with real system apps… instead of one app calling another app to do something… is removed… easy? yes? but removed… some people should learn to code a programming language and not a scripting language. GO/Rust will do the job for most shit people try to push down our throat because of lazy “programmers” that get scared of doing any real coding with C/Go/Rust/… I mean like why boot a whole OS to just use the browser or browser alike slow applications? may as well just boot into the browser LOL

    • @0xc0ba17
      -1•4 years ago

      I just dont know why people want to use stupid javascript or fake system apps like electron to act as a “browser” and having a “middle man” taking care of things you should be doing with real system apps

      Holy gatekeeping, batman.

      I want to build an app, not spend 6 months learning Qt. That’s why I use Electron. Screw your “real” app, because my existing Electron app is better than your non-existing Rust app.

        • @0xc0ba17
          0•4 years ago

          and I wont reply,

          “lalala can’t hear you”

          Learning isn’t hard your smartass, otherwise I wouldn’t be a developper. I’m not implying that native apps aren’t better, of course they are, but the hard truth is that either I don’t have the time to learn a new GUI framework (because guess what, I want to make fun stuff in my free time, and not pile up unfinished projects), or the client does not have the ressources to develop a native app.

          That’s not an opinion, that’s how it works in the real world. Like it or not, when performance is not a critical factor, people go for the easiest solution because they want to ship a product, and not masturbate on their craft.

          My Electron app implements CodeMirror and currently uses ~120MB of memory. Is it much for a text editor? Certainly, I’m quite conscious about it, but I’m far from the 1GB example from your 2017 article, and I don’t see myself spending eons to write a markdown parser/colorizer/real-time renderer.

  • @some_dude
    1•4 years ago

    Especially if actions that normally require a call to the browser’s API can be compiled into standalone WebAssembly code

    webassembly does not have bindings for web and dom APIs, these have to be called from javascript. So any extension that blocks javascript from using certain APIs will work with webassembly code.

    • @AgreeableLandscapeOP
      1•4 years ago

      For now, but I suspect native WebAssembly websites are coming.