10 ms·

Can someone explain to me what the difference really is between WASM and older tech like Java Applets, ActiveX, Silverlight and Macromedia Flash, because they d

by junto 2y ago

Can someone explain to me what the difference really is between WASM and older tech like Java Applets, ActiveX, Silverlight and Macromedia Flash, because they don’t really sound much different to me. Maybe I’m just old, but I thought we’d learnt our lesson on running untrusted third party compiled code in a web browser. In all of these cases it’s pitched as improving the customer experience but also conveniently pushes the computational cost from server to client.

palmfacehn 2y ago
There have also been exploits of Chrome's JS sandbox. For me the greatest difference is that WASM is supported by the browser itself. There isn't the same conflict of interest between OS vendors and 3rd party runtime providers.
freetonik 2y ago
Not an answer, but I think it’s unfair to group Flash with the others because it was both the editor/compiler and the player were proprietary. I guess same applies to Silverlight at least.
- Kwpolska 2y ago
  The ActiveX "player" (Internet Explorer) was also proprietary. And I'm not sure if you could get away without proprietary Microsoft tools to develop for it.
tptacek 2y ago
Java Applets and ActiveX had less-mediated (Applets, somewhat; ActiveX, not at all) access to the underlying OS. The "outer platform" of WASM is approximately the Javascript runtime; the "outer platform" of Applets is execve(2).
pajamaboin 2y ago
This article is about WASM on the server so to answer your question it's different because it's not pushing computational cost from the server to the client. It can, but it doesn't in all cases. That's a huge difference. Others have already commented others (better sandboxing, isolation, etc)
- ranger_danger 2y ago
  It's amazing how many people don't actually read the article and just start commenting right away. It's like leaving bad amazon reviews for products you haven't purchased.
tsimionescu 2y ago
Pushing compute to the client is the whole point, and is often a major improvement for the end user, especially in the era in which phones are faster than the supercomputers of the 90s. And otherwise, WASM is different in two ways. For one, browsers have gotten pretty good at running untrusted 3rd party code safely, which Flash or the JVM or IE or.NET were never even slightly adequate for. The other difference is that WASM is designed to allow you to take a program in any language and run it in the user's browser. The techs you mention were all available for a single language, so if you already had a program in, say, Python, you'd have to re-write it in Java or C#, or maybe Scala or F#, to run it as an applet or Silverlight program.
- pjmlp 2y ago
  CLR means Common Language Runtime for a reason. From 2001, "More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET." https://news.microsoft.com/2001/10/22/massive-industry-and-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001/ https://news.microsoft.com/2001/10/22/massive-industry-and-d...
  - tsimionescu 2y ago
    It's not the same thing though. All of these languages have specific constructs for integrating with the CLR, the CLR is not just a compilation target like WASM is. C++/CLR even has a fourth kind of variable compared to base C++ (^, managed references of a type, in addition to the base type, * pointers to the type, and & references to the type). IronPython has not had a GIL since its early days. I'm sure the others have significant differences, but I am less aware of them.
    - pjmlp 2y ago
      As if WebAssembly doesn't impose similar restrictions, with specific kinds of toolchains, and now the whole components mess. This WebAssembly marketing is incredible.
SkiFire13 2y ago
The replacement for those technologies is arguably javascript. WASM is more focused on performance by providing less abstractions and an instruction set closer to assembly (hence the name). The issue with those older technologies was that the runtime itself was a third-party external plugin you had to trust, and they often had various security issues. WASM however is an open standard, so browser manifacturers can directly implement it in browser engines without trusting other third-parties. It is also much more restricted in scope (less abstractions mean less work to optimize them!) which helps reducing the attack surface.
- 0x457 2y ago
  > The replacement for those technologies is arguably javascript. WASM is more focused on performance by providing less abstractions and an instruction set closer to assembly (hence the name). That is nonsense. WASM and JS have the exact same performance boundaries in a browser because the same VM runs them. However, WASM allows you to use languages where it's easier to stay on a "fast-path".
IshKebab 2y ago
ActiveX wasn't sandboxed so it was a security joke. Flash and Silverlight were full custom runtimes that a) only worked with a specific language, and b) didn't integrate well with the existing web platform. WASM fixes all of that.
- tightbookkeeper 2y ago
  But that’s missing a few steps. First they banned all those technologies saying JavaScript was sufficient, then only later made wasm. There never was a wasm vs applet debate.
  - IshKebab 2y ago
    Nobody banned Flash. Apple just sensibly didn't implement it, because it was shit on phones. Android did support Flash and the experience was awful.
    - tightbookkeeper 2y ago
      They sure banned Java Applets. > Nobody banned Flash. What happened first? Chrome dropping support for flash, or flash stopped making updates?
Laremere 2y ago
Wasm has a great benefits over those technologies: - Wasm has verification specification that wasm bytecode must comply to. This verified subset makes security exploits seen in those older technologies outright impossible. Attacks based around misbehaving hardware like heartbleed or rowhammer might still be possible, but you, eg, can't reference memory outside of your wasm's memory by tricking the VM to interpret a number you have as a pointer to memory that doesn't belong to you. - Wasm bytecode is trivial (as it gets) to turn into machine code. So implementations can be smaller and faster than using a VM. - Wasm isn't owned by a specific company, and has an open and well written specification anyone can use. - It has been adopted as a web standard, so no browser extensions are required. As for computation on clients versus serves, that's already true for Javascript. More true in fact, since wasm code can be efficient in ways that are impossible for Javascript.
- kgeist 2y ago
  >Wasm has verification specification. This verified subset makes security exploits seen in those older technologies outright impossible Both Java and .NET verify their bytecode. >Wasm bytecode is trivial (as it gets) to turn into machine code JVM and .NET bytecodes aren't supercomplicated either. Probably the only real differences are: 1) WASM was designed to be more modular and slimmer from the start, while Java and .NET were designed to be fat; currently there are modularization efforts, but it's too late 2) WASM is an open standard from the start and so browser vendors implement it without plugins Other than that, it feels like WASM is a reinvention of what already existed before.
  - flohofwoe 2y ago
    AFAIK the big new thing in WASM is that it enforces 'structured control flow' - so it's a bit more like a high level AST than an assembly-style virtual ISA. Not sure how much of that matters in practice, but AFAIK that was the one important feature that enabled the proper validation of WASM bytecode.
    - iainmerrick 2y ago
pdpi 2y ago
Unlike ActiveX, Silverlight, or Flash, it's an open standard developed by a whole bunch of industry players, and it has multiple different implementations (where Java sits on that spectrum is perhaps a bit fuzzier). That alone puts it heads and shoulders above any of the alternatives. Unlike the JVM, WASM offers linear memory, and no GC by default, which makes it a much better compilation target for a broader range of languages (most common being C and C++ through Emscripten, and Rust). > Maybe I’m just old, but I thought we’d learnt our lesson on running untrusted third party compiled code in a web browser. WASM is bytecode, and I think most implementations share a lot of their runtime with the host JavaScript engine. > In all of these cases it’s pitched as improving the customer experience but also conveniently pushes the computational cost from server to client. The whole industry has swung from fat clients to thin clients and back since time immemorial. The pendulum will keep swinging after this too.
- DougMerritt 2y ago
  > The whole industry has swung from fat clients to thin clients and back since time immemorial. The pendulum will keep swinging after this too. Indeed, graphics pioneer and all-around-genius Ivan Sutherland observed (and named) this back in 1968: "wheel of reincarnation "[coined in a paper by T.H. Myer and I.E. Sutherland On the Design of Display Processors, Comm. ACM, Vol. 11, no. 6, June 1968)] Term used to refer to a well-known effect whereby function in a computing system family is migrated out to special-purpose peripheral hardware for speed, then the peripheral evolves toward more computing power as it does its job, then somebody notices that it is inefficient to support two asymmetrical processors in the architecture and folds the function back into the main CPU, at which point the cycle begins again. "Several iterations of this cycle have been observed in graphics-processor design, and at least one or two in communications and floating-point processors. Also known as the Wheel of Life, the Wheel of Samsara, and other variations of the basic Hindu/Buddhist theological idea. See also blitter." https://www.catb.org/jargon/html/W/wheel-of-reincarnation.html https://www.catb.org/jargon/html/W/wheel-of-reincarnation.ht...
  - justanotherjoe 2y ago
    That was why i stopped using the word 'tech' to refer to these things. You don't suddenly go back to stop using the wheel after a time, or suddenly think that printing press was a bad idea after all. Those are techs. Many of the things we call techs nowadays are just paradigms. And frameworks are defnitely not 'new technology'.
