Le 06/06/2014 15:57, Mark S. Miller a écrit :
By contrast, a Map's state is more like the private instance variable
state of a closure or a post-ES6 class.
The capabilities to arbitrarily modify Maps (set/delete on all keys,
with any values) will be expected by any ES6-compliant code to be
globally available, so a Map's state cannot reasonably be considered
private.
This differs from the state of a closure where its access is strictly
moderated by the public API giving access to it and to the fact that
this API is not provided globally (unlike Map.prototype).
Object.freeze of a Map should not alter the mutability of this state
for the same reason it does not alter the state captured by a closure
or a future class instance.
I'd argue the Map state is very much like regular objects (for which you
can't deny [[Set]], [[Delete]], etc.), not closure's state.
In an ES6 world, denying access to the global Map.prototype.* would
break legitimate code, so that's not really an option confiners like
Caja could provide.
or should an Object.makeImmutable be introduced? (it would be
freeze + make all internal [[*Data]] objects immutable)
We do need something like that. But it's a bit tricky. A client of an
object should not be able to attack it by preemptively deep-freezing
it against its wishes.
I don't see the difference with shallow-freezing?
It's currently not possible to defend against shallow-freezing (it will
be possible via wrapping in a proxy).
This can be achieved with Proxy right, or is that too cumbersome?
Code-readability-wise, wrapping in a proxy is as cumbersome as a
call to Object.preventUndeclaredGet I guess.
This sort of concerns are only development-time concerns and I
believe the runtime shouldn't be bothered with these (I'm aware it
already is in various web). For instance, the TypeScript compiler
is capable today of catching this error. Given that we have free,
cross-platform and fairly easy to use tools, do we need assistance
from the runtime?
Yes. Object.freeze is a runtime production protection mechanism,
because attacks that are only prevented during development don't
matter very much ;).
Just to clarify, I agree that Object.freeze was necessary in ES5 (have
we had proxies, it might have been harder to justify?), because there
was no good alternative to protect an object against the parties it was
shared with.
But the concern Nicholas raises doesn't seem to have this property.
Reading a property that doesn't exist doesn't carry a security risk,
does it? Object.preventUndeclaredGet doesn't really protect against
anything like ES5 methods did.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
