Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Chromecast Ultra would not start until I began answering 8.8.8.8

mailarchive.ietf.org

Post reply on HN
Print view View original

221–230 of 519 posts

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#221

Post by pdkl95 »

CivBase wrote: post #101
mankyd wrote: post #95

Earlier quoted context omitted.

https://developers.google.com/speed/public-dns/privacy > 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.

Fair enough.

That page is full of doublespeak. They claim they "don't keep personally identifiable information or IP information" in the permanent logs, but then go on to explain how they log everything else that you would need to track someone. In addition to saving everything about the DNS query itself (domain, record type, etc)j, they also admit to logging (quoting from the above URL):

* Client's AS (autonomous system or ISP), e.g. AS15169

* User's geolocation information: i.e. geocode, region ID, city ID, and metro code

* Absolute arrival time in seconds

While Google's AS that the use as an example is huge[1], sometimes the AS is very revealing[2] and only map to a few addresses[3]. Combined with the geo-data, if you're on a smaller AS, Google has better tracking data than the IP address that is easy to correlate back to unique users[4].

As for their claim that "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."

There is a lot of carefully chosen language in that claim. You didn't "provide" them with the AS number or geo-data; they looked that stuff up based on your IP address. How are they defining "personal information", and exactly what counts as "provided Google for other services."? These are totally undefined terms and companies have a tendency to evolve their definitions of important-but-not-strictly-defined terminology as the Overton window shifts and bad behavior becomes sufficiently normalized that they can use the "everybody is doing it" excuse.

But looking at it in terms of what they currently say misses the larger problem: unless they have shown that their ability to amend this policy is restrict by a Ulysses Contract[5][6], they can change their policy at any time. They can also have the policy changed by an external power, against their will (e.g. a court could order them to start logging (w/ a timestamp) who communicated with them[7], even if they didn't want to.

[1] "IPs Originated (v4): 8,717,056" https://bgp.he.net/AS15169

[2] Google is admitting to logging which entry on this list each DNS requests originated from (warning, big page, only has US data): https://www.whatismyip.com/asn/US/

[3] "IPs Originated (v4): 256" https://bgp.he.net/AS54007

[4] https://news.ycombinator.com/item?id=17170468

[5] https://en.wikipedia.org/wiki/Ulysses_pact

[6] https://www.youtube.com/watch?v=zlN6wjeCJYk

[7] https://en.wikipedia.org/wiki/Pen_register (or a NSL, etc)

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#222

Post by apostacy »

scrollaway wrote: post #50
apostacy wrote: post #43

Earlier quoted context omitted.

This isn't a case of an IOT device though. My Chromecast went through massive amount of trouble to use Google's DNS servers, to serve ads behind my pi-hole. It would respect all of my DHCP parameters, but silently ignore DNS settings. It was clearly intentional to serve ads. I had to set up a firewall to force it to use my DNS server. And eventually even that stopped working with an update (which themselves are reall…

I can't really entertain the suggestion that pi-holes are considered by Google as a serious-enough threat that they'd go through this trouble just to fuck with it. Seriously, think about the venn diagram of Chromecast users and pi-hole users. It looks a lot like a tennis ball being dropped into the sun.

Um, the pi-hole wasn't specifically targeted. They just wouldn't accept anything other than Google's DNS. Some ISPs will do DNS hijinks too, like transparently intercepting port 53 traffic and re-routing it.

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#223

Post by AlphaSite »

matz1 wrote: post #156
joekrill wrote: post #113

Earlier quoted context omitted.

OK but if that "known good" DNS server goes down or isn't available, you still have others you can fall back to. The device shouldn't just become completely useless. But that's what Google is doing here. It's their DNS servers or none, it seems.

To me its a reasonable trade off, the probability the google DNS server goes down is low and the amount of people who purposely block google dns is also low.

My company blocks google dns.

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#224

Post by cma »

tialaramex wrote: post #35
megous wrote: post #22

Earlier quoted context omitted.

Yes, but how does it help hardcoding one IP address that ISPs can simply route to their own DNS server?

Today the ISP could, with a bunch of effort, re-route the traffic, though I haven't seen any evidence that any of them do that. So it helps materially because for today it works. Tomorrow these devices will do DPRIV, probably DNS over HTTPS, and so the ISP won't be different from any other man-in-the-middle, unable to meddle with the contents of protected traffic.

They could keep routing it and modify it's results. Comcast already does this with http, injecting datacap warnings into HTML pages.

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#225

Post by joshuamorton »

llukas wrote: post #217
joshuamorton wrote: post #142

Earlier quoted context omitted.

Yes. They don't. They guarantee they don't. The spooky answer is they don't need it.

This guarantee is one TOS change away from vanishing...

Then they'd need to announce that to all of the users of their DNS service.

You tell me how to do that.

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#226

Post by AnIdiotOnTheNet »

Arnt wrote: post #148
joekrill wrote: post #113

Earlier quoted context omitted.

OK but if that "known good" DNS server goes down or isn't available, you still have others you can fall back to. The device shouldn't just become completely useless. But that's what Google is doing here. It's their DNS servers or none, it seems.

I too have written code that asks 8.8.8.8 and 8.8.4.4, because the DNS server I get from DHCP frequently is so brain-damaged. (SRV records, what's that?) I asked both in parallel. On one hand it feels wrong to not ask in parallel. On the other, $%#@%#$%!$@# the %$#%#$%^$#@%#$! packet filters that block DNS packets to everyone except the local brain-damaged resolver. Or even redirect. If Google will fight that fight I…

As someone who has had to block and redirect DNS traffic, there are reasons we do this and if you have a problem with it then you should contact the admins about it. If you're unwilling to do that, maybe you shouldn't be doing what you're trying to do at work.

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#227

Post by mthoms »

jrockway wrote: post #154
alias_neo wrote: post #140

Earlier quoted context omitted.

This is how I solved it. Someone above says an update prevented this somehow, though.

It seems unlikely to me that the DNS client has the sophistication to know that it's not Google's 8.8.8.8 that it's talking to. That would be a nightmare to maintain; the 8.8.8.8 team changes some implementation detail, and then all Google clients stop working (and are now unable to update because they refuse to resolve DNS names)? I doubt they implemented that because it's crazy.

>It seems unlikely to me that the DNS client has the sophistication to know that it's not Google's 8.8.8.8 that it's talking to

I don't know much about DNS but based on what I do know I would think this to be trivial(?). All you'd need to do is make a request for a domain that doesn't exist. Something like "is-this-google-dns-im-connecting-with.google" or .com. Google DNS could be coded to respond accordingly.

So no DNS response, or not the response you were expecting = not Google DNS.

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#228

Post by barrkel »

eertami wrote: post #164
unethical_ban wrote: post #139

Jared Mauch's response was pretty rude. I don't mind defaults, but I do not like the inability to change. I wonder if it was clearly documented as a device requirement that 8.8.8.8 was needed. All prerequisites of function should be in the Quick Start Guide of the tool in question. Furthermore, users aren't always in control of the firewall/ACL on their network. If I go to Jack's Organic Coffee for a meeting and they…

Maybe I'm missing the forest for the trees but... what possible reason would you have for taking a Chromecast to a coffee shop?

Not a coffee shop, but certainly a hotel room, to cast some entertainment on the TV rather than rely on a laptop.

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#229

Post by jaredmauch »

nabakin wrote: post #195
C1sc0cat wrote: post #185

Earlier quoted context omitted.

You must have lead a sheltered life if you think this is "pretty rude". Its blunt and to the point I will give you but really

You don't have to be sheltered to think it's rude. This feels like an attack, please stop.

You also maybe should know that I could have texted that to him as well. It's not as if we don't know each other.. i may have even been to his home previously :-)

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#230

Post by djrogers »

05 wrote: post #220
RickS wrote: post #212

More concerning to me was the fairly recent removal of non-phone-app setup. It used to be that a chromecast would display a 4 character code on screen, which could be used to activate it from the browser. Now, they require that it be managed with the google Home app, and have discontinued the method that allowed chromecast use without installing additional google software on your phone. This made for a really dishear…

The obvious reason is that any local browser config pages cannot be SSL protected because the device can not provide a valid certificate for 192.168.0.33 or chromecast.local Phone app can use a custom TLS CA to make sure the stick was produced by Google and is not a rogue neighbor phishing for your WiFi password..

No, that's not how it worked - you got a code on the screen you could use to activate the device with google from any browser - much like many many many TV apps use (visit foo.com/activate and enter code NNNN). You weren't browsing to any local devices...
Post reply on HN