Re: WindowProxy objects violate ES5 invariants

On 12/15/12 8:36 AM, David Bruant wrote:
> The downside is that if proxies aren't optimized, same-origin accesses
> need to go through 2 levels of handlers before reaching the actual
> object. This may have some cost.

In general, I wouldn't worry too much about the details of how the 
security checks are implemented, as long as it's possible; I expect it 
to vary between UAs based on the specific constraints of their security 
architecture and ES implementations.  For example, in Gecko the security 
check is done by a completely separate security membrane proxy before 
you ever get to the WindowProxy, but that's obviously not a hard 
requirement in theory.

>> Sure.  That's a useful way to think about it conceptually, but actual
>> implementations may do something different under the hood for
>> performance or convenience reasons.
> I can see the performance problems especially if proxies aren't
> optimized, but I don't understand what you're calling "convenience".

See above about decisions about exactly where to put the implementation 
of the security membrane, for example.

>> Detecting that might be annoying enough to not be worthwhile, though.
> Annoying for maintainability? for performance?

Mostly for maintainability: you have to whitelist the properties or 
something.

Though maybe if you never allow defining other non-configurable 
properties the WindowProxy could just assume that anything 
non-configurable that _has_ made it through to the Window is legit and 
just report them all as non-configurable.

> That point is important. If WindowProxy can reflect [Unforgeable]
> properties as configurable, then it changes the definition of
> [Unforgeable].

I don't see how it does.  [Unforgeable] is just defined in terms of what 
it puts on the Window.

-Boris

Received on Saturday, 15 December 2012 16:38:17 UTC