Le 21/01/2013 03:35, Allen Wirfs-Brock a écrit :
On Jan 20, 2013, at 5:42 PM, David Bruant wrote:
Le 20/01/2013 23:05, Allen Wirfs-Brock a écrit :
On Jan 20, 2013, at 11:12 AM, David Bruant wrote:
"complicated" was an expression. Either proxies don't work with
class instances, making them vastly pointless or classes need to
publicize their private symbols (or maybe expose something like
"myClass.acceptProxy" which is marginally better), thus ruining
their own encapsulation.
Actually this whole discussion makes me question the validity of the
current Proxy design rather than that of private Symbol. I may be
on the road towards getting on the NotificationProxy train.
If there is time to make that big of a change, Mark's idea of action
proxies could be considered too. I've only expressed reluctance on
the list, because it allows to do weird things when badly used, but
for all use cases I've had, it would be fine. Tom expressed
reluctance regarding the cost of action proxies, but I'm not entirely
sure it's founded.
Although Notification and action proxies are good to get rid of the
invariants cost, I'm not entirely sure they can help to reduce the
complexity when it comes to private symbols.
(...)
This suggests a possible generalized solution to the Proxy/private
symbol exposure problem:
The [[Get]] and [[Set]] (and probably some others) internal methods
of a proxy never call the corresponding trap when the property key
is a private Symbol. Instead, they trace the [[Target]] chain of
the proxy until a non-proxy object is reached (call this the
"ultimate target"). It then invokes the ultimate target's
[[Gett]]/[[Set]] using that same private Symbol key. The result of
that operation is then returned as the value of the original
[[Get]]/[[Set]].
The "private" state access is applied to the correct object and
there is no exposure of the private symbol!
It can work for built-in private state (and could work for private
class syntax too), but not for user-generated or obtained private
symbols:
Let's say 2 untrusted parties are in 2 membranes. They share a
private symbol and each has access to a proxy wrapping a common
target. With the private symbols semantics you're describing, these 2
untrusted parties have an unmediated communication channel.
How did they originally come to share the private symbol? Don't they
have to have some common point of origin with visibility of the symbol
or have both been provided the private symbol by some third party.
No, they have shared the symbol through mediated communication. As Tom
has argued multiple times, while symbols are "objects", they should be
considered as primitive values that can't be wrapped by proxies.
So the 2 parties, while using the mediated communication came to share a
private symbol. They didn't need a third party for that.
In either case couldn't they have closure captured references to each
other and use those references for direct communicate?
No, you created each of this context separately and you are the only
entity with access to both and for whatever good reason of yours, you
initially make them share a single object through which their mediated
communication start. A setup like one that Mark describes much better
than I do [1].
For instance, you're a webpage, each untrusted party is a widget and you
have an event mechanism through which you allow widgets to communicate
for some time and for whatever good reason.
An unmediated communication channel defeats the purpose of having put
the 2 untrusted parties in membranes in the first place.
The semantics of user-generated or obtained symbols has to go through
proxy mediation because of this use case, hence the whitelist and the
unknownPrivateSymbol trap in the current proxy design.
This really makes me start to question even more the viability of
Proxy based membranes (direct proxies, at least) as an isolation
mechanism. Independent of private Symbols, it isn't clear that it is
a practical approach.
I wonder how you're coming to such a question. It is a practical
approach assuming proxies can properly mediate communication.
Also, I think some of the issues discussed in the thread
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027246.html have
bearing on this discussion. It is probably worth taking a second look.
I think too that this thread revealed unclear stratification properties
in built-in algorithms, but I'm not following how relates to this
discussion.
David
[1]
http://www.youtube.com/watch?v=w9hHHvhZ_HY&feature=player_detailpage#t=2574s
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
