WebAssembly
First-class XHR/fetch()-free mode
Right now, the file:// protocol is severely limited on chrome, meaning it doesn't provide any support for JavaScript to perform requests like via XHR or the fetch API. There are other scenarios as well where there is no support for JavaScript initiated requests. E.g. the wayback machine crawler doesn't run any JavaScript at all, so it doesn't archive any JavaScript requested resources.
Right now, all of the recommended ways to load WebAssembly files use window.fetch. It seems the only way to load WebAssembly files without JavaScript initiated requests is to load them via WebAssembly.instantiate from a buffer that was e.g. serialized via base64 inside a JavaScript string literal, possibly in a separate file. This obviously requires eval support to be enabled, which is a sad limitation. I'd consider that second-class support.
It would be great to have first-class support without the need for base64. JavaScript manages to do this as well :).
Some variants of module integration (#1087) might possibly provide a first class "JavaScript initiated requests"-free mode, but most variants seem to not provide it. That's why I'm filing this issue.
Right now, all of the recommended ways to load WebAssembly files use XHR
That's wrong; WebAssembly.instantiateStreaming is the recommended way and use window.fetch.
For Webpack and Rollup, the JavaScript module integration uses instantiateStreaming and fetch.
window.fetch is similarly not supported by Chrome on the file:// protocol. But I'll edit the issue to include javascript initiated requests instead.
I'd like to understand why file:// is relevant to this issue. Can you expand? Is file:// support the only motivation for the issue?
I'd like to understand why file:// is relevant to this issue.
Yes, the main use case is the file:// protocol.
You can load JavaScript content via the <script> tag on the file:// protocol without any issues, even in Chrome. It would be great to have something like that (whether with a <script> tag or something entirely different) for WebAssembly as well.
You can load JavaScript content via the
<script>tag on thefile://protocol without any issues, even in Chrome. It would be great to have something like that (whether with a<script>tag or something entirely different) for WebAssembly as well.
I understand that it's possible, but I don't understand why it's desirable. Is this purely to double-click an HTML file and have it to its thing through file:// URLs, rather than spawning a lightweight server on localhost? Or is there a deeper use case which I'm missing?
Or is there a deeper use case which I'm missing?
No. Is it bad if I want to avoid electron for something small that doesn't need any of electron's deeper privileges?
It feels wrong to me to force people to fire up localhost web servers (lightweight or not) just to be able to view static web sites (static meaning here that the server does nothing, not that there is no interactivity).
No. Is it bad if I want to avoid electron for something small that doesn't need any of electron's deeper privileges?
I'm not sure why electron is relevant here. Can you elaborate?
It feels wrong to me to force people to fire up localhost web servers (lightweight or not) just to be able to view static web sites (static meaning here that the server does nothing, not that there is no interactivity).
I still don't understand if this is a convenience thing for developers who test a static page on their own machine, or if you have something more in mind. The mention of electron leads me to believe it might be more, but I don't see what you have in mind. Please elaborate.
To be clear: I ask these questions because we need to understand why a suggestion comes in. Given the option to focus the CG's attention on Web use cases, non-Web use cases, or the convenience of a few developers I'd first focus on Web and non-Web. That's my prioritization, others might disagree, but if we don't even understand what a feature is for, which problem it solves for who, then we can't even prioritize it.
Finally, it's unclear to me why you think module integration might not work. Maybe that's what we need to focus on, or explicitly design out of module integration's scope.
I'm not sure why electron is relevant here. Can you elaborate?
Have this hypothetical scenario:
Maybe you want to write a tool that generates a report with some nice graphs and so on... business report, report how much milk the machine has processed in the last 24 hours, or how much oil the machine has something else. Such a report would most likely have some interactivity... maybe you want to run queries but the data is so much that JS is overwhelmed so you choose to take Wasm to speed up things. Should you have to ship electron with that report just so that it can be displayed by people who don't have that tool?
I'd call it the "interactive document" use case. A bit like harry potter newspaper.
My personal use case is similar to it. I made an app and wanted it to be universally executable. Browsers exist on any OS and are installed everywhere. Not so much if it were a python script or a Java executable... unless you ship the entire runtime but that runtime itself is not platform independent and you'd have to write platform specific guides how to start the thing :).
Finally, it's unclear to me why you think module integration might not work. Maybe that's what we need to focus on, or explicitly design out of module integration's scope.
To my knowledge, ES6 modules can be loaded via a <script> tag, but any modules you load from inside that module will give you SOP violation errors on the file:// protocol.... even though you can't load ES6 modules dynamically like you could load files via window.fetch().
As wasm files often do need JavaScript implementations, they need to depend on JS modules themselves, so they would fire such a request that'd be disallowed on the file:// protocol (for no good reason).
I don't think we're interested in expanding file:'s horrible (and underspecified) security model to further script execution targets. We (Chrome) explicitly disallowed it for JS module scripts, and are more likely to remove it from JS classic scripts than we are to add it web assembly scripts.
We (Chrome) explicitly disallowed it for JS module scripts
Could you lay out why or alternatively, do you have any pointers on past discussions about this issue?
JS module scripts or wasm scripts don't seem more dangerous to me than classic scripts.
The alternative, localhost web servers have security issues of their own: not being restricted to one user, possibly wrongly configured to accept connections from other hosts (not just localhost), etc etc.
As for electron security, you really need to watch out here as well :).
I've explained above:
I don't think we're interested in expanding file:'s horrible (and underspecified) security model to further script execution targets.
JS module scripts or wasm scripts don't seem more dangerous to me than classic scripts.
Yes. But one dangerous thing being used insecurely does not imply we should let other dangerous things be used insecurely. Instead, it implies we should try to make the dangerous thing not be usable in this insecure fashion; thus my above
are more likely to remove it from JS classic scripts
@domenic Is this line of arguing what you were saying?
- You have deemed the
file:///protocol unfit to have scripting abilities, out of security reasons. - At a future point in time, you may want to remove scripting support for the
file:///protocol - To minimize breakage in the future you don't want any additions like first-class wasm support to happen
Minimizing breakage makes a lot more sense to me personally than arguing with security because there is no decrease in security by addition of proper wasm support, and this is all which counts, no?