I wonder how exactly this works. I'm guessing 1e100.net has various subdomain names that can correspond to different Google servers (i.e. Youtube.)
Edit: Apparently different subdomains correspond to different IP addresses. For example, gx-in-f191.1e100.net points to 220.127.116.11 and qw-in-f18.1e100.net points to 18.104.22.168.
Besides, even if we picked some other domain you'd still need to look it up to determine whether it was actually us or someone pretending to be us.
Actually, you should be careful about that.
There is malware floating around that connects to 1el00.net, le100.net, etc. (replacing the numeral 1 with the letter L, which looks virtually identical in the lower case you find in netstat etc.). I don't know what data it exchanges with those servers.
This is actually a really clever move on the malware-author's part. All of the "OMG! I have a virus." and "Don't worry it's Google" threads you see online add significant confusion.
Moreover, they seem to have used their bot-net to bury information about the malware in search results, as you can see by searching for "1EL00.net", etc.
The creators of this malware were actually pretty clever about it (there are more layers of obfuscation at play). I encountered an infected machine and once I saw the layers of trickiness involved, I went for the nuclear option and completely wiped the machine. They seemed to be smarter than me (and for that matter, existing AV software) about this.
"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.)
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.
Some of these problems are addressed by modern browsers and other techniques, but getting good performance out of the median web browser remains a big challenge.
And 1e100.net is a lot shorter than googleserver.com, which can make a fairly significant bandwidth saving for pages which contain a lot of URLs. Have you ever noticed that Facebook used fbcdn.net and Yahoo uses yimg.com for their CDNs? There are several reasons for using separate domains for their CDNs (security, to ensure that cross domain policies apply, bandwidth, to ensure that you don't send cookies to something that will just be serving up static images), but using a separate domain does mean that your URLs are longer, which on a high traffic, highly optimized page, can be a fairly substantial portion of the page content.
Finding a good, short, and descriptive alternate domain can be hard. 1e100.net is really not much worse than yimg.com or fbcdn.net.
1e100 has a lot of characters than can easily be misread.
When you see a connection on tcp/443 to ec2-50-29-151-90.compute-1.amazonaws.com, how do you know if that is a botnet connection or not?
1600 Amphitheatre Parkway
Mountain View CA 94043
Assuming "all these obscurely named TCP connections" means 1e100 hostnames, why exactly did you need to do this for "each one", why was this such a time sink, and how would "googleserver.com" be any more implicitly trustworthy?
Also, I don't recall using the /surprised/ tag in my post.
It looks like there is actually some fairly interesting technical story behind this...