Object.keys(): Why no inherited properties?

Mark S. Miller erights at google.com
Wed Sep 7 10:28:07 PDT 2011


On Wed, Sep 7, 2011 at 9:53 AM, Brendan Eich <brendan at mozilla.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110907/02e52ef5/attachment.html>


More information about the es-discuss mailing list