Oh, no worries at all—it happens!
[Creator of the StarlingMonkey JS runtime here] > It works in the browser already, by bundling another browser runtime engine into wasm. Note that that's not how JCO works: JCO unbundles a Component, emitting core wasm…
Oh, no worries at all! While there was no acquisition involved, a whole group of folks working on WebAssembly at Mozilla (myself included) moved to Fastly last Fall. What I tried to emphasize is that instead of the…
It's really the other way around: we joined Fastly because we knew it's a place where we could do this kind of work in the open. None of the code involved here existed a year ago, and none of it was somehow forced to be…
That is how we support references in the Rust toolchain right now, via wasm-bindgen, and it's an important part of making unforgable references work for languages that rely on linear memory. It doesn't help with making…
Agreed, and there are a lot of UX questions to sort out. Many security concepts took many attempts to figure out in full (or to the extent that they have been figured out :)) One important aspect here is that this…
Indeed: that and many other things are prior art in this space. And there is a lot of prior art for what we're working on—this is not meant as an academic research project! :)
What you're describing will indeed be introduced with the WebAssembly GC proposal: https://github.com/WebAssembly/gc For languages that can express unforgeable pointers as first-class concept, that is indeed a very…
To expand on this, capabilities allow us to go further than pledge(2): it enables selective forwarding of capabilities to other nanoprocesses, such as only forwarding a handle to a single file out of a directory, or a…
And Wasmtime will also support both of those. Support for environments in which JITting is not an option is of course really important to this!
We're working on that, too :) See this post from last Fall where we laid out a way to think about where WebAssembly is going, which use cases to enable, and how:…
Good news: we fully agree with these goals! On 1, the libc we're working on[1] is based on musl. It won't ever be 100% compatible with all code, because that runs into constraints imposed by our security goals, but the…
Oh, this is amazing!
Yes!
We've mainly based the current design on CloudABI/Capsicum, but it's all early days, and Fuchsia is on our list of systems to at the very least take heavy inspiration from :)
(Member of the team at Mozilla here ) Yes, that's the list. And the layout of structs, strings, etc is up to the compiler, within the bounds of the restrictions WebAssembly imposes. We'll definitely have a test suite,…
This is indeed a problem for Wasm/JS integration. The JS WeakRef proposal[1] will address it for many use cases, and the WebAssembly GC proposal[2], combined with JS Typed Objects[3] will address many others. Even…
Intermittently failing tests are a problem that all large code bases have, regardless of the used language. See for example this post about Google's code base[1], which is largely Java, Python, and to some extent Go and…
That last part doesn't work, unfortunately. We looked into doing exactly that, but the way history navigation works is specified quite strictly - and relied upon by existing web content - making this infeasible.
See my reply in another conversation thread: https://news.ycombinator.com/item?id=13520978
(Member of the browser.html team here) There's a section at the end about how we got to this approach. You're right that there isn't too much detail there, though. In short, research on how people interact with…
Things like history management. While tabs in browser.html are just iframes, browser.html needs more access to the contained documents to be able to fully do its job. For security reasons, you can't get at an iframe's…
EME is a way to add DRM support to html5 video, but it's not compatible with Flash's DRM system, so can't directly be used to implement that.
Thanks, bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1133323
Can you give steps to reproduce this crash? It should definitely not happen. In fact, until https://bugzilla.mozilla.org/show_bug.cgi?id=558184 is implemented we rely on an installed Flash plugin to make the Flash…
Oh, no worries at all—it happens!
[Creator of the StarlingMonkey JS runtime here] > It works in the browser already, by bundling another browser runtime engine into wasm. Note that that's not how JCO works: JCO unbundles a Component, emitting core wasm…
Oh, no worries at all! While there was no acquisition involved, a whole group of folks working on WebAssembly at Mozilla (myself included) moved to Fastly last Fall. What I tried to emphasize is that instead of the…
It's really the other way around: we joined Fastly because we knew it's a place where we could do this kind of work in the open. None of the code involved here existed a year ago, and none of it was somehow forced to be…
That is how we support references in the Rust toolchain right now, via wasm-bindgen, and it's an important part of making unforgable references work for languages that rely on linear memory. It doesn't help with making…
Agreed, and there are a lot of UX questions to sort out. Many security concepts took many attempts to figure out in full (or to the extent that they have been figured out :)) One important aspect here is that this…
Indeed: that and many other things are prior art in this space. And there is a lot of prior art for what we're working on—this is not meant as an academic research project! :)
What you're describing will indeed be introduced with the WebAssembly GC proposal: https://github.com/WebAssembly/gc For languages that can express unforgeable pointers as first-class concept, that is indeed a very…
To expand on this, capabilities allow us to go further than pledge(2): it enables selective forwarding of capabilities to other nanoprocesses, such as only forwarding a handle to a single file out of a directory, or a…
And Wasmtime will also support both of those. Support for environments in which JITting is not an option is of course really important to this!
We're working on that, too :) See this post from last Fall where we laid out a way to think about where WebAssembly is going, which use cases to enable, and how:…
Good news: we fully agree with these goals! On 1, the libc we're working on[1] is based on musl. It won't ever be 100% compatible with all code, because that runs into constraints imposed by our security goals, but the…
Oh, this is amazing!
Yes!
We've mainly based the current design on CloudABI/Capsicum, but it's all early days, and Fuchsia is on our list of systems to at the very least take heavy inspiration from :)
(Member of the team at Mozilla here ) Yes, that's the list. And the layout of structs, strings, etc is up to the compiler, within the bounds of the restrictions WebAssembly imposes. We'll definitely have a test suite,…
This is indeed a problem for Wasm/JS integration. The JS WeakRef proposal[1] will address it for many use cases, and the WebAssembly GC proposal[2], combined with JS Typed Objects[3] will address many others. Even…
Intermittently failing tests are a problem that all large code bases have, regardless of the used language. See for example this post about Google's code base[1], which is largely Java, Python, and to some extent Go and…
That last part doesn't work, unfortunately. We looked into doing exactly that, but the way history navigation works is specified quite strictly - and relied upon by existing web content - making this infeasible.
See my reply in another conversation thread: https://news.ycombinator.com/item?id=13520978
(Member of the browser.html team here) There's a section at the end about how we got to this approach. You're right that there isn't too much detail there, though. In short, research on how people interact with…
Things like history management. While tabs in browser.html are just iframes, browser.html needs more access to the contained documents to be able to fully do its job. For security reasons, you can't get at an iframe's…
EME is a way to add DRM support to html5 video, but it's not compatible with Flash's DRM system, so can't directly be used to implement that.
Thanks, bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1133323
Can you give steps to reproduce this crash? It should definitely not happen. In fact, until https://bugzilla.mozilla.org/show_bug.cgi?id=558184 is implemented we rely on an installed Flash plugin to make the Flash…