A case for removing the seal/freeze/isSealed/isFrozen traps
erik.arvidsson at gmail.com
Fri Feb 15 06:24:23 PST 2013
... and security sensitive code could just ban/alter the reflection methods.
On Feb 15, 2013 8:29 AM, "Brandon Benvie" <bbenvie at mozilla.com> wrote:
> I definitely agree that something like "preventAccidentalExtensions"
> (disallows new properties through [[Put]] but not [[DefineOwnProperty]])
> has more common uses cases than preventExtensions, and for the precise
> reasons that David said. The security is against bugs usually, not
> attackers. PreventExtensions is a clumsy tool for managing capabilities
> because it leaves no room for giving *some* code permission while
> preventing other code, which is exactly what we want when the clueful *me*
> of now is writing code to manage the clueless *I* of the future.
> On Feb 15, 2013, at 6:31 AM, medikoo <medikoo+mozilla.org at medikoo.com>
> > David, that's great clarification, and indeed it looks a bit different
> > that perspective.
> > Still the only use case I see for freezing/sealing whole object (the way
> > works now) is when we expose some constant dictionary object on which
> > property counts, and that's very rare use case.
> > I don't see much good in disallowing extensions to prototypes we expose.
> > it's not JS way. We can prevent accidental modifications of *existing*
> > but disallowing custom extensions is too restrictive and not friendly in
> > opinion.
> > --
> > View this message in context:
> > Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss