[saurik]

Are you willing to describe the threat more? (I am legitimately curious, run a bunch of websites, use CDNs, may at some point have similar constraints involving also needing to host user content, and both respect and acknowledge the value of getting handed down understanding and explanations from people who have been doing things longer. ;P)

"a.google.com" and "b.google.com" are not "same origin", so cross-site scripting should fail. You can, however, have the two domains opt in to communicating with each other by having them both set their document.domain to "google.com"; does Google normally set document.domain on their pages, thereby allowing injected iframes to take advantage of this?

(I had thought the most common reason for having separate top-level domain names were due to performance and security implications involving cookies, which sometimes are scoped at the level of a domain name rather than at the level of a subdomain in order to allow sharing between related properties, such as plus.google.com and www.google.com.)

[gwillen]

I am not directly experienced with the threat involved. I know it is crossdomain-related; if you tell me it's cookies rather than JS, I'll believe you.

I have no idea whether Google normally sets document.domain, but I could certainly imagine it doing so; I feel like the "google.com" domain is one that any page under google.com is likely to believe it can trust, whether or not that trust is expressed programmatically. Certainly serving untrusted js anywhere under the google.com umbrella is likely to violate _someone_'s assumptions somewhere. I do not actually know it to be exploitable.

[Someone]

Why, then, did we get plus.google.com and not google+.com? (and aside: I find those (google.com) suffixes on HN that turn out to be links on plus.google.com confusing. For google.com URLs, I expect either search results or pages that represent google's position)