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....@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 > opinion. > > > > > -- > 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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
