Viewing profile — tschneidereit

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 unb…

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 t…

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, …

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 line…

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 i…

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-cl…

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…

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: https://hacks.mozi…

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 …

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…

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[…

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 …

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 co…

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, resear…

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 …

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 install…