W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2012

Re: WindowProxy objects violate ES5 invariants

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 15 Dec 2012 11:37:49 -0500
Message-ID: <50CCA75D.2080406@mit.edu>
To: David Bruant <bruant.d@gmail.com>
CC: "Mark S. Miller" <erights@google.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
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 

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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC