direct_proxies "problem"

Boris Zbarsky bzbarsky at mozilla.com
Wed Jan 9 10:43:04 PST 2013


On 1/9/13 1:23 PM, David Bruant wrote:
> I don't think anyone (me including) really took the time to write an
> example of how unknownPrivateSymbol works either. Let's do that:

Thank you, that helps a lot.

>> What happens if unknownPrivateSymbol throws?
> I'm not sure yet. My guess is that the error should be propagated

So just to make sure we're on the same page here...  Say I have a proxy 
for a <div> and I put it in the DOM.  Say my page has:

   <style>
     section > div { color: green; }
   </style>

Should matching that selector against the div call unknownPrivateSymbol 
when getting the parent of the div?  If so, what should it do if it 
throws?  Note, by the way, that UAs are working on doing off-main-thread 
selector matching and that the exact timing/ordering of selector 
matching is not defined and won't be (because it's a state thing, not a 
procedural algorithm), so doing anything script-observable anywhere here 
is pretty weird.

On the other hand, selector matching allows one to exfiltrate things 
like which attributes are set and to what values, as well as information 
about the ancestors and often descendants of the element.

> It would be up to spec writers of each sort of object to decide.

OK.

> If the serialization algorithm is represented as a private symbol'ed
> methods on objects, then, doing a [[Get]] with this symbol as argument
> would call the unknownPrivateSymbol trap. The result of this trap (throw
> or return (return value is ignored)) determines whether the algorithm is
> actually called.

That wasn't my point.  My point was what happens to the tree traversal 
the serialization algorithm does if the firstChild member (not the 
getter, the actual internal state that stores the first child) is 
defined to be a private symbol?

> unknownPrivateSymbol is a trap, so I'm not sure I understand your
> question.

My question boils down to this: are we talking about introducing things 
that would be able to modify a DOM tree while it's being iterated by 
internal browser algorithms?  Because doing that is not acceptable.

It sounds like so far the answer is "maybe, depending on how those 
traversals are defined in the specs".

> The trap in itself cannot do anything.

On the contrary, it can do anything any JS function on the page can do.

> Best case, it forwards the operation to
> the target, worst case, it cancels the operation entirely.

No, worst case it calls document.open() or window.close() or spins the 
event loop via showModalDialog or any of a number of other interesting 
things script can do.

> The trap in itself can't do anything. The code in it is a function which
> can't do anything more than what a function can do today.

That's a _really_ interesting definition of "can't do anything".

Functions today can totally destroy the world (as in, the entire web 
page they're running in).  The only saving grace is that they can only 
be invoked at particular safe points when you allow the world to be 
destroyed.

Any proposal that would allow random functions to be invoked in too many 
cases is dead in the water from a security and performance standpoint.

> It can have side-effects, the only important case is whether a public
> method call result in 0 or 1+ calls on a given object.

Uh... no.  How can that be the only important case???

> What I meant
> above (but didn't say) is that whether it's called (0 or 1) is
> important, but if it's 1 or 5 times for a given public method call, it
> doesn't matter much.

For a function with side-effects this seems blatantly false to me, so I 
must be missing something.  What am I mising?

-Boris


More information about the es-discuss mailing list