Catchall proposal

[Mark S. Miller]

On Wed, May 6, 2009 at 9:10 AM, Brendan Eich <brendan at mozilla.com> wrote:
> On May 6, 2009, at 8:22 AM, David-Sarah Hopwood wrote:
>
>> The ability to define 'has', 'get', and 'invoke' handlers for the
>> case where the property exists, is definitely needed IMHO. Suppressing
>> the visibility of a property is potentially as useful as creating a
>> "virtual" property, especially for the secure JS subsets.
>
> Good feedback. What do other secure subsetters say?

Good thread! I only have time to skim it at the moment, but it is of
central importance to improving the securability of ES. Thanks for
putting a concrete catchall proposal out there and getting us started
on this. This is important.

As for the particular point, I don't understand it. How would a secure
subset use these hooks to suppress, for example, domNode.innerHTML or
window.eval from being visible to "untrusted" code (i.e., code
constrained to be in SES -- a std Secure EcmaScript to emerge from
ADsafe, Jacaranda, dojox.secure, and Cajita) but not suppress its
visibility to normal ES code? Especially if we wish the future of
secure subsetting to be verification-based (as in Jacaranda,
dojox.secure, and ADsafe) rather than translation-based (as in current
Cajita)? If we can make verification work with adequate safety, I'm
all for it. But I don't see how the proposal above helps, since a
catchall cannot (and should not be able to) sense whether its caller
is in SES or full ES.

Note that the translation-basis of Valija, WebSandbox, and FBJS2 is a
distinct issue, since the goal there is to instantiate multiple
emulated global environments within a single actual global
environment. Catchalls may or may not help here as well, but the
question is so different that I suggest we postpone it until we first
understand the issues at the SES level.

-- 
    Cheers,
    --MarkM