4 ms·

The global symbol registry sounds intriguing but dangerous. Does it now provide a mechanism for client side cross domain communication? The browser spends most

by zmmmmm 11y ago

The global symbol registry sounds intriguing but dangerous. Does it now provide a mechanism for client side cross domain communication? The browser spends most of its time isolating different domains, but in this instance the feature seems to be explicitly added to allow for some kind of cross domain interaction. In turn however that would seem to bring with it all the security problems of allowing it - phishing sites can frame your web site and then farm all the information out of the global symbols. Which means any use of them would have to be very careful. Does anybody have any insight on whether my interpretation here is correct?

girvo 11y ago
Iirc, there are still ways to communicate between frames (postMessage rings a bell?) -- the global symbols don't really hold any information though, and are mostly just markers that are used in the code itself :)
- tracker1 11y ago
  I'm curious if Symbols are valid for localStorage keys.. it could be used as communication channels between frames that way, I seem to remember a post for something like that, and Symbols may be a bit safer.. though not sure if Symbol.for('__my_channel__') is safer than '__my_channel__' in this case (same domain). Though the cross-domain bit is slightly interesting, I'm not really sure what the risk would be in practice.
- AdieuToLogic 11y ago
  > the global symbols don't really hold any information though, and are mostly just markers that are used in the code itself Global flags always represent information, be it to the people who code them up or attackers who leverage their existence.
  - to3m 11y ago
    I can't see any reliable extra information available, based on the description in the article. The only thing I can think of offhand: time the execution of Symbol.for. Mostly, this won't be terribly illuminating, because the bulk of the work (hashing input + looking in table) will be the same in both cases, and won't take long. But, assuming the registry is a hash table, what you could do in one script is pollute the registry with enough strings to trigger several hash table rebuilds (which you can detect by outsize results from Symbol.for - you add enough strings to provide a good representative set of timings). Then another script could detect this by doing the same operation and seeing if no call to Symbol.for took much longer than any other. This gets you 1 bit of information... is that useful? (Also, I wonder what they do about symbol table exhaustion.) As for the results, they don't themselves hold any extra information, I don't think. Regarding Symbol.for: if the table contained the requested symbol already, it will return that symbol. If it didn't, a new symbol will be added, and returned. These are the only two options, and the caller has no way of knowing which was taken. And regarding Symbol.keyFor: if the input was previously returned by Symbol.for, returns true. And if not, returns false. Neither tells you anything because the caller can only have acquired the symbol by doing one of these two operations itself, meaning it isn't getting any information that it didn't in theory have already.
  - Manishearth 11y ago
    That's the thing. The "existence" of a global symbol isn't observable. Think of `Symbol.for("foo")` as if it were the string "foo". The string "foo" is also global, when passed across iframe boundaries it still retains its meaning. One can use this string on either side. Using it doesn't observably instantiate some global flag, though internally there may be interning and whatnot. Similarly, using Symbol.for("foo") doesn't instantiate any flag, observably.
Manishearth 11y ago
Symbols are opaque aside from their tag. The global registry just means that you can have cross domain opaque identifiers which are equal; which is useful for communication.
- AdieuToLogic 11y ago
  Funny... I think I've heard this line of reasoning before: https://technet.microsoft.com/en-us/library/cc781906(v=ws.10).aspx https://technet.microsoft.com/en-us/library/cc781906(v=ws.10...
  - Manishearth 11y ago
    Global symbols can be thought of as "keys which always existed" and they don't have values. You can't determine if a global symbol is being used by another frame. They just ... exist.

by zmmmmm 11y ago

girvo 11y ago

Iirc, there are still ways to communicate between frames (postMessage rings a bell?) -- the global symbols don't really hold any information though, and are mostly just markers that are used in the code itself :)

tracker1 11y ago
I'm curious if Symbols are valid for localStorage keys.. it could be used as communication channels between frames that way, I seem to remember a post for something like that, and Symbols may be a bit safer.. though not sure if Symbol.for('__my_channel__') is safer than '__my_channel__' in this case (same domain). Though the cross-domain bit is slightly interesting, I'm not really sure what the risk would be in practice.
AdieuToLogic 11y ago
> the global symbols don't really hold any information though, and are mostly just markers that are used in the code itself Global flags always represent information, be it to the people who code them up or attackers who leverage their existence.
- to3m 11y ago
  I can't see any reliable extra information available, based on the description in the article. The only thing I can think of offhand: time the execution of Symbol.for. Mostly, this won't be terribly illuminating, because the bulk of the work (hashing input + looking in table) will be the same in both cases, and won't take long. But, assuming the registry is a hash table, what you could do in one script is pollute the registry with enough strings to trigger several hash table rebuilds (which you can detect by outsize results from Symbol.for - you add enough strings to provide a good representative set of timings). Then another script could detect this by doing the same operation and seeing if no call to Symbol.for took much longer than any other. This gets you 1 bit of information... is that useful? (Also, I wonder what they do about symbol table exhaustion.) As for the results, they don't themselves hold any extra information, I don't think. Regarding Symbol.for: if the table contained the requested symbol already, it will return that symbol. If it didn't, a new symbol will be added, and returned. These are the only two options, and the caller has no way of knowing which was taken. And regarding Symbol.keyFor: if the input was previously returned by Symbol.for, returns true. And if not, returns false. Neither tells you anything because the caller can only have acquired the symbol by doing one of these two operations itself, meaning it isn't getting any information that it didn't in theory have already.
- Manishearth 11y ago
  That's the thing. The "existence" of a global symbol isn't observable. Think of `Symbol.for("foo")` as if it were the string "foo". The string "foo" is also global, when passed across iframe boundaries it still retains its meaning. One can use this string on either side. Using it doesn't observably instantiate some global flag, though internally there may be interning and whatnot. Similarly, using Symbol.for("foo") doesn't instantiate any flag, observably.

Manishearth 11y ago

Symbols are opaque aside from their tag. The global registry just means that you can have cross domain opaque identifiers which are equal; which is useful for communication.

AdieuToLogic 11y ago
Funny... I think I've heard this line of reasoning before: https://technet.microsoft.com/en-us/library/cc781906(v=ws.10).aspx https://technet.microsoft.com/en-us/library/cc781906(v=ws.10...
- Manishearth 11y ago
  Global symbols can be thought of as "keys which always existed" and they don't have values. You can't determine if a global symbol is being used by another frame. They just ... exist.