Symbols, Protocols, Frames, and Versioning

David Bruant bruant.d at gmail.com
Thu Oct 4 01:52:58 PDT 2012


2012/10/4 Brendan Eich <brendan at mozilla.org>

> David Bruant wrote:
>
>> Unforgeability can be given up, but you end up with global namespaces.
>> new Symbol("21fef4ae-1439-4b6a-**b412-3585906b35f1"); or
>> "org.ecmascript.system.**iterator"
>>
>
> This is no better than dunder-iterator (I mean '__iterator__', I just like
> typing dunder- ;-), or just 'iterator' (what Firefox uses currently).

I agree it's the exact same thing.


>
>  I've faced an equivalent problem recently, so I wish to take this
>> occasion to share an idea on how to fix the awful security policy of
>> local storage.
>> An alternative design would be that instead of defaulting to Same-Origin
>> Policy, we'd say that storages are only available initially to those who
>> create it and who the creator shared it with.
>>
>
> Ocap, yay! [sincere here]

Caught.
The discovery of Ocaps and more generally POLA (Principle Of Least
Authority) fundamentally changed the way I reason about programming
especially when it comes to security.



>
>       var s = new Storage();
>>      s.secret; // serializable identifier
>>      // send the identifier to anywho is trusted like another frame or a
>> server
>>
>>      // in another frame/tab/window (of the same browser obviously)
>>      var s = Storage.get(secret);
>>      // same storage regardless of the origin
>>
>> Trust domain is no longer "Same-Origin" but rather "whoever knows the
>> secret id *regardless* of the origin". The secret can even be hidden
>> from same-origin pages. Useful when webservers hosts content from
>> different people; at my school, people had
>> http://www.enseirb-matmeca.fr/**~bruant<http://www.enseirb-matmeca.fr/~bruant>addresses. Creating one page, I
>> could have stolen the local storage of my school domain anytime.
>>
>
> Yes, old prob with same-origin. Remember jwz.livejournal.com? The fix
> costs in subdomains.
>
Actually, that's the biggest problem I have with the local storage spec. It
basically tells you how to organize your URLs. That's an absurd demand from
a feature which "only" aims at storing data in the user agent.
Hopefully, no other spec imposes such a constraint. Hopefully, no other
spec imposes *contradictory* constraints about URLs...

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


More information about the es-discuss mailing list