Whitelist WeakSet

David Bruant bruant.d at gmail.com
Wed Sep 26 12:27:18 PDT 2012


[cc'ing Eddy Bruel for his opinion. Search for your name below]

Le 26/09/2012 20:46, Tom Van Cutsem a écrit :
> 2012/9/25 David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>>
>
>     In this last paragraph, I've demonstrated a way for the whitelist
>     to be
>     a proxy to a weakmap without ever needing to leak private names.
>     It all
>     rely on the internal [[has]] of weakset instances to be a private name
>     known to no one. Being a private name is just for spec economy
>     since the
>     name will never be visible to any client code.
>
>
> Thanks for your worked-out example. I understand where you're going,
> but I still feel it introduces too much complexity for a questionable
> use case. Your proposal implicitly assumes that built-in functions
> such as [[has]] are represented as private names. That's not how
> built-in methods currently work. Also, you mention that it's just for
> spec economy, but that's not really true: if the WeakSet is a proxy
> and [[has]] is a private name, the proxy's unknownPrivateName trap
> would need to be called.
True. I didn't sort out all the details and it's biting back...
The demonstration I gave isn't valid, but I'm sure it's not that far
from being workable either.
We can remove the part about [[has]] being a private name.

The engine can know if the end-target is a (Weak)Set, so it can decide
to bypass the proxy chain entirely and check directly on the end target.
Maybe the unknownPrivateName can be generalized to a "securityCheckSink"
trap. The name is awful, but the idea is here.

> Besides, I repeat, this isn't the first case where objects can't be
> transparently proxied.
This is however the first case within pure ECMAScript programs and I
find that problematic for the very use case I exposed in the previous
message (Alice and Bob both in different membranes trying to share a set
of private names).
I admit I don't have a perfect solution yet, but what I've proposed (and
tweaked above) isn't that far from an efficient and minimalistic solution.
If we can find such a solution, there is no reason not to use it. If all
possible solutions we come up with are too complicated or inefficient to
implement, let's accept it as a limitation.

> Consider the following transcript (tested in Firefox nightly 18.01a,
> with support for direct proxies):
>
> var e = document.createElement("div")
> var e2 = document.createElement("ul")
> e.appendChild(e2) // works fine
> var e3 = new Proxy(e2, {})
> e.appendChild(e3)
> Exception... "Could not convert JavaScript argument arg 0 ..."
It does not currently work, however, it isn't clear whether it should.
I'm convinced no work has been done in Firefox to make proxies and the
DOM interoperable (cc'ing Eddy Bruel who implemented direct proxies in
Firefox for his opinion).
With the previous proxy design, it was clear that emulating native DOM
objects with proxies was a no-go, because there was no way for the DOM
tree to know whether a proxy could be assiocated with a native object.
With the current design, however, the DOM can figure out whether the end
target of a proxy chain is a genuine DOM object and potentially accept
it as Node in the DOM tree if that's what the end target is.
I can't tell whether it's a good or bad idea, whether it's worth the
implementation cost, but the proxy design shift has re-opened that door.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120926/947913b7/attachment.html>


More information about the es-discuss mailing list