A case for removing the seal/freeze/isSealed/isFrozen traps
bbenvie at mozilla.com
Fri Feb 15 05:29:19 PST 2013
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> wrote:
> David, that's great clarification, and indeed it looks a bit different from
> that perspective.
> Still the only use case I see for freezing/sealing whole object (the way it
> works now) is when we expose some constant dictionary object on which each
> 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* API's
> but disallowing custom extensions is too restrictive and not friendly in my
> View this message in context: http://mozilla.6506.n7.nabble.com/A-case-for-removing-the-seal-freeze-isSealed-isFrozen-traps-tp272443p272674.html
> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss