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
window.document.
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.
Yep.
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...
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
