Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Recommendations when publishing a WASM library

nickb.dev

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Recommendations when publishing a WASM library

#11

Post by jitl »

johannes1234321 wrote: post #5
dgb23 wrote: post #3

Earlier quoted context omitted.

Can you elaborate on that? From what I know, WASM is a safe, rather abstract bytecode format and has far less API capabilites as JS has (which is why you need to call it from JS to affect the browser).

The concern is the same as with any dependency: The dependency runs under your privileges with access to your data. A malice vendor could do "anything" at least within the scope of your application. For instance if you create a web mail application the code probably has access to all mails, can delete them, can send mail under the user's identity, ... How relevant those scenarios are you have to evaluate. If you comp…

The great thing about WASM is that you don’t need to audit the binary - just the code that touches the binary through the WebAssembly.* namespace. If the code looks too complicated, or exposes eval or equivalent capabilities like arbitrary JS function calls, then you should approach with caution and build yourself, etc etc.

Most WASM libraries I’ve considered using (and the one I package myself) use an off-the-shelf Emscripten wrapper minified with Google Closure Compiler. This is annoying to audit compared to plain JS, but certainly doable with a few rename-symbol in your editor.

Re: Recommendations when publishing a WASM library

#12

Post by jitl »

gwbas1c wrote: post #10
dgb23 wrote: post #6

Earlier quoted context omitted.

But again, it's not "just" a binary. You provide the interfaces to it that actually affect the world. I agree with the general implications of using a dependency though.

At least in in-browser Blazor (C# compiled to WASM) I have full access to the page's Javascript environment: I can call most Javascript methods available, and I can even call eval. I'm still new to WASM, but I assume this functionality is part of the WASM runtime? (As opposed to a hook that's part of the Javascript part of Blazor?)

You are assuming wrong, this is Blazor’s JS support library. By “default” WebAssembly has nothing outside the WASM bytecode, not even memory/allocator. It’s up to the host environment to provide the WASM module a Memory and whatever “imports” it needs.

Re: Recommendations when publishing a WASM library

#13

Post by westurner »

conda: "Adding a WebAssembly platform" https://github.com/conda/conda/issues/7619

  pyodide.loadPackage("numpy");
 
  pyodide.loadPackage("https://foo/bar/numpy.js");
  

  #  import micropip
 
 micropip.install('https://example.com/files/snowballstemmer-2.0.0-py2.py3-none-any.whl')
"Creating a Pyodide package" > "2. Creating the meta.yaml file" https://pyodide.org/en/stable/development/new-packages.html#...

conda-forge: "WASM as a supported architecture" https://github.com/conda-forge/conda-forge.github.io/issues/...

Re: Recommendations when publishing a WASM library

#15

Post by johannes1234321 »

dgb23 wrote: post #6
johannes1234321 wrote: post #5

Earlier quoted context omitted.

The concern is the same as with any dependency: The dependency runs under your privileges with access to your data. A malice vendor could do "anything" at least within the scope of your application. For instance if you create a web mail application the code probably has access to all mails, can delete them, can send mail under the user's identity, ... How relevant those scenarios are you have to evaluate. If you comp…

But again, it's not "just" a binary. You provide the interfaces to it that actually affect the world. I agree with the general implications of using a dependency though.

It is true, that you have to expose things first. However as soon as any non-trivial object is shared from JS to WASM it is likely that some reference to something global, to the DOM, ... is nested in there. And that makes all other attempts to limit access void. (DOM give networking etc )

Re: Recommendations when publishing a WASM library

#17

Post by kylebarron »

Looks to be a great resource. I've been working on a WASM implementation of reading and writing Apache Parquet [0] and it's been difficult being new to WASM to find the best way of distributing the WASM that works on Node and through bundlers like Webpack.

[0]: https://github.com/kylebarron/parquet-wasm

Re: Recommendations when publishing a WASM library

#18

Post by klibertp »

jitl wrote: post #12
gwbas1c wrote: post #10

Earlier quoted context omitted.

At least in in-browser Blazor (C# compiled to WASM) I have full access to the page's Javascript environment: I can call most Javascript methods available, and I can even call eval. I'm still new to WASM, but I assume this functionality is part of the WASM runtime? (As opposed to a hook that's part of the Javascript part of Blazor?)

You are assuming wrong, this is Blazor’s JS support library. By “default” WebAssembly has nothing outside the WASM bytecode, not even memory/allocator. It’s up to the host environment to provide the WASM module a Memory and whatever “imports” it needs.

Memory can also be statically reserved in a binary, like the .data section in x86 asm. IIRC (tell me if I'm very wrong) Emscripten malloc works by reserving a large buffer up front and then managing pointers to (parts of) it. Otherwise, you can allocate memory buffer dynamically from JS[1] and pass the pointer to it to the WASM. Obviously, you can do this in response to the request coming from WASM, but you don't have to.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Recommendations when publishing a WASM library

#19

Post by klibertp »

johannes1234321 wrote: post #15
dgb23 wrote: post #6

Earlier quoted context omitted.

But again, it's not "just" a binary. You provide the interfaces to it that actually affect the world. I agree with the general implications of using a dependency though.

It is true, that you have to expose things first. However as soon as any non-trivial object is shared from JS to WASM it is likely that some reference to something global, to the DOM, ... is nested in there. And that makes all other attempts to limit access void. (DOM give networking etc )

I think you actually can't pass any non-trivial object to WASM. The only thing you can pass to and get out of WASM (IIRC) is a chunk of linear memory, a buffer. I don't think it's possible to obtain a raw pointer to an object on a JS side - passing that would be very unsafe, but also pretty much useless, unless you knew precisely the memory layout of said object. If you need to expose operations on a more complex objects to WASM, you need to encode the object identity somehow (as a number, or a buffer) and expose an API that will decode the object reference and call the needed function/method on it.

Re: Recommendations when publishing a WASM library

#20

Post by johannes1234321 »

klibertp wrote: post #19
johannes1234321 wrote: post #15

Earlier quoted context omitted.

It is true, that you have to expose things first. However as soon as any non-trivial object is shared from JS to WASM it is likely that some reference to something global, to the DOM, ... is nested in there. And that makes all other attempts to limit access void. (DOM give networking etc )

I think you actually can't pass any non-trivial object to WASM. The only thing you can pass to and get out of WASM (IIRC) is a chunk of linear memory, a buffer. I don't think it's possible to obtain a raw pointer to an object on a JS side - passing that would be very unsafe, but also pretty much useless, unless you knew precisely the memory layout of said object. If you need to expose operations on a more complex obj…

When using emscripten you get the full marshalling of objects.

Doing a network request from C++:

   val xhr = val::global("XMLHttpRequest").new_();
  xhr.call("open", std::string("GET"), std::string("http://url"));
https://emscripten.org/docs/api_reference/val.h.html#val-h

Of course this can be thrown out of the JavaScript binding side so that it isn't there anymore, but the marshalling makes the API nice and so many emscripten users will use it, thus it's present, thus you have to trust the wasm library.

How complicated this is without emscripten i don't know, but even then I guess many people will need some marshalling for real life scenarios.

Post reply on HN