Google acknowledges XKCD #1361 A TXT record query on Google's 8.8.8.8 DNS server returns a link to xkcd 1361: $ dig +short TXT google-public-dns-a.google.com "http://xkcd.com/1361/" |
Google acknowledges XKCD #1361 A TXT record query on Google's 8.8.8.8 DNS server returns a link to xkcd 1361: $ dig +short TXT google-public-dns-a.google.com "http://xkcd.com/1361/" |
Heck, I even have it aliased as "pg" on all my systems.
dig +short TXT google-public-dns-a.google.com
by the way, the "http://xkcd..." part is the response, but since @asdafa didn't put \n\n after the command, it's appearing at the same line.
Turns out there are clever ways of (mis)using DNS features to make money. For example, your server could hijack NXDOMAIN responses and instead direct the user to a nice page that tells them that the name couldn't be resolved alongside a couple relevant advertisements.
This may actually be true, as google believe's that if you arrive faster to a website after searching on Google you will use Google more
Also, at the scale Google operates, I am not sure that DNS is that big of a resource commitment, and it may allow them to do fancy traffic routing stuff for their own services.
It is also a DNS server.
In that blog post, and in a technical note sent to data protection authorities the same day, we said that while Google did collect publicly broadcast SSID information (the WiFi network name) and MAC addresses (the unique number given to a device like a WiFi router) using Street View cars, we did not collect payload data (information sent over the network). But it’s now clear that we have been mistakenly collecting samples of payload data from open (i.e. non-password-protected) WiFi networks, even though we never used that data in any Google products.
-- http://googleblog.blogspot.co.uk/2010/05/wifi-data-collectio...
Possibly a debug option to log the whole packets added during development, and it was accidently left on in production.
Or the whole packet was always logged, a second process would then skim just extracting the SSID/MAC (correlating with GPS), and another process was deleting the raw logs. That third process failed.
A few big drives in teh data collection devices, and possibly nobody noticed where filling up a little too quickly.