A case for removing the seal/freeze/isSealed/isFrozen traps

David Bruant bruant.d at gmail.com
Fri Feb 15 02:48:18 PST 2013


Le 15/02/2013 11:03, Mariusz Nowak a écrit :
> I've worked a lot with ECMAScript5 features in last two years, and I must say
> I never found a good use case for Object.freeze/seal/preventExtensions, it
> actually raised more issues than it actually helped (those few times when I
> decided to use it). Currently I think that's not JavaScript'y approach and
> use cases mentioning "untrusted parties" sounds "logical" just in theory, in
> practice when actually we never include "untrusted" modules in our code base
> does not make much sense.
>
> However, main point I want to raise is that several times I had a use case
> for very close functionality, that with current API seem not possible:
> I'd like to be able to *prevent accidental object extensions*.
If something *accidental* can happen, then "untrusted parties" is more 
than theorical ;-)
Brendan says it better [1]:
"In a programming-in-the-large setting, a writable data property is 
inviting Murphy's Law. I'm not talking about security in a mixed-trust 
environment specifically. Large programs become "mixed trust", even when 
it's just me, myself, and I (over time) hacking the large amount of code."

"Security" and "untrusted parties" aren't about terrorists groups trying 
to hack your application to get a copy of your database or corrupt it or 
your choice to use some code downloaded from a dark-backgrounded website.
They're about you trying to meet a deadline and not having time to read 
carefully the documentation and comments of every single line of modules 
you're delegating to.
Trust isn't an all-or-nothing notion. Anytime I say "untrusted", I 
should probably say "partially trusted" instead.
Trust also changes over time, mostly because as times passes, our brains 
forget the invariants and assumptions we baked in our code and if those 
aren't enforced at compile time or runtime, we'll probably violate them 
at one point or another and thus create bugs. Or we just make mistakes, 
because we're human and that's exactly the case you're explaining.
"Security" and "untrusted parties" are about our inability as human 
beings to remember everything we do and our inability to be perfect. Any 
"security" mechanism is a mechanism to protect against hostile outsiders 
but also and probably mostly ourselves over time.

It is usually not considered so, but separation of concerns is a 
security mechanism in my opinion. So are most object-oriented so-called 
good practices.

"Security" is very loaded with emotions of people afraid to have their 
password stolen and "cyber attacks". It's also loaded with the notion of 
human safety and human integrity which, as human beings are sensitive to.
Maybe I should start using a different word...

> I want to
> control all enumerable properties of the object, so they can only be set via
> defineProperty, but any direct assignment of non existing prop e.g.
> 'x.notDefinedYet = value'  will throw. Imagine some ORM implementation, that
> via setters propagates changes to underlying persistent layer, at this time
> we cannot prevent accidental property sets that may occur before property
> was actually defined (therefore not caught by the setter)
> I assume that proxies will make such functionality possible, but maybe some
> Object.preventUndefinedExtensions will be even better.
The problem is that there are probably dozens of use cases like yours 
[2] and the Object built-in can't welcome them all.
Hence proxies as an extension mechanism of any "random 
micro-abstraction" (as Andreas Rossberg puts it ;-) )

David

[1] https://mail.mozilla.org/pipermail/es-discuss/2013-February/028724.html
[2] When I learned JS, how many time did I mistyped .innerHTML and 
wasted hours not understanding where some "undefined" string in my UI 
came from.


More information about the es-discuss mailing list