Lecture series on SES and capability-based security by Mark Miller

David Herman dherman at mozilla.com
Tue Nov 8 20:23:54 PST 2011


And another silent semantic change? I wouldn't be so quick to do that. And that's not the direction we were going for __proto__ in the last f2f.

I *wish* __proto__ were just treated as another normal property. And I'd like for us to work towards a future where that's the case. I'm just skeptical we can do it by cramming it into strict mode.

Dave

On Nov 8, 2011, at 3:50 PM, Mark S. Miller wrote:

> 
> 
> On Tue, Nov 8, 2011 at 3:46 PM, Mark S. Miller <erights at google.com> wrote:
> 
> 
> On Tue, Nov 8, 2011 at 3:33 PM, David Herman <dherman at mozilla.com> wrote:
>> Perhaps __proto__ should not be writeable in "use strict"?
>> 
>> That's a great idea! This never occurred to me, and I have not heard anyone suggest this. Thanks!
> 
> Doesn't work.
> 
>     obj[(function(__){return __ + "proto" + __})("__")]
> 
> If the "[" above is a strict "[", it should not be able to address "__proto__", regardless of whether the  "__proto__" is computed or not. Or if we intend only to suppress writing, then
> 
>      obj[(function(__){return __ + "proto" + __})("__")] = {}
> 
> should still fail if the "[" above is in strict code.
> 
> Sorry, it should not fail. It should simply create a normal property that happens to be named "__proto__". Likewise, your first example should simply address such a normal property. Then JSON would again be an almost-subset of ES5/strict, modulo \u2028 and \u2029.
> 
>  
> 
>  
> 
> Dave
> 
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111108/81abac31/attachment.html>


More information about the es-discuss mailing list