vbezhenar 2y ago
Java and Flash failed to deliver its promise of unbreakable sandbox where one could run anything without risking compromising host. They tried, but their implementations were ridden with vulnerabilities and eventually browsers made them unusable. Other mentioned technologies didn't even promise that, I think. JavaScript did deliver its promise of unbreakable sandbox and nowadays browser runs JavaScript, downloaded from any domain without asking user whether he trusts it or not. WASM builds on JavaScript engine, delivering similar security guarantees. So there's no fundamental difference between WASM and JVM bytecode. There's only practical difference: WASM proved to be secure and JVM did not. So now Google Chrome is secure enough for billions of people to safely run evil WASM without compromising their phones, and you can copy this engine from Google Chrome to server and use this strong sandbox to run scripts from various users, which could share resources. An alternative is to use virtualization. So you can either compile your code to WASM blob and run it in the big WASM server, or you can compile your code to amd64 binary, put it along stripped Linux kernel and run this thing in the VM. There's no clear winner here, I think, for now, there are pros and cons for every approach.
- silvestrov 2y ago
  Most of all the problem with Java Applets was that they were very slow to load and required so many resources that the computer came to a halt. They also took much longer to develop than whatever you could cook up in plain html and javascript.
  - kaba0 2y ago
    Funnily enough, wasm also has the problem of “slow to load”. In that vein, a higher level bytecode would probably result in smaller files to transport. And before someone adds, the JVM also supports loading stuff in a streaming way - one just has to write a streaming class loader, and then the app can start immediately and later on load additional classes.
    - deleted 2y ago
      [deleted]
  - 2y ago
flohofwoe 2y ago
> untrusted third party compiled code in a web browser. WASM makes that safe, and that's the whole point. It doesn't increase the attack surface by much compared to running Javascript code in the browser, while the alternative solutions where directly poking through into the operating system and bypassing any security infrastructure of the browser for running untrusted code.
Starlevel004 2y ago
You can't easily decompile WASM so it makes it harder to block inline ads.
- afiori 2y ago
  You can alreay compile javascript into https://jsfuck.com/ https://jsfuck.com/ and you could also very easily recompile the wasm into js. Obsuscation and transpilation are not new in jsland
