13 ms·

WebAssembly Interface Types: Interoperate with All the Things

324 points by skellertor 7y ago

gyre007 7y ago
Oh, this is wonderful. Getting closer to that multilang WASM world.
duxup 7y ago
I'm gonna go out on a limb here and expose my n00bishness, and honestly a lot of that article has my head spinning as I google a lot of terms ;) I've only done web development for a year now and I've seen some cool WebAssembly demos but mostly those are demos of various frameworks (or no framework) reusing random WebAssembly components. It's cool, but I'm missing from a large web application stance how WebAssembly is supposed to work, specifically when it comes to stuff like you see in some frameworks with state management across components and etc. Is there an example of that?
- vcarl 7y ago
  Web assembly is generally an optimization, not an app alternative. Think of it the way you would the C bindings Node.js has. If you've got a compute-heavy code path, writing it in C (or Rust etc) and shipping it as web assembly could be a dramatic perf improvement, but there's not really a substantive benefit to writing your entire app with it.
  - petters 7y ago
    Another benefit I suppose is that you can choose from many more languages. Whether that is substantive or not depends on the person, I guess.
  - weberc2 7y ago
    That's a use case, but there are many others, as the article mentions, like lightweight isolation for server side apps or writing your frontend app in a different language (not pragmatic today, but could be in the future).
  - opencl 7y ago
    Another benefit is initial page load times, if your page has a lot of JS it can take a pretty significant amount of time to parse it. i.e. Figma said it reduced page load times by a factor of 3, though they were using WASM to replace existing asm.js code. https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
  - asdkhadsj 7y ago
    > but there's not really a substantive benefit to writing your entire app with it. Amendment: Perhaps it's debatable what "substantive benefit" would be, but writing the whole app in it is a huge benefit if you really want to do that. That is to say, for years people wanted to write Web UI stuff in various languages, this also allows for that. So while the concrete performance boost may not be meaningful in writing an entire web app in C, Rust, Go, Python or w/e - to the developer happiness the boost may be huge for those devs that want it.
    - vcarl 7y ago
      Well, you still can't do that—WASM doesn't have DOM bindings, you'd still have to ship out to JS. I believe that's a goal, so yes eventually that could be a benefit, but not at the moment.
      - asdkhadsj 7y ago
        Fwiw, you can - just perhaps with not pure WASM and perf. My next app I'm planning on using a Rust WASM DOM framework, and I know there are some in Go as well. This is primarily for developer UX.
      - pjmlp 7y ago
        DOM bindings are kind of irrelevant when one has WebGL. One example among many ramping up https://platform.uno/ https://platform.uno/
        icebraining 7y ago
        I looked into their WebAssembly demo, but it doesn't seem to use WebGL, just a regular DOM (with an ungodly number of elements).
        pjmlp 7y ago
        That was just an example, maybe not the best one. I should just have linked something done in Unity instead.
- Juliennng 7y ago
  Maybe that article can help about real world use case : https://tech.ebayinc.com/engineering/webassembly-at-ebay-a-real-world-use-case/ https://tech.ebayinc.com/engineering/webassembly-at-ebay-a-r...
  - duxup 7y ago
    Thank you.
lachlan-sneff 7y ago
So this is what they've been up to! How well will this interact with the upcoming (hopefully before the heatdeath of the universe) rich gc types extension?
- sunfish 7y ago
  Interface types will make it easy for two modules to interface with each other, regardless of whether both sides use GC, just one side does, or neither side does. And even within GC types, different languages have different ways of representing strings, and Interface Types can allow them to talk to each other.
hackcasual 7y ago
Glad to see this being worked on. The difference between a heap vs. runtime managed object is a huge perf gap for tightly interoperating JS and WASM. At my company, we built a specific object representation that would allow zero copy, through array buffer sharing, views of C++ data from Javascript. Sounds very similar to this.
- ptx 7y ago
  I got the impression from the article that it will always copy data (e.g. strings) between wasm modules. Did I misread it?
