Symbols, Protocols, Frames, and Versioning

David Bruant bruant.d at
Wed Oct 3 15:39:41 PDT 2012

Le 03/10/2012 23:09, Brendan Eich a écrit :
> Domenic Denicola wrote:
>> Would it suffice to allow cross-frame sharing of symbols via
>> postMessage and its structured clone algorithm? They're immutable,
>> right?
> They are immutable but you'd still have to pass your @iterator to
> another same-origin frame, and then have to use it carefully when
> iterating objects from the first frame. This is unusable.
> Making @iterator a singleton (to the limits of observability:
> same-origin, CORS, out-of-process-via-DOM in IE9+
> notwithstanding!) can be done. That wins, no need to pass and use the
> other frame's @iterator symbol.
> But how to let users create such singletons?
I concur with Kevin's analysis. Global namespace or it's not possible.
The problem to be solved is to have 2 independent ECMAScript
environments "creating" (or rather retrieving) the same unforgeable
item. It's just not possible.
If you create something in an ECMAScript runtime it's initially fully
local, there is no way another runtime can know about it without
providing authority that could be otherwise abused.

Unforgeability can be given up, but you end up with global namespaces.
new Symbol("21fef4ae-1439-4b6a-b412-3585906b35f1"); or

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.

    var s = new Storage();
    s.secret; // serializable identifier
    // send the identifier to anywho is trusted like another frame or a

    // 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 addresses. Creating one page, I
could have stolen the local storage of my school domain anytime. It
makes the feature basically unusable for such cases.
It's the global identifier pattern. Local storage secrets needs to
transfered from server to client to recover the storage securely. Of
course, the secret needs to be sent over HTTPS :-)

The private symbol has been replaced by a storage instance, but it's the
same problem, I think.

For that matter, I've started a prototype implementation [1]. I have all
ideas straight, but the prototype isn't functional yet. I need to hack
on DNS (which I know nothing about); if anyone is interested in helping
on that, I'll be happy of the help.



More information about the es-discuss mailing list