Oh, no worries at all—it happens!
131 karma · joined October 23, 2014
> 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 modules plus JS glue code. JCO also is a toolchain that can orchestrate turning JS into a Component, and that does bundle a JS runtime (StarlingMonkey), but that's not for running Components in JS/browsers, but for running JS in Component runtimes, such as Wasmtime.
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 projects at hand here being open source because they somehow had to be, we all joined Fastly because it's a place where this kind of project can be made open source (and be created in the first place!) :)
None of the code involved here existed a year ago, and none of it was somehow forced to be open source. (Also, the code in these two repositories is in many ways the most boring part of this solution. See this blog post for an excellent overview of the more interesting parts: https://bytecodealliance.org/articles/making-javascript-run-...)
It doesn't help with making capabilities more fine-grained, though: we have to treat all code that has access to that table as having the same level of trust.
One important aspect here is that this doesn't just target whole apps. It also targets developers using dependencies: while it's desirable to restrict an application's capabilities, there's a lot of value in developers only giving packages they depend on very limited sets of capabilities. And that seems much more tractable, given that kitchen-sink packages aren't what most people want to use anyway.
For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether.
Since we want to support those languages as first-class citizens, we can't require GC support as a base concept, so we have to treat a nanoprocess as the unit of isolation from the outside.
Once we have GC support, nothing will prevent languages that can use it from expressing finer-grained capabilities even within a nanoprocess, and that seems highly desirable indeed.
(full disclosure: I'm a Mozilla employee and one of the people who set up the Bytecode Alliance.)
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 vast majority of code should eventually just compile when targeting this. (Eventually, because this is all early days.)
On 2, yes, that is explicitly the goals. I'd add that it's not just about OSes, but also about platforms and hardware form factors.
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, but this is all early days, so a lot of all that isn't yet in place.
And yes, this can be targeted by LLVM-based and other compilers. In fact, Emscripten could use this as the foundation for their POSIX-like libc and library packages. The syscalls are indeed exposed as Wasm function imports.
[1] https://github.com/tc39/proposal-weakrefs [2] https://github.com/WebAssembly/meetings/blob/master/2018/pre... [3] https://github.com/tschneidereit/typed-objects-explainer
[1] They don't say which code base the post is about, so I'm just assuming that it's not Chromium. If it is, it'd largely be C++.
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 information sources shows that we rely on the kinds of connections we're trying to preserve as important queues for remembering and mentally sorting information.
As other posters here have pointed out, purely looking at the informational content it'd be enough to copy over the current tab's history stack when opening a link in a new tab. That doesn't mean that this information is easily consumed, though: while the degree to which this is true varies from person to person, by and large our mind works in a way that we have a hard time grasping connections between nodes in a graph without seeing enough of it at the same time and being able to map it out. If the only way to get any insights into the graph is to look at each tab's history stack individually, that's fine for compuers, but just not too useful for people.
See Patryk's earlier post on this topic (and the post's bibliography) for much more background information: https://medium.freecodecamp.com/browserhistory-2abad38022b1
In addition, the browser needs to act as a sort of broker between sites and the OS. Storing cookies and session data, showing notifications or dialogs, and entering fullscreen mode are just a few examples of this. (Note that most of these things aren't even implemented yet. Browsers are complex applications in their own right, even after accounting for the browser engine.)
There are two easy ways to test Shumway on all SWF files: if you don't want to use Firefox Nightly, you can just install the extension from http://areweflashyet.com/ and should be all set. If you're using Firefox Nightly, you can simply visit about:config and change the shumway.swf.whitelist setting to "*". Note that you still need to have the Flash plugin installed for most sites to work, as I explained in another comment a few minutes ago.
Regarding the table of supported APIs: the problem with that is that we actually have most APIs implemented, but have compatibility bugs in some of them which break content. If we could easily list the broken APIs, then in most cases we could just as easily fix them. That said, there are some major API areas we don't yet support. Those are mostly related to newer and thus less-used capabilities, such as Flash's version of WebGL, called Stage3D, and a new text layout system called Text Layout Engine.