syrusakbary 7y ago
Super happy to see WebAssembly Interface Types in development! At Wasmer (disclaimer, I'm the founder!) we've been creating integrations with a lot different languages (C, C++, Rust, Python, Ruby, PHP, C# and R) and we agree that this is a pain point and an important problem to solve. We're excited that Mozilla is also pushing this forward. If you want to start using WebAssembly anywhere: https://wasmer.io/ https://wasmer.io/ Keep up the good work! Let's bring WebAssembly everywhere!
- jedisct1 7y ago
  Is this going to replace wasmer's WebAssembly interfaces? As a library implementer, I'm a bit lost about how to expose functions from a wasm module to the outside world. wasmer's interfaces have the advantage of being very simple to write. But they are not very expressive. WebIDL is horrible, albeit more expressive. At the same time, I feel like this is not enough. My experience with libsodium.js, one of the first library exposing wasm (and previously asm.js) to other environments, has been that IDLs simply exposing function interfaces are not good enough. For example, C functions returning 0 or -1 to indicate an error or not, would not be idiomatic at all if exposed that way in Scala, Javascript or Python. We want these to raise an exception instead. Also, we need ways to preallocate buffers, check their size, etc. in order to make things appear more idiomatic. In libsodium.js, the description language for the WebAssembly <-> JS glue is JSON-based. It describes the input and output types, but also their constraints, and how to interpret the output. That was necessary, and if more languages are targeted, this is even more necessary. I feel like WebIDL is both complex, and insufficient. Another thing that I don't necessarily get is why such a description language was designed specifically for WebAssembly. Instead, we could have (yet another) way to describe APIs and how to encode that description. That description can then be included in ELF libraries, in Java objects, in WebAssembly modules, whatever. You know, like, what debuggers already use.
- erlend_sh 7y ago
  We are exploring using Wasmer as a scripting/modding platform in the Amethyst game engine: https://github.com/amethyst/amethyst/pull/1892 https://github.com/amethyst/amethyst/pull/1892
the_duke 7y ago
I'm very happy to see the WebIDL proposal replaced with something generalized. The article brings up an interesting point: Webassembly really could enable seamless cross-language integration in the future. Writing a project in Rust, but really want to use that popular face detector written in Python? And maybe the niche language tokenizer written in PHP? And sprinkle ffmpeg on top, without the hassle of target-compatible compilation and worrying about use after free vulnerabilities? No problem use one of the many WASM runtimes popping up (like [1], [2]) and combine all those libraries by using their pre-compiled WASM packages distributed on a package repo like WAPM [2], with auto-generated bindings that provide a decent API from your host language. Sounds too good to be true? Probably, and there are plenty of issues to solve. But it sounds like a future where we could prevent a lot of the re-writes and duplication across the open source world by just tapping into the ecosystems of other languages. [1] https://wapm.io/ https://wapm.io/ [2] https://github.com/CraneStation/wasmtime https://github.com/CraneStation/wasmtime [2] https://wapm.io/ https://wapm.io/
- wahern 7y ago
  JVM (Java), Parrot (Perl 6 VM) and CLR (C#) shipped easy, multi-language environments over a decade ago. For some definitions of "easy" and "multi-language". Different programming languages exist for many reasons, only one of which is syntax. Many of these reasons relate to data structures and runtime control flow. WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. (Spoiler: they didn't, and WASM won't.) At best you'll get a Rust'ish WASM, Python'ish WASM, PHP'ish WASM, etc. And all of those will feel like a cousin to JavaScript, just as anything on the JVM feels similar to Java, on Parrot feels similar to Perl 6, and on the CLR feels similar to C#. WASM's choice of data structures, control flow, and data representations will be strongly influenced by the requirements of the major JavaScript engines (in Firefox, Chrome, and maybe WebKit). This is already the case when it comes to control flow semantics.
  - k__ 7y ago
    Could it be that JVM and CLR were technically correct, but policy wrong?
sunfish 7y ago
Note that Wasmtime is the engine starring in the blog post and demos :-). Of course, cross-language interfaces will always have tradeoffs. But we see Interface Types extending the space where the tradeoffs are worthwhile, especially in combination with wasm's sandboxing.
skrowl 7y ago
WOW that was too much to read. Can someone TLDR when we'll be able to get rid of Electron using this for me?
- sunfish 7y ago
  Much of what makes Electron Electron are the APIs it provides. The blog post here is a way to describe and work with APIs, not actual new APIs. We're working on APIs too, in WASI, but there's a lot of work to do to build everything you'd need to build Electron-like apps.
- STRiDEX 7y ago
  If anything you'd use wasm in electron.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
baybal2 7y ago
I'm a strong opponent of WASM because I think that WASM will break the internet the very same way and same reason ActiveX and Java applets broke it over 20 years ago. An untrusted executable code, no matter how much sandboxed, virtualised, and isolated it is, would never be a good thing. It wasn't 20 years ago, and would never be, invariably of what "tech sauce" it is served with. I advocate for proactive removal of WASM lobbyists from standard setting bodies, and countering their promotion of WASM.
- omn1 7y ago
  ActiveX and Java applets were proprietary when they got introduced. WASM is an open standard that it supported by all browser vendors and already integrated without any third-party plugins. There is a spec for it that you can contribute to.
  - baybal2 7y ago
    It doesn't change a thing. Both ax and java were quite well documented and free for everybody to use, but they definitely broke the Internet for everybody without any exaggeration. I'll explain you why in the most neutral tone I can. Do you understand that biggest peddlers of inscrutinable executable format on the web are people who are not fine with the open nature of the Internet, and who can not make their business when all code available through the browser is available to at least minimal form of inspection? In other words, the people who are mad because they can't run business in the web because their business model depends on their code being closed, they WANT THIS big time. Their business thrives off non-interoperability and brokennes of software at large. Their success comes at the detriment of the Internet ecosystem at large. The more they brake the Internet for the rest of its users, the more money they can make, and this is why there can not be reconciliation with them and, us, the wider and more sane part of software developer community. And we, the engineering cadres, the most influential class of people in the new tech driven world, have all the influence needed to deny WASM adoption.
    - AlexanderDhoore 7y ago
      Modern minified javascript is just as inscrutable as anything else. For example, please try to read this code: https://apis.google.com/js/client.js https://apis.google.com/js/client.js You would need a "decompiler" to make anything out of that.
adev_ 7y ago
Side comment: a Thumbs-up for Lin Clark and her usual Mozilla blog posts including this one. It is easy to understand, very informative and the hand-drawn infographies makes it pleasant to read.
- CraftThatBlock 7y ago
  Would also like to add that the video in the article (https://www.youtube.com/watch?v=Qn_4F3foB3Q https://www.youtube.com/watch?v=Qn_4F3foB3Q) is really well made and to the point
hinkley 7y ago
I hope someone with their hand in these specs experienced the dumpster fire that was SOAP interoperability and is taking pains to be sure we don't have the same class of problems in wasm.
mkl 7y ago
> Document.createElement() takes a string. But when I call it, I’m going to pass you two integers. Use these to create a DOMString from data in my linear memory. Use the first integer as the starting address of the string and the second as the length. This seems like its introducing buffer overflow vulnerabilities, if the code can be tricked into using the wrong numbers. Sure, just into WebAssembly memory, but if everything's implemented in WebAssembly, won't there often be sensitive information in there? Doing some more research, it seems like this may be a common problem: https://stackoverflow.com/questions/41353389/how-can-i-return-a-javascript-string-from-a-webassembly-function https://stackoverflow.com/questions/41353389/how-can-i-retur...
- CUViper 7y ago
  Doesn't each wasm module get its own isolated memory? If so, then you could only shoot your own sensitive foot.
  - yellowapple 7y ago
    There's no guarantee that the module's memory is strictly isolated; I don't recall what the specification says, but on a technical level there's nothing stopping a WASM implementation from exposing the same memory range to multiple WASM modules (and in fact, I can imagine this to be a very common use case for multiple memories, e.g. defining STDOUT and STDIN as memories shared with other modules, with one module reading and the other writing). Most (all?) WASM runtimes currently enforce this isolation, though, for security reasons. If any do allow memories to be shared between modules, I'd imagine it'd be very explicit and opt-in.
  - pjmlp 7y ago
    That is already enough to trigger CVE on WASM modules.
  - kevingadd 7y ago
    Yes, but a "module" can be an application and a full set of its dependencies. It's unlikely that its dependencies would have isolated heaps, as there would be no way for them to communicate (they can't touch each others' pointers, etc) other than through intermediary JS. So any vulnerability in any piece of wasm in your webpage effectively compromises everything. One compromised module can also likely reach out into the page and then use other modules' public interfaces to compromise them too. There is not sandboxing in place to prevent this sort of attack, the sandbox merely protects the browser from attack by content.
aloknnikhil 7y ago
Good effort. But the bit about using Protobuf, Cap'nProto only in processes that don't share memory is wrong. Sure, that may not be how they're traditionally used. But that doesn't exclude me from defining opaque C FFIs that pass/return opaque bytes that are serialized messages and have it be deserialized on the other end.

324 points by skellertor 7y ago

Oh, this is wonderful. Getting closer to that multilang WASM world.

I'm gonna go out on a limb here and expose my n00bishness, and honestly a lot of that article has my head spinning as I google a lot of terms ;) I've only done web development for a year now and I've seen some cool WebAssembly demos but mostly those are demos of various frameworks (or no framework) reusing random WebAssembly components. It's cool, but I'm missing from a large web application stance how WebAssembly is supposed to work, specifically when it comes to stuff like you see in some frameworks with state management across components and etc. Is there an example of that?

vcarl 7y ago
Web assembly is generally an optimization, not an app alternative. Think of it the way you would the C bindings Node.js has. If you've got a compute-heavy code path, writing it in C (or Rust etc) and shipping it as web assembly could be a dramatic perf improvement, but there's not really a substantive benefit to writing your entire app with it.
- petters 7y ago
  Another benefit I suppose is that you can choose from many more languages. Whether that is substantive or not depends on the person, I guess.
- weberc2 7y ago
  That's a use case, but there are many others, as the article mentions, like lightweight isolation for server side apps or writing your frontend app in a different language (not pragmatic today, but could be in the future).
- opencl 7y ago
  Another benefit is initial page load times, if your page has a lot of JS it can take a pretty significant amount of time to parse it. i.e. Figma said it reduced page load times by a factor of 3, though they were using WASM to replace existing asm.js code. https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
- asdkhadsj 7y ago
  > but there's not really a substantive benefit to writing your entire app with it. Amendment: Perhaps it's debatable what "substantive benefit" would be, but writing the whole app in it is a huge benefit if you really want to do that. That is to say, for years people wanted to write Web UI stuff in various languages, this also allows for that. So while the concrete performance boost may not be meaningful in writing an entire web app in C, Rust, Go, Python or w/e - to the developer happiness the boost may be huge for those devs that want it.
  - vcarl 7y ago
    Well, you still can't do that—WASM doesn't have DOM bindings, you'd still have to ship out to JS. I believe that's a goal, so yes eventually that could be a benefit, but not at the moment.
    - asdkhadsj 7y ago
      Fwiw, you can - just perhaps with not pure WASM and perf. My next app I'm planning on using a Rust WASM DOM framework, and I know there are some in Go as well. This is primarily for developer UX.
    - pjmlp 7y ago
      DOM bindings are kind of irrelevant when one has WebGL. One example among many ramping up https://platform.uno/ https://platform.uno/
      - icebraining 7y ago
        I looked into their WebAssembly demo, but it doesn't seem to use WebGL, just a regular DOM (with an ungodly number of elements).
        pjmlp 7y ago
        That was just an example, maybe not the best one. I should just have linked something done in Unity instead.
Juliennng 7y ago
Maybe that article can help about real world use case : https://tech.ebayinc.com/engineering/webassembly-at-ebay-a-real-world-use-case/ https://tech.ebayinc.com/engineering/webassembly-at-ebay-a-r...
- duxup 7y ago
  Thank you.

lachlan-sneff 7y ago

So this is what they've been up to! How well will this interact with the upcoming (hopefully before the heatdeath of the universe) rich gc types extension?

sunfish 7y ago
Interface types will make it easy for two modules to interface with each other, regardless of whether both sides use GC, just one side does, or neither side does. And even within GC types, different languages have different ways of representing strings, and Interface Types can allow them to talk to each other.

hackcasual 7y ago

Glad to see this being worked on. The difference between a heap vs. runtime managed object is a huge perf gap for tightly interoperating JS and WASM. At my company, we built a specific object representation that would allow zero copy, through array buffer sharing, views of C++ data from Javascript. Sounds very similar to this.

ptx 7y ago
I got the impression from the article that it will always copy data (e.g. strings) between wasm modules. Did I misread it?

syrusakbary 7y ago

Super happy to see WebAssembly Interface Types in development! At Wasmer (disclaimer, I'm the founder!) we've been creating integrations with a lot different languages (C, C++, Rust, Python, Ruby, PHP, C# and R) and we agree that this is a pain point and an important problem to solve. We're excited that Mozilla is also pushing this forward. If you want to start using WebAssembly anywhere: https://wasmer.io/ https://wasmer.io/ Keep up the good work! Let's bring WebAssembly everywhere!

jedisct1 7y ago
Is this going to replace wasmer's WebAssembly interfaces? As a library implementer, I'm a bit lost about how to expose functions from a wasm module to the outside world. wasmer's interfaces have the advantage of being very simple to write. But they are not very expressive. WebIDL is horrible, albeit more expressive. At the same time, I feel like this is not enough. My experience with libsodium.js, one of the first library exposing wasm (and previously asm.js) to other environments, has been that IDLs simply exposing function interfaces are not good enough. For example, C functions returning 0 or -1 to indicate an error or not, would not be idiomatic at all if exposed that way in Scala, Javascript or Python. We want these to raise an exception instead. Also, we need ways to preallocate buffers, check their size, etc. in order to make things appear more idiomatic. In libsodium.js, the description language for the WebAssembly <-> JS glue is JSON-based. It describes the input and output types, but also their constraints, and how to interpret the output. That was necessary, and if more languages are targeted, this is even more necessary. I feel like WebIDL is both complex, and insufficient. Another thing that I don't necessarily get is why such a description language was designed specifically for WebAssembly. Instead, we could have (yet another) way to describe APIs and how to encode that description. That description can then be included in ELF libraries, in Java objects, in WebAssembly modules, whatever. You know, like, what debuggers already use.
erlend_sh 7y ago
We are exploring using Wasmer as a scripting/modding platform in the Amethyst game engine: https://github.com/amethyst/amethyst/pull/1892 https://github.com/amethyst/amethyst/pull/1892

the_duke 7y ago

I'm very happy to see the WebIDL proposal replaced with something generalized. The article brings up an interesting point: Webassembly really could enable seamless cross-language integration in the future. Writing a project in Rust, but really want to use that popular face detector written in Python? And maybe the niche language tokenizer written in PHP? And sprinkle ffmpeg on top, without the hassle of target-compatible compilation and worrying about use after free vulnerabilities? No problem use one of the many WASM runtimes popping up (like [1], [2]) and combine all those libraries by using their pre-compiled WASM packages distributed on a package repo like WAPM [2], with auto-generated bindings that provide a decent API from your host language. Sounds too good to be true? Probably, and there are plenty of issues to solve. But it sounds like a future where we could prevent a lot of the re-writes and duplication across the open source world by just tapping into the ecosystems of other languages. [1] https://wapm.io/ https://wapm.io/ [2] https://github.com/CraneStation/wasmtime https://github.com/CraneStation/wasmtime [2] https://wapm.io/ https://wapm.io/

wahern 7y ago
JVM (Java), Parrot (Perl 6 VM) and CLR (C#) shipped easy, multi-language environments over a decade ago. For some definitions of "easy" and "multi-language". Different programming languages exist for many reasons, only one of which is syntax. Many of these reasons relate to data structures and runtime control flow. WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. (Spoiler: they didn't, and WASM won't.) At best you'll get a Rust'ish WASM, Python'ish WASM, PHP'ish WASM, etc. And all of those will feel like a cousin to JavaScript, just as anything on the JVM feels similar to Java, on Parrot feels similar to Perl 6, and on the CLR feels similar to C#. WASM's choice of data structures, control flow, and data representations will be strongly influenced by the requirements of the major JavaScript engines (in Firefox, Chrome, and maybe WebKit). This is already the case when it comes to control flow semantics.
- k__ 7y ago
  Could it be that JVM and CLR were technically correct, but policy wrong?

sunfish 7y ago

Note that Wasmtime is the engine starring in the blog post and demos :-). Of course, cross-language interfaces will always have tradeoffs. But we see Interface Types extending the space where the tradeoffs are worthwhile, especially in combination with wasm's sandboxing.

skrowl 7y ago

WOW that was too much to read. Can someone TLDR when we'll be able to get rid of Electron using this for me?

sunfish 7y ago
Much of what makes Electron Electron are the APIs it provides. The blog post here is a way to describe and work with APIs, not actual new APIs. We're working on APIs too, in WASI, but there's a lot of work to do to build everything you'd need to build Electron-like apps.
STRiDEX 7y ago
If anything you'd use wasm in electron.

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

baybal2 7y ago

I'm a strong opponent of WASM because I think that WASM will break the internet the very same way and same reason ActiveX and Java applets broke it over 20 years ago. An untrusted executable code, no matter how much sandboxed, virtualised, and isolated it is, would never be a good thing. It wasn't 20 years ago, and would never be, invariably of what "tech sauce" it is served with. I advocate for proactive removal of WASM lobbyists from standard setting bodies, and countering their promotion of WASM.

omn1 7y ago
ActiveX and Java applets were proprietary when they got introduced. WASM is an open standard that it supported by all browser vendors and already integrated without any third-party plugins. There is a spec for it that you can contribute to.
- baybal2 7y ago
  It doesn't change a thing. Both ax and java were quite well documented and free for everybody to use, but they definitely broke the Internet for everybody without any exaggeration. I'll explain you why in the most neutral tone I can. Do you understand that biggest peddlers of inscrutinable executable format on the web are people who are not fine with the open nature of the Internet, and who can not make their business when all code available through the browser is available to at least minimal form of inspection? In other words, the people who are mad because they can't run business in the web because their business model depends on their code being closed, they WANT THIS big time. Their business thrives off non-interoperability and brokennes of software at large. Their success comes at the detriment of the Internet ecosystem at large. The more they brake the Internet for the rest of its users, the more money they can make, and this is why there can not be reconciliation with them and, us, the wider and more sane part of software developer community. And we, the engineering cadres, the most influential class of people in the new tech driven world, have all the influence needed to deny WASM adoption.
  - AlexanderDhoore 7y ago
    Modern minified javascript is just as inscrutable as anything else. For example, please try to read this code: https://apis.google.com/js/client.js https://apis.google.com/js/client.js You would need a "decompiler" to make anything out of that.

adev_ 7y ago

Side comment: a Thumbs-up for Lin Clark and her usual Mozilla blog posts including this one. It is easy to understand, very informative and the hand-drawn infographies makes it pleasant to read.

CraftThatBlock 7y ago
Would also like to add that the video in the article (https://www.youtube.com/watch?v=Qn_4F3foB3Q https://www.youtube.com/watch?v=Qn_4F3foB3Q) is really well made and to the point

hinkley 7y ago

I hope someone with their hand in these specs experienced the dumpster fire that was SOAP interoperability and is taking pains to be sure we don't have the same class of problems in wasm.

mkl 7y ago

> Document.createElement() takes a string. But when I call it, I’m going to pass you two integers. Use these to create a DOMString from data in my linear memory. Use the first integer as the starting address of the string and the second as the length. This seems like its introducing buffer overflow vulnerabilities, if the code can be tricked into using the wrong numbers. Sure, just into WebAssembly memory, but if everything's implemented in WebAssembly, won't there often be sensitive information in there? Doing some more research, it seems like this may be a common problem: https://stackoverflow.com/questions/41353389/how-can-i-return-a-javascript-string-from-a-webassembly-function https://stackoverflow.com/questions/41353389/how-can-i-retur...

CUViper 7y ago
Doesn't each wasm module get its own isolated memory? If so, then you could only shoot your own sensitive foot.
- yellowapple 7y ago
  There's no guarantee that the module's memory is strictly isolated; I don't recall what the specification says, but on a technical level there's nothing stopping a WASM implementation from exposing the same memory range to multiple WASM modules (and in fact, I can imagine this to be a very common use case for multiple memories, e.g. defining STDOUT and STDIN as memories shared with other modules, with one module reading and the other writing). Most (all?) WASM runtimes currently enforce this isolation, though, for security reasons. If any do allow memories to be shared between modules, I'd imagine it'd be very explicit and opt-in.
- pjmlp 7y ago
  That is already enough to trigger CVE on WASM modules.
- kevingadd 7y ago
  Yes, but a "module" can be an application and a full set of its dependencies. It's unlikely that its dependencies would have isolated heaps, as there would be no way for them to communicate (they can't touch each others' pointers, etc) other than through intermediary JS. So any vulnerability in any piece of wasm in your webpage effectively compromises everything. One compromised module can also likely reach out into the page and then use other modules' public interfaces to compromise them too. There is not sandboxing in place to prevent this sort of attack, the sandbox merely protects the browser from attack by content.

aloknnikhil 7y ago

Good effort. But the bit about using Protobuf, Cap'nProto only in processes that don't share memory is wrong. Sure, that may not be how they're traditionally used. But that doesn't exclude me from defining opaque C FFIs that pass/return opaque bytes that are serialized messages and have it be deserialized on the other end.