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/" I thought Google's core product was allowing "ping -t google.com" ICMP traffic to be the central monitor of my network connectivity and latency to the internet. Heck, I even have it aliased as "pg" on all my systems. Time was, that was Sun's core product... Is this a paul graham joke? ping google pingoo The command is only: 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. They probably did put it in but forgot about markdown. That is exactly what happened :( Maybe a stupid question, but is it monetized somehow? I mean DNS servers. After all, it's a pretty heavy load… I still don't really understand what is (is known to be) monetizable and what isn't. I guess, for Google at least, getting all DNS requests of their users is worth paying for a popular DNS server. That's how they know which sites your like even if those sites don't use Google Analytics. Wow, that's really good idea. So obvious after you said it, but I absolutely didn't think of it! So if I want to bias their search in favour of my favourite sites, I should use their DNS? Sure, they benefit by getting valuable data on Internet traffic. For another example of DNS server monetization, see http://opendns.com/. 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. NXDOMAIN hijacking is what OpenDNS does. People use Google much more if they can access it fast, which means more revenue. A lot of ISPs have slow DNS servers, and Google needs a good production DNS server for internal purposes anyways, so it was not that hard for the engineers to make it a public project. >We built Google Public DNS to make the web faster and to retain as little information about usage as we could, while still being able to detect and fix problems. Google Public DNS does not permanently store personally identifiable information. 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 What could Google possibly do with people telling them every website they are visiting? 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. They could use it to build more accurate profiles of their users in order to monetize them. > We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services. Interesting. I tend to believe it for some reason, although I don't know why myself. Does somebody really check if such promises are true? Are they trustworthy? It reminds me, that case with collecting wifi traffic — how did it get revealed at all? Nine days ago the data protection authority (DPA) in Hamburg, Germany asked to audit the WiFi data that our Street View cars collect for use in location-based products like Google Maps for mobile, which enables people to find local restaurants or get directions. His request prompted us to re-examine everything we have been collecting, and during our review we discovered that a statement made in a blog post on April 27 was incorrect. 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... How do you _mistakenly_ collect "samples of payload data"? Someone mistakenly wrote/used a packet logger, compiled/installed it on the Street View cars and mistakenly executed the service to be running in the background? How does that happen? The logger was obviouslly there, it was deliberatly collecting the SSIDs and MAC addresses. 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. They also don't work with the NSA. Define "work with" I have no idea, that's why I'm asking. And as you can see there turn out to be some pretty good answers to that already. He was being sarcastic. The funny thing is I had to blackhole 8.8.8.8 on my home router earlier this week because of a change in the Netflix app on the Roku. Why won't people just take my money? What's the 8.8.8.8 server? Google's core business. Google's ping-back server. It is also a DNS server. Do NOT forget 8.8.4.4! The tooltip is an integral part of xkcd. ROFL! I did not know this. To be specific if you are not an XKCD reader: hover your mouse over the comic for a second punch line. Or if you are on mobile m.xkcd.com/<number> Damn, now you have to start from the start and pick up on all those missed jokes. Clickable link for those like me who haven't read it. http://xkcd.com/1361/ it's also a DuckDuckGo instant answer (any xkcd comic) https://duckduckgo.com/?q=xkcd+1361