My ECMAScript 7 wishlist

[David Bruant]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140606/f8313ac3/attachment.html>