Live data from Hacker News

My Chromecast Ultra would not start until I began answering 8.8.8.8

mailarchive.ietf.org

241–250 of 519 posts

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

#241
post #205

Earlier quoted context omitted.

> it can report the problem to the user How? And what should the user do with that information? This device is not architected for users who know what DNS, DHCP, or TLS are, much less who care.

> This device is not architected for users who know what DNS, DHCP, or TLS are, much less who care. The only technical data I suggested showing the user was an optional "technical details" popup, for the rare cases when someone (perhaps you ) actually was interested in that information. > How? Iff there is a useful UI, the same way they show anything to the user. I suggested automatically failing over to the hardcode…

That seems to add a lot of logic and interaction complexity to work around a problem that is only a problem for people who already have the technical skill to remap 8.8.8.8 to their preferred DNS server anyway.

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

#242
post #178
post #168

Yeah. I know we'd all want to believe that the response and reaction here would be the same if it was pointed to 1.1.1.1, but... yeah, we know better. Everyone would point out that consumer ISPs server polluted data and that Cloudflare clearly provides better service, and relying on that instead of the local garbage is quite obviously a benefit to the device user. But this is Google, and people here have iPhones, so…

It's not unreasonable to attempt to use DHCP provided DNS servers. It's not unreasonable to use fallback DNS servers when the DHCP provided servers don't work. It would be a bit strange, but maybe not altogether unreasonable to run a fully recursive DNS client with root.hints and what not. I guess you could argue over reasonableness of favoring the fallback DNS over DHCP. It's not reasonable to ignore DHCP when the f…

[deleted]

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

#243

Earlier quoted context omitted.

First they came for the appliances I don't want or need, because I don't use appliances I don't want or need. This has been discussed to death. Slippery slope, etc., etc.

I disagree. People who care about not hitting 8.8.8.8 simply do not own a Chromecast.

Not really, before you could firewall it off from the rest of your network - though now you can just masquerade 8.8.8.8 and 8.8.4.4 to your DNS server of choice

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

#244

This should bother people here more than it does. The last thing the Internet needs is even more dependence upon Google. They've made it quite clear through their actions that they're not supporters of a free and open Internet: https://theintercept.com/2018/09/14/google-china-prototype-l... If people don't push back against these kinds of things, Google will continue to abuse their power. There shouldn't be an army o…

It doesn't bother me because it's a Chromecast, an appliance I don't want or need. If I needed something similar, I could get it from other manufacturers.

I think the idea is that getting Google to fix this by telling them this is unacceptable is a swifter course of action than hoping Google will notice your individual $35 purchase went elsewhere.

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

#245

Just the fact that you can't cast your own local content when the mothership is down makes me want to throw out all cast devices. Ignoring DNS servers seems like a very minor issue.

Have you verified you can't cast your own local content if 8.8.8.8 is down? I thought it did a fallback.

I've not tried it myself, but the title does say the device won't start without it.

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

#246
post #231
post #201

Earlier quoted context omitted.

Where do they announce all the other IPs that need to be reachable in order to access YouTube? Why is the dependency on 8.8.8.8 being reachable somehow more annoying than the rest?

Well there are nearly infinite ways to route traffic to/from YouTube.com, that is how the internet works. However for this product there is a very hard dependency on this one specific IP address, which isn’t documented and is pretty unreasonable

> Well there are nearly infinite ways to route traffic to/from YouTube.com, that is how the internet works.

I'm talking about the endpoint. YouTube.com resolves to a finite set of IP addresses, and accessing YouTube requires that outgoing traffic is allowed to all of them. All of this is entirely under the control of Google, so how does adding one small additional dependency on 8.8.8.8 affect the end user's control in any way? It's just one more IP address that has to be allowed to be able to use YouTube, and it's equally as documented as the others (i.e. not documented at all).

Additionally, 8.8.8.8 uses anycast routing to distribute the requests over many servers. So it's not like having "one fixed IP" is any worse than having one fixed domain, as you seem to be implying. It's not a single point of failure.

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

#247

DNAT 8.8.8.8:53 back to your own DNS server.

Came here to say exactly this. Why even make a fuss about it? Bro, do you even NAT? The argument is Google can record what you're sending your Chromecast. Well, (sorry for the crudeness) no shit... You're using Google hardware. If you're going to act like the DoD and not use Huawei switches, then don't use Huawei switches. If you so choose, you must look at Google as malevolent as the US DoD would see an attacking na…

Cool, I'll be sure to tell my mother-in-law that if she's concerned about her privacy, she just needs to use NAT "bro".

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

#248

Earlier quoted context omitted.

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...

> No, that's not how it worked Yes, it is; Chromecast activation has always used the Chromecast itself as the WiFi host; you have to do that to even set it up to use another network. > 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). TV apps can do that because the TV device is already co…

(OP of complaint)

This matches my understanding as well.

05's answer about security and rogue devices is a good one. It makes a lot of sense. For my (and I expect most people's) threat model, google's prying eyes are a more credible concern than my neighbor's, and I wish they hadn't changed it, but it's nonetheless a defensible reason for making the change.

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

#249
post #158

Earlier quoted context omitted.

You are missing the point, it's not that they first try 8.8.8.8 then falling back to ISP/defaults, they are requiring 8.8.8.8 for DNS which is BS.

If they would fallback to the ISP's DNS server they'd encourage the ISP to block access to their DNS, which arguably would be even worse.

Honest question: is that even legal?

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

#250
post #220
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..

Thank you for this answer. It makes a lot of sense. For my (and I expect most people's) threat model, google's prying eyes are a more credible concern than my neighbor's, and I wish they hadn't changed it, but it's nonetheless a defensible reason for making the change.
Post reply on HN