mike_hearn 2y ago
Conceptually, they aren't that different. The details do matter though. WASM on its own isn't anything special security-wise. You could modify Java to be as secure or actually more secure just by stripping out features, as the JVM is blocking some kinds of 'internal' security attacks that WASM only has mitigations for. There have been many sandbox escapes for WASM and will be more, for example this very trivial sandbox escape in Chrome: https://microsoftedge.github.io/edgevr/posts/Escaping-the-sandbox-A-bug-that-speaks-for-itself/ https://microsoftedge.github.io/edgevr/posts/Escaping-the-sa... ... is somewhat reminiscent of sandbox escapes that were seen in Java and Flash. But! There are some differences: 1. WASM / JS are minimalist and features get added slowly, only after the browser makers have done a lot of effort on sandboxing. The old assumption that operating system code was secure is mostly no longer held whereas in the Flash/applets/pre-Chrome era, it was. Stuff like the Speech XML exploit is fairly rare, whereas for other attempts they added a lot of features very fast and so there was more surface area for attacks. 2. There is the outer kernel sandbox if the inner sandbox fails. Java/Flash didn't have this option because Windows 9x didn't support kernel sandboxing, even Win2K/XP barely supported it. 3. WASM / JS doesn't assume any kind of code signing, it's pure sandbox all the way.
sebastianconcpt 2y ago
For starters, in that it gives you memory safe bytecodes computation that aren't coupled with one specific language.
afavour 2y ago
The big conceptual difference is that Flash, ActiveX etc allowed code to reach outside of the browser sandbox. WASM remains _inside_ the browser sandbox. Also no corporate overlord control.
deleted 2y ago
[deleted]
dspillett 2y ago
> Can someone explain to me what the difference really is between WASM and older tech like Java Applets, ActiveX, Silverlight and Macromedia Flash As well as the security model differences other are debating, and WASM being an open standard that is easy to implement and under no control from a commercial entity, there is a significant difference in scope. WebAssemply is just the runtime that executes byte-code compiled code efficiently. That's it. No large standard run-time (compile in everything you need), no UI manipulation (message passing to JS is how you affect the DOM, and how you ready DOM status back), etc. It odes one thing (crunch numbers, essentially) and does it well.
BiteCode_dev 2y ago
WASM is a child of the browser community and built on top of existing infra. Java was an outsider trying to get in. The difference is not in the nature of things, but rather who championed it.
bloppe 2y ago
WebAssembly has a few things that set it apart: - The security model (touched on by other comments in this thread) - The Component Model. This is probably the hardest part to wrap your head around, but it's pretty huge. It's based on a generalization of "libraries" (which export things to be consumed) to "worlds" (which can both export and import things from a "host"). Component modules are like a rich wrapper around the simpler core modules. Having this 2-layer architecture allows far more compilers to target WebAssembly (because core modules are more general than JVM classes), while also allowing modules compiled from different ecosystems to interoperate in sophisticated ways. It's deceivingly powerful yet also sounds deceivingly unimpressive at the same time. - It's a W3C standard with a lot of browser buy-in. - Some people really like the text format, because they think it makes Wasm modules "readable". I'm not sold on that part. - Performance and the ISA design are much more advanced than JVM.
- duped 2y ago
  > This is probably the hardest part to wrap your head around, but it's pretty huge. It's just an IDL, IDL's have been around a long time and have been used for COM, Java, .NET, etc.

by junto 2y ago

palmfacehn 2y ago

There have also been exploits of Chrome's JS sandbox. For me the greatest difference is that WASM is supported by the browser itself. There isn't the same conflict of interest between OS vendors and 3rd party runtime providers.

freetonik 2y ago

Not an answer, but I think it’s unfair to group Flash with the others because it was both the editor/compiler and the player were proprietary. I guess same applies to Silverlight at least.

Kwpolska 2y ago
The ActiveX "player" (Internet Explorer) was also proprietary. And I'm not sure if you could get away without proprietary Microsoft tools to develop for it.

tptacek 2y ago

Java Applets and ActiveX had less-mediated (Applets, somewhat; ActiveX, not at all) access to the underlying OS. The "outer platform" of WASM is approximately the Javascript runtime; the "outer platform" of Applets is execve(2).

pajamaboin 2y ago

This article is about WASM on the server so to answer your question it's different because it's not pushing computational cost from the server to the client. It can, but it doesn't in all cases. That's a huge difference. Others have already commented others (better sandboxing, isolation, etc)

ranger_danger 2y ago
It's amazing how many people don't actually read the article and just start commenting right away. It's like leaving bad amazon reviews for products you haven't purchased.

tsimionescu 2y ago

Pushing compute to the client is the whole point, and is often a major improvement for the end user, especially in the era in which phones are faster than the supercomputers of the 90s. And otherwise, WASM is different in two ways. For one, browsers have gotten pretty good at running untrusted 3rd party code safely, which Flash or the JVM or IE or.NET were never even slightly adequate for. The other difference is that WASM is designed to allow you to take a program in any language and run it in the user's browser. The techs you mention were all available for a single language, so if you already had a program in, say, Python, you'd have to re-write it in Java or C#, or maybe Scala or F#, to run it as an applet or Silverlight program.

pjmlp 2y ago
CLR means Common Language Runtime for a reason. From 2001, "More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET." https://news.microsoft.com/2001/10/22/massive-industry-and-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001/ https://news.microsoft.com/2001/10/22/massive-industry-and-d...
- tsimionescu 2y ago
  It's not the same thing though. All of these languages have specific constructs for integrating with the CLR, the CLR is not just a compilation target like WASM is. C++/CLR even has a fourth kind of variable compared to base C++ (^, managed references of a type, in addition to the base type, * pointers to the type, and & references to the type). IronPython has not had a GIL since its early days. I'm sure the others have significant differences, but I am less aware of them.
  - pjmlp 2y ago
    As if WebAssembly doesn't impose similar restrictions, with specific kinds of toolchains, and now the whole components mess. This WebAssembly marketing is incredible.

SkiFire13 2y ago

The replacement for those technologies is arguably javascript. WASM is more focused on performance by providing less abstractions and an instruction set closer to assembly (hence the name). The issue with those older technologies was that the runtime itself was a third-party external plugin you had to trust, and they often had various security issues. WASM however is an open standard, so browser manifacturers can directly implement it in browser engines without trusting other third-parties. It is also much more restricted in scope (less abstractions mean less work to optimize them!) which helps reducing the attack surface.

0x457 2y ago
> The replacement for those technologies is arguably javascript. WASM is more focused on performance by providing less abstractions and an instruction set closer to assembly (hence the name). That is nonsense. WASM and JS have the exact same performance boundaries in a browser because the same VM runs them. However, WASM allows you to use languages where it's easier to stay on a "fast-path".

IshKebab 2y ago

ActiveX wasn't sandboxed so it was a security joke. Flash and Silverlight were full custom runtimes that a) only worked with a specific language, and b) didn't integrate well with the existing web platform. WASM fixes all of that.

tightbookkeeper 2y ago
But that’s missing a few steps. First they banned all those technologies saying JavaScript was sufficient, then only later made wasm. There never was a wasm vs applet debate.
- IshKebab 2y ago
  Nobody banned Flash. Apple just sensibly didn't implement it, because it was shit on phones. Android did support Flash and the experience was awful.
  - tightbookkeeper 2y ago
    They sure banned Java Applets. > Nobody banned Flash. What happened first? Chrome dropping support for flash, or flash stopped making updates?

Laremere 2y ago

Wasm has a great benefits over those technologies: - Wasm has verification specification that wasm bytecode must comply to. This verified subset makes security exploits seen in those older technologies outright impossible. Attacks based around misbehaving hardware like heartbleed or rowhammer might still be possible, but you, eg, can't reference memory outside of your wasm's memory by tricking the VM to interpret a number you have as a pointer to memory that doesn't belong to you. - Wasm bytecode is trivial (as it gets) to turn into machine code. So implementations can be smaller and faster than using a VM. - Wasm isn't owned by a specific company, and has an open and well written specification anyone can use. - It has been adopted as a web standard, so no browser extensions are required. As for computation on clients versus serves, that's already true for Javascript. More true in fact, since wasm code can be efficient in ways that are impossible for Javascript.

kgeist 2y ago
>Wasm has verification specification. This verified subset makes security exploits seen in those older technologies outright impossible Both Java and .NET verify their bytecode. >Wasm bytecode is trivial (as it gets) to turn into machine code JVM and .NET bytecodes aren't supercomplicated either. Probably the only real differences are: 1) WASM was designed to be more modular and slimmer from the start, while Java and .NET were designed to be fat; currently there are modularization efforts, but it's too late 2) WASM is an open standard from the start and so browser vendors implement it without plugins Other than that, it feels like WASM is a reinvention of what already existed before.
- flohofwoe 2y ago
  AFAIK the big new thing in WASM is that it enforces 'structured control flow' - so it's a bit more like a high level AST than an assembly-style virtual ISA. Not sure how much of that matters in practice, but AFAIK that was the one important feature that enabled the proper validation of WASM bytecode.
  - iainmerrick 2y ago

