[Forwarded by request]
On Sat, Nov 4, 2017 at 1:17 AM, Andreas Rossberg <[email protected]> wrote: > To clarify for the broader crowd, to me this quote about (module) > instances just describes an aspect of proper modularity, which naturally > consists of two dual properties: > > 1. A module can only access what it (is given as) imports. > 2. A client can only access what a module exports. > > Of course, whether this implies an “ocap" system also depends on what > exactly “what” quantifiers over. Formally this usually refers to free names > or variables or addresses, which of course could still be side-stepped by a > language providing ambient capabilities in an unnamed fashion, e.g. as > primitive instructions. > > Ben Titzer (CC’ed) initially prototyped Wasm that way, and as far as he > told me, he consciously decided not to include any such primitives, even > though he didn’t frame it as ocap. Given the diversity of environments that > Wasm is supposed to be embeddable in that is almost a necessity: there > practically is no interesting (non-computational) resource that can be > assumed to exist in all possible embeddings, and hence you cannot build any > into the language even if you wanted. In particular, Wasm shall neither > depend on the web nor JavaScript nor any specific form of OS. > > (A minor quibble I have with the quote is formulating the “what” as > “effects”, because under the usual semantic interpretation of the term, a > Wasm computation can still have observable effects, such as traps, > non-determinism, or non-termination. But these (hopefully) are benign > effects wrt security considerations.) > > /Andreas > > > I suspect that most people in the room just > > On Nov 3, 2017, at 22:56 , Mark Miller <[email protected]> wrote: > > > > At the latest wasm (Web Assembly) standards meeting, I pointed out that > wasm is already an OS-like ocap system: A wasm instance, with its linear > data space + table of opaque external functions/objects is already a > process-granularity-like unit of isolation with an address space and a > clist. A wasm computation addresses its clist entries by clist index as > expected. In addition, wasm currently obeys the following restriction. > > > > > WebAssembly instances must never be able to cause effects other than > by wielding explicitly granted access (e.g. the importObject in a JS > embedding). > > > > According to Andreas Rossberg (cc'ed), this is on purpose, even though > the people in the room at the time did not seem to know that. I suggested > that it be made normative, so security uses of this restriction would not > be compromised by later "enhancements" that accidentally break this > unarticulated restriction. > > > > https://github.com/WebAssembly/meetings/issues/104 > > is the one to watch. Assuming I do a good job clarifying the agreement > we just came to, and assuming the agreement holds in the face of these > clarifications, it looks like wasm will explicitly be the object-capability > system it was designed to be. > > > > Andreas and Bradley (also cc'ed), please clarify or expand as > appropriate. If you don't want to subscribe to these lists, send your posts > to me and I will forward. Thanks. > > > > -- > > Cheers, > > --MarkM > > -- Cheers, --MarkM -- --- You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
