Le 17/12/2011 22:37, David Herman a écrit :
> On Dec 17, 2011, at 4:04 AM, David Bruant wrote:
>> I propose to accept that "o[n]" may disclose 'n' if 'o' is a proxy.
> This is just a non-starter. Then you can't use private names as private names.
I have read a lot of code that I have written myself and I admit that if
I wanted to switch to private names, I would make myself vulnerable to
the attacks mentionned and would be required to use closures anyway, so
as you say, I wouldn't be able to use private names as private names.
>> (One good news is that mostly static analysis
>> can assist us in finding where we may disclose 'n' in this scenario).
> When you say "static analysis can solve this" you're saying "some
> hypothetical approximation to an undecidable problem will find out all the
> places where the unstated and unwritten intentions of the programmer were
> violated. Also, despite the fact that it's mathematically impossible for such
> a tool to have both no false positives and no false negatives, it will still
> be both safe and useful." I'll believe it when I see it?
I was careful to say "assist" and not "solve".
> Besides, we shouldn't knowingly add features that will invite bugs that can
> only be found with (as yet unspecified and non-existent) additional
> development tools.
I agree.
>>> And there's no way you can fix
>>> this, without resorting to some other method of hiding things like
>>> closures.
>> I disagree, there is.
>> In the case where you want the proxy ("worst case", here "proxy" means
>> "untrusted third party") to have access to the private name, you need
>> the proxy to have access to a public->private map.
> You seem to be treating ES6 as being The Ultimate Proxy Language (with some
> additional side features).
I do not. I'm aware that proxies have benefits and positive things can
get out of them. As it turns out, they are heavily used in Firefox as
well from what I heard. It would be interesting to hear from the people
who have experience with them to know how they feel about private names
and the ".public"
> Proxies are not the common use case we are optimizing for, nor should they be.
>
> The common case we are optimizing for has nothing to do with proxies. It's
> simple stuff like:
>
> let n = Name();
> function Stuff() {
> this[n] = /* some internal stuff */;
> }
> Stuff.prototype = {
> doStuff: function() {
> ... this[n] ...
> }
> };
>
>> If each time I create an abstraction using proxies, I need a
>> public->private map, it is likely that I (and it's obviously not about
>> "me", but anyone writing proxies) won't use private names with proxies.
>> I may just use WeakMaps.
> Great -- do that! If proxy writers have to work harder to deal with the
> public/private map, so be it! I would much rather tax proxy writers than tax
> everyone else. As cool as proxies are, they are not intended to be nearly as
> common as the usual simple functions + prototypes abstractions of JS.
Have you had a look at my alternative proposal [1]? It seems to solve
all concerns raised by anyone (including me) in this thread.
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-December/018908.html
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