pdpi 2y ago

Unlike ActiveX, Silverlight, or Flash, it's an open standard developed by a whole bunch of industry players, and it has multiple different implementations (where Java sits on that spectrum is perhaps a bit fuzzier). That alone puts it heads and shoulders above any of the alternatives. Unlike the JVM, WASM offers linear memory, and no GC by default, which makes it a much better compilation target for a broader range of languages (most common being C and C++ through Emscripten, and Rust). > Maybe I’m just old, but I thought we’d learnt our lesson on running untrusted third party compiled code in a web browser. WASM is bytecode, and I think most implementations share a lot of their runtime with the host JavaScript engine. > In all of these cases it’s pitched as improving the customer experience but also conveniently pushes the computational cost from server to client. The whole industry has swung from fat clients to thin clients and back since time immemorial. The pendulum will keep swinging after this too.

DougMerritt 2y ago
> The whole industry has swung from fat clients to thin clients and back since time immemorial. The pendulum will keep swinging after this too. Indeed, graphics pioneer and all-around-genius Ivan Sutherland observed (and named) this back in 1968: "wheel of reincarnation "[coined in a paper by T.H. Myer and I.E. Sutherland On the Design of Display Processors, Comm. ACM, Vol. 11, no. 6, June 1968)] Term used to refer to a well-known effect whereby function in a computing system family is migrated out to special-purpose peripheral hardware for speed, then the peripheral evolves toward more computing power as it does its job, then somebody notices that it is inefficient to support two asymmetrical processors in the architecture and folds the function back into the main CPU, at which point the cycle begins again. "Several iterations of this cycle have been observed in graphics-processor design, and at least one or two in communications and floating-point processors. Also known as the Wheel of Life, the Wheel of Samsara, and other variations of the basic Hindu/Buddhist theological idea. See also blitter." https://www.catb.org/jargon/html/W/wheel-of-reincarnation.html https://www.catb.org/jargon/html/W/wheel-of-reincarnation.ht...
- justanotherjoe 2y ago
  That was why i stopped using the word 'tech' to refer to these things. You don't suddenly go back to stop using the wheel after a time, or suddenly think that printing press was a bad idea after all. Those are techs. Many of the things we call techs nowadays are just paradigms. And frameworks are defnitely not 'new technology'.

vbezhenar 2y ago

Java and Flash failed to deliver its promise of unbreakable sandbox where one could run anything without risking compromising host. They tried, but their implementations were ridden with vulnerabilities and eventually browsers made them unusable. Other mentioned technologies didn't even promise that, I think. JavaScript did deliver its promise of unbreakable sandbox and nowadays browser runs JavaScript, downloaded from any domain without asking user whether he trusts it or not. WASM builds on JavaScript engine, delivering similar security guarantees. So there's no fundamental difference between WASM and JVM bytecode. There's only practical difference: WASM proved to be secure and JVM did not. So now Google Chrome is secure enough for billions of people to safely run evil WASM without compromising their phones, and you can copy this engine from Google Chrome to server and use this strong sandbox to run scripts from various users, which could share resources. An alternative is to use virtualization. So you can either compile your code to WASM blob and run it in the big WASM server, or you can compile your code to amd64 binary, put it along stripped Linux kernel and run this thing in the VM. There's no clear winner here, I think, for now, there are pros and cons for every approach.

silvestrov 2y ago
Most of all the problem with Java Applets was that they were very slow to load and required so many resources that the computer came to a halt. They also took much longer to develop than whatever you could cook up in plain html and javascript.
- kaba0 2y ago
  Funnily enough, wasm also has the problem of “slow to load”. In that vein, a higher level bytecode would probably result in smaller files to transport. And before someone adds, the JVM also supports loading stuff in a streaming way - one just has to write a streaming class loader, and then the app can start immediately and later on load additional classes.
  - deleted 2y ago
    [deleted]
- 2y ago

flohofwoe 2y ago

> untrusted third party compiled code in a web browser. WASM makes that safe, and that's the whole point. It doesn't increase the attack surface by much compared to running Javascript code in the browser, while the alternative solutions where directly poking through into the operating system and bypassing any security infrastructure of the browser for running untrusted code.

Starlevel004 2y ago

You can't easily decompile WASM so it makes it harder to block inline ads.

afiori 2y ago
You can alreay compile javascript into https://jsfuck.com/ https://jsfuck.com/ and you could also very easily recompile the wasm into js. Obsuscation and transpilation are not new in jsland

mike_hearn 2y ago

Conceptually, they aren't that different. The details do matter though. WASM on its own isn't anything special security-wise. You could modify Java to be as secure or actually more secure just by stripping out features, as the JVM is blocking some kinds of 'internal' security attacks that WASM only has mitigations for. There have been many sandbox escapes for WASM and will be more, for example this very trivial sandbox escape in Chrome: https://microsoftedge.github.io/edgevr/posts/Escaping-the-sandbox-A-bug-that-speaks-for-itself/ https://microsoftedge.github.io/edgevr/posts/Escaping-the-sa... ... is somewhat reminiscent of sandbox escapes that were seen in Java and Flash. But! There are some differences: 1. WASM / JS are minimalist and features get added slowly, only after the browser makers have done a lot of effort on sandboxing. The old assumption that operating system code was secure is mostly no longer held whereas in the Flash/applets/pre-Chrome era, it was. Stuff like the Speech XML exploit is fairly rare, whereas for other attempts they added a lot of features very fast and so there was more surface area for attacks. 2. There is the outer kernel sandbox if the inner sandbox fails. Java/Flash didn't have this option because Windows 9x didn't support kernel sandboxing, even Win2K/XP barely supported it. 3. WASM / JS doesn't assume any kind of code signing, it's pure sandbox all the way.

sebastianconcpt 2y ago

For starters, in that it gives you memory safe bytecodes computation that aren't coupled with one specific language.

afavour 2y ago

The big conceptual difference is that Flash, ActiveX etc allowed code to reach outside of the browser sandbox. WASM remains _inside_ the browser sandbox. Also no corporate overlord control.

deleted 2y ago

[deleted]

dspillett 2y ago

> Can someone explain to me what the difference really is between WASM and older tech like Java Applets, ActiveX, Silverlight and Macromedia Flash As well as the security model differences other are debating, and WASM being an open standard that is easy to implement and under no control from a commercial entity, there is a significant difference in scope. WebAssemply is just the runtime that executes byte-code compiled code efficiently. That's it. No large standard run-time (compile in everything you need), no UI manipulation (message passing to JS is how you affect the DOM, and how you ready DOM status back), etc. It odes one thing (crunch numbers, essentially) and does it well.

BiteCode_dev 2y ago

WASM is a child of the browser community and built on top of existing infra. Java was an outsider trying to get in. The difference is not in the nature of things, but rather who championed it.

bloppe 2y ago

WebAssembly has a few things that set it apart: - The security model (touched on by other comments in this thread) - The Component Model. This is probably the hardest part to wrap your head around, but it's pretty huge. It's based on a generalization of "libraries" (which export things to be consumed) to "worlds" (which can both export and import things from a "host"). Component modules are like a rich wrapper around the simpler core modules. Having this 2-layer architecture allows far more compilers to target WebAssembly (because core modules are more general than JVM classes), while also allowing modules compiled from different ecosystems to interoperate in sophisticated ways. It's deceivingly powerful yet also sounds deceivingly unimpressive at the same time. - It's a W3C standard with a lot of browser buy-in. - Some people really like the text format, because they think it makes Wasm modules "readable". I'm not sold on that part. - Performance and the ISA design are much more advanced than JVM.

duped 2y ago
> This is probably the hardest part to wrap your head around, but it's pretty huge. It's just an IDL, IDL's have been around a long time and have been used for COM, Java, .NET, etc.