On Wed, Dec 4, 2013 at 12:43 PM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu>wrote:
> On Wed, Dec 4, 2013 at 3:22 PM, Mark Miller <erig...@gmail.com> wrote: > > On Wed, Dec 4, 2013 at 12:12 PM, Sam Tobin-Hochstadt < > sa...@cs.indiana.edu> > > wrote: > >> > >> On Wed, Dec 4, 2013 at 3:04 PM, Mark Miller <erig...@gmail.com> wrote: > >> > Hi Sam, I read and followed your message, but I'm now confused about > the > >> > topic. Are we discussing hypothetical variants of JS in which we are > >> > happy > >> > to trust user code to uphold system invariants? Or are we discussing > >> > what > >> > can actually be done in current and future JS? If the former, I agree, > >> > but > >> > why is this a more interesting question than what we would do if we > had > >> > even > >> > fewer legacy constraints? > >> > >> My impression is we're talking about whether it's sensible to propose > >> a change that extends the behavior of proxies with regard to equality > >> (whether that's `===` or some other form of equality). I don't think > >> I was assuming that we trust user code to uphold system constraints. > >> Instead, I was arguing that the restriction to "checkably pure" code > >> is insufficient when you actually don't trust the other code, and > >> excessive when you do. > > > > > > That's interesting. Could you expand on the "insufficient" part of the > > argument? I hadn't gotten that. Thanks. > > The most obvious way that it's insufficient is that resource > consumption is an important effect. For example, we added > `chaperone?` in Racket -- the equivalent would be `isProxy` in JS -- > in order to avoid calling any potentially long-running code when a > particular critical lock was held in a part of the GUI system > implementation. > > The second way is that errors and other forms of non-termination are > effects, which can be visible to code outside of the proxy. Whether > that be a TypeError, or an infinite loop, checkable purity as > described in the Joe-E paper doesn't rule this out. > My fault for being sloppy in simply saying "secure" without explanation. Briefly, local E, Joe-E, and SES only claim to protect integrity, not availability at object granularity. (The situation with confidentiality is more nuanced than yes or no, but is not relevant to this thread.) Among objects sharing a single thread of control, protecting availability is essentially impossible. Distributed E, Waterken/Joe-E, and Dr. SES provide some protection of availability at vat granularity, but this is again both nuanced and not relevant to this thread. > > A more fundamental problem, however, is that checkable purity in the > sense of the Joe-E paper is not a reasonable strategy for proxy > handlers. In particular, proxy handlers have access to (a) the object > being proxied and (b) the arguments to the operation performed on the > proxy. The checkable purity strategy would require that both of these > be immutable, but that would restrict these checkably-pure proxy > handlers to transitively-immutable first-order data, making them > basically useless. > A good observation that I'd missed. The is also no mechanism that has been built in or on E that would solve this problem. So I agree with your conclusion. > > Sam > -- Cheers, --MarkM _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
