On Wed, Sep 7, 2011 at 9:53 AM, Brendan Eich <[email protected]> wrote: [...]
> NOTE Implementations that add additional capabilities to the set of > built-in functions are encouraged to do so by adding new functions rather > than adding new parameters to existing functions. > > I think we should make this a normative restriction in ES6. +100. The SES whitelisting mechanism, where we remove all non-standard properties not on our whitelist < http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/whitelist.js>, only protects under the assumption that this restriction is upheld. While we could instead whitelist by name+arity, it would be a too expensive. In addition to removing everything absent from our whitelist, we'd have to wrap everything present on our whitelist. And even that still wouldn't be sound if implementors might still enable new abilities by, e.g., type-based overloads. We should also promote the recommendation at < http://wiki.ecmascript.org/doku.php?id=conventions:make_non-standard_properties_configurable> to normative status, so that such whitelisting mechanisms are possible. I believe these two constraints together are equivalent to the constraints enumerated at <http://code.google.com/p/es-lab/wiki/SecureableES5>. While I'm sure this list is incomplete, and the Ch16 exemptions need to be further restricted somehow, these two are still a great start. Btw, to avoid terminology confusion, I use "abilities" in sentences like yours when it works. In this case, it is precisely the mapping of such abilities onto capabilities that is at stake ;). -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
