4 ms·

The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound se

• Retr0id 7mo ago
  What makes WASM execution riskier than JS?
  • observationist 7mo ago
    Novelty - JS has had more time and effort spent in hardening it, across the browsers, WASM isn't as thoroughly battle-tested, so there will be novel attacks and exploits.
    • Retr0id 7mo ago
      On one hand, yes, new attack surface is new attack surface. But WASM has been in browsers for almost a decade now.
      • lich_king 7mo ago
        Without the bindings this talks about, so it really couldn't do nearly as much.
        • 0x457 7mo ago
          WASM has access to everything JS has via JS in the same sandbox that JS runs in. JS didn't magically become more "secure". Multiple things happened: - ActiveX and Flash got booted from browsers - Browsers got much better sandboxes Essentially limited what untrusted code can run and sandboxed that untrusted code. Before NaCl and PNaCl it was wild west in browsers. The same sandbox runs WASM. It even goes through the same runtime in every browser. It's no different from compiling language of your choice to subset of JavaScript (see asm.js).
    • JoshTriplett 7mo ago
      That would be more true if WebAssembly didn't share so much sandboxing infrastructure with JS. If anything, I'd argue that WebAssembly is a much smaller surface area than JavaScript, and I think that will still be true even when DOM is directly exposed to WebAssemly.
      • lich_king 7mo ago
        I don't think it's "much smaller" once you aim for feature parity (DOM). It might be more regular than an implementation of a higher-level language, but we're not getting rid of JS. By the same token, was Java or Flash more dangerous than JS? On paper, no - all the same, just three virtual machines. But having all three in a browser made things fun back in the early 2000s.
        • cogman10 7mo ago
          It is much smaller. WASM today has no access to anything that isn't given to it from JS. That means that the only possible places to exploit are bugs in the JIT, something that exists as well for JavaScript. Even WASM gets bindings to the DOM, it's surface area is still smaller as Javascript has access to a bunch more APIs that aren't the DOM. For example, WebUSB. And even if WASM gets feature parity with Javascript, it will only be as dangerous as Javascript itself. The main actual risk for WASM would be the host language having memory safety bugs (such as C++). So why was Java and Flash dangerous in the browser (and activex, NaCL). The answer is quite simple. Those VMs had dangerous components in them. Both Java and Flash had the ability to reach out and scribble on a random dll in the operating system or to upload a random file from the user folder. Java relied HEAVILY on the security manager stopping you from doing that, IDK what flash used. Javascript has no such capability (well, at least it didn't when flash and Java were in the browser, IDK about now). For Java, you were running in a full JVM which means a single exploit gave you the power to do whatever the JVM was capable of doing. For Javascript, an exploit on Javascript still bound you to the javascript sandbox. That mostly meant that you might expose information for the current webpage.
          • JoshTriplett 7mo ago
    • embedding-shape 7mo ago
      > Novelty - JS has had more time and effort spent in hardening it Taking this argument to its extreme, does this mean that introducing new technology always decreases technology? Because even if the technology would be more secure, just the fact that it's new makes it less secure in your mind, so then the only favorable move is to never adopt anything new? Supposedly you have to be aware of some inherent weakness in WASM to feel like it isn't worth introducing, otherwise shouldn't we try to adopt more safe and secure technologies?
      • fenykep 7mo ago
        To be fair I think this could be true for certain industries/applications. And while I obviously don't agree with the extreme example, any new technology, especially if it brings a new paradigm has more unknown unknowns which carries potential voulnerabilities.
      • seangrogg 7mo ago
        > Taking this argument to its extreme, does this mean that introducing new technology always decreases technology? I assume you mean "decreases security" by context. And in that case - purely from a security standpoint - generally speaking the answer is yes. This is why security can often be a PITA when you're trying to adopt new things and innovate, meanwhile by default security wants things that have been demonstrated to work well. It's a known catch-22.
    • kccqzy 7mo ago
      There is very significant overlap between browsers’ implementation of JS and WASM. For example in V8, the TurboFan compiler works for both JS and WASM. Compilation aside, all the sandboxing work done on JS apply to WASM too. This isn’t NaCl.
    • skrtskrt 7mo ago
      > JS has had more time and effort spent in hardening it JS required the time and effort because it's a clown-car nightmare of a design from top to bottom. How many person-hours and CPU cycles were spent on papering over and fixing things that never should have existed in the first place? This doesn't even count as a sunk cost fallacy, because the cost is still being paid by everyone who can't even get upgraded to the current "better" version of everything. The sooner JavaScript falls out of favor the better.
• traderj0e 7mo ago
  I only got mad when people wanted to add browser features that clearly break sandboxing like WebUSB. How does wasm break this?
• leptons 7mo ago
  >20 years of serious browser security bugs caused chiefly by JavaScript I think you may be confusing Javascript the language, with browser APIs. Javascript itself is not insecure and hasn't been for a very long time, it's typically the things it interfaces with that cause the security holes. Quite a lot of people still seem to confuse Javascript with the rest of the stuff around it, like DOM, browser APIs, etc.
  • strongpigeon 7mo ago
    That’s not entirely true. Security issues in the JIT of V8 are found every now and then. See https://v8.dev/blog/sandbox https://v8.dev/blog/sandbox
    • leptons 7mo ago
      Javascript isn't more insecure than any other language. Any language can have the same or other security issues.
      • echoangle 7mo ago
        Yeah, but you're not normally going to random websites, downloading an exe and running it. But every website you visit can run JS on your computer (as long as you don't disable JS). So maybe JS should be more secure than any other language.
        • leptons 7mo ago
          >So maybe JS should be more secure than any other language. And it probably is. The sandboxing and security have been around a very long time. If Python were the de-facto browser language, people would also blame it for "security problems", and would be just as paranoid about python running when they visit a website. I know whatever language it would be, people would still be paranoid. I personally don't see any problem with Javascript. If someone knows how to use it, it can be very simple and powerful. Before Javascript ever existed, I was wishing that websites had a scripting language. I didn't really care what it was, but Javascript answered my prayers rather nicely. But it wouldn't really matter what the language is, I'd still be coding for the web browser, and other people would be hating it for whatever reasons.
• spankalee 7mo ago
  Nothing is being ripped out or replaced.
• rishflab 7mo ago
  > The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues. Isnt this what an OS is supposed to do? Mobile operating systems have done a pretty good job of this compared to the desktop OS.
  • jitl 7mo ago
    mobile operating systems review all the code that gets installed on every device
    • rishflab 7mo ago
      Security does not depend on code review. They have stronger sandboxing and have granular permissions that the user must allow. My point is running untrusted code securely should be the operating systems job. It is possible to do this at the operating system level, a browser is not required. The problem is the security model for desktop operating systems is ancient and has not kept up with today's requirements.
  • lich_king 7mo ago
    Mobile OSes don't allow random people to run code on your device. They allow you to install software you want and sort-of trust, which is conceptually close to the desktop model. There are some safeguards on top of that, but the primary line of defense is that cheap-pillz.virus-basket.ru can't actually execute anything on your device.
    • pjmlp 7mo ago
      Desktop model at least on Apple, Google and Microsoft platforms is slowly adopting similar security models, boiling water and frogs kind of approach.
• scuff3d 7mo ago
  It's worth it if it gets rid of JavaScript
  • silon42 7mo ago
    "out of the frying pan into the fire"... I'd like to avoid wasm too...
    • scuff3d 7mo ago
      To each their own. Anything that frees people from the misery of JavaScript and front end frameworks is a good thing in my book.
• mendyberger 7mo ago
  Wasm is safer since it has a much smaller attack surface.
• easterncalculus 7mo ago
  0-days mostly got expensive from compiler optimizations and other security guarantees that carry over to webassembly, like ASLR and pointer authentication, as well as sandboxes and multi-process architectures. It's not all thrown away here. Browsers are millions of lines of code, the amount of UAFs, overflows, etc so far is not the bottleneck.