direct_proxies "problem"

Boris Zbarsky bzbarsky at
Wed Jan 9 08:42:03 PST 2013

On 1/9/13 11:30 AM, François REMY wrote:
> However, this second problem is not related to the DOM but to
> globally accessible variables.

Well, right, but the DOM sort of forces the problem on us because of 

> No membrane system can be secure through global variable access, so
> we should not worry about that.

Actually, a membrane system _can_ be secure through global variable 
access.  You just have to make sure that all accesses are performed via 
the membrane and that you know for any accessor what the right membrane is.

An existence proof are the membranes Gecko+SpiderMonkey uses for 
security checks.  But those require that any time you're returning an 
object from anywhere you check who your caller is and what membrane they 
should be getting....

> According to me, the only thing we want to make sure with a Proxy is
> that you can't actually extract the value of a DOMObject that's not
> added nor addable to any globally accessible map (like a
> CustomEvent). If you can, by creating an element and calling
> dispatchEvent on that element using the membrane and get the
> unmembraned CustomEvent in the event listener, then we've a problem.

OK.  So this assumes that all consumers should get the same membrane, right?

> When the ProxiedCustomEvent is given back to the
> script world, his getScriptValue method is called to return the
> original proxy.

This is doable in theory.  I'd have to think about performance impact. 
One of the goals here from a UA implementor point of view is that there 
should be no performance hit from supporting this use case if you 
_don't_ proxy WebIDL objects.

> Albeit possible, this is quite a bit of work, however.


> The only problem I still see with the ProxiedXXX decorator approach
> is that, normally, when you are using a proxy, you can "control" the
> value returned by some property calls (let's say you pretend
> innerHTML is "" while this is not true) but in the "native" world,
> your barrier will not apply and therefore one can get the innerHTML
> by using a DOMSerializer.

Yep.  Lots of issues like that, actually...

> Because, when you think about it, I can deep-clone any
> "JS" object and except that o!===o2 they will be the same and work in
> the same contexts

Well, you have to know about the underlying identity of the "JS" object, no?

If I deep-clone (in the sense of copying all own property descriptors 
and copying the proto chain) a Date onto an Object, I don't think that 
will work quite right in current implementations, for example.  Same for 
Array.  So properly deep-cloning involves detecting cases like that 
already and creating a clone of the right type...


More information about the es-discuss mailing list