My Chromecast Ultra would not start until I began answering 8.8.8.8(mailarchive.ietf.org) |
My Chromecast Ultra would not start until I began answering 8.8.8.8(mailarchive.ietf.org) |
No way Im turning pihole off, and Im not gonna get a legit router setup to reroute 8.8.8.8.....
He may want to consider an alternative product. Or use his 1337 hacker skills to modify his already-customized local routing configuration to just do the thing this consumer electronics device is assuming is standard (i.e. accessing services by IP on the Internet) by telling his network to proxy 8.8.8.8 to some other IP he designates.
He of all people should understand that the practical implementation of DNS and DHCP has become so broken by bad-acting ISPs that consumer electronics devices end up side-stepping the spec entirely so the thing works for the common consumer user.
Providing a DNS server via DHCP is insufficient as many IoT devices ignore it for tracking purposes. Similar deal with blocking port 53 outbound, they just refuse to work.
[1]: https://pi-hole.net/
Never fails to make me chuckle.
I like to use a BSD based router and a PF firewall. My solution:
match in on $i inet proto udp from any to !($i) port {53 123} rdr-to ($i)
The gateway has daemons listening and caching requests for performance. The client has no idea this is happening.
It works great for me.
As others have said though, who buys a Google device thinking it's not gonna talk to Google?
So I don't believe the OP, even though it's the living legend that is PV.
Maybe my router masquerades the dns port and answers vs blocking other dns outright?
Google is literally cartoonishly evil at this point. That slogan of theirs is an absolute joke.
I can see why you would want to use a known-good dns provider in your product, however at the very least there should be an ability to turn off such behaviour.
It is me. My resolver does that and it is for a reason. Disrespecting what the local network tells you to use just leads to arms race.
Yes, to track you better.
https://googleblog.blogspot.com/2009/12/introducing-google-p...
Kind of like they started Knol to compete directly with Wikipedia.
People who buy little internet devices usually don't respond well to "it's your ISP" when their day-to-day web browsing experience is just fine to them.
If your resolver does that, you're going to be the 0.01% that complains, rather than the 2-5% that is crushing customer support.
Not saying that makes it "right", just saying it fixes it.
However, that quick fix does a damage. Why don't you use it just like a fallback. Why use it, when everything works right?
One of the most common complaints we get is that things "are slow to start" or that "I click and it's slow to respond". After long and expensive remote diagnosis, this turns out to be slow DNS, and 8.8.8.8 fixes it. Falling back to it wouldn't change the user experience.
It sucks that customization was damaged in the arms race, but that's the nature of measure-countermeasure in web technologies across the board. Every web technology is a three-edged sword: the spec, the intention behind the spec, and the real-world implementation of the spec.
DNS / DHCP implementation drifted from intention years ago.
No need to drag letsencrypt and co into the game, that's only for publicly facing machines.
(I’m a fan of local DNS for many reasons and so I think DoT is two steps forward for privacy and 3 steps backward for everything else)
So the pihole community is tiny, but that may be the reason, why Google thinks that they are worth the sacrifice: after all, there is just a few of them.
On top of that, Virgin Media resolver managed to go offline particularly regularly.
So here we are: what user sees is that a particular device doesn’t work, while others do. So they obviously blame the ones adhering to standards.
With DoH, it will be more difficult, but still possible - you will have to run your own proxy. I imagine, that folks that came up pihole, will package something similar that includes proxy.
On such networks, devices that won't allow to enroll custom certificates won't get onto Internet. It is then up to the user, what he or she prefers, privacy and control or that specific product.
I actually like DoT a DoH as protocols, from the privacy point of view. However, I don't like their implementations and the lockdown they are used for, where they try to establish the tunnel out of the local networks, taking control out of their owners.
In the future, if it would need one to resolve domain names, I guess it won't get onto Internet without it, then. It was just around 30 euro anyway.
If people don't push back against these kinds of things, Google will continue to abuse their power. There shouldn't be an army of apologists here making excuses for them.
As far as a solution goes, they can simply make 8.8.8.8 a fallback when something goes wrong. It's a disturbing trend to see them forcing things like this upon users.
Mention this online, and you will get a torrent of people telling you that you must be doing something wrong, and even if it is true Google probably has a good reason that is just beyond our understanding.
I just talked about my experience with Chromecast here a few hours ago in another thread. [1] The Google product forums are way worse.
It is not reasonable that I should have to do packet injection to not let my Chromecast connect to Google's DNS servers, especially if I just want to watch locally streamed videos.
Google has slowly been carving features off of the Chromecast for the last four years. I only use it for local video content, so why must I update when it has burned me in the past?
What really kills me is how we wouldn't let Microsoft or Facebook pull this crap.
Watching Big G's actions over the last few years, I've sometimes wondered if it's laying the groundwork to fork the internet.
People talk about China and Russia's actions balkanizing the internet. But I have a sense that Google could do it, as well, and bring us back to the days when people didn't know the difference between the real internet and America Online.
Wonder no more as that is the end goal.
Nothing less than becoming the new Ma Bell can be considered success.
Would that mean that my internet would no longer have Googly stuff on it? I could get behind that.
This doesn't change that? It's a google streaming device that in order to function at all requires a connection to google's data centers.
Why does it matter if that connection happens via 8.8.8.8 or some other IP resolved by a different DNS server? What is the actual, practical difference of that? It's still connecting to Google in order to provide the singular feature of the device. And if you didn't want that, then don't buy the product? It's not exactly surprising that an internet streaming stick requires connecting to the product's cloud services, is it?
If they hardcoded some other google IP and it wasn't a DNS server at all, would that still bother you to the same degree? Would you still be ranting about a "free and open internet"? If not, then your objections in this case are probably misguided to say the least. Because this is really just an implementation detail of the Cast device connecting to the Cast servers. It doesn't change your privacy. It doesn't change the shape of the internet. It doesn't change anything significant. And if you really, desperately care for some reason you can route 8.8.8.8 wherever you want.
Otherwise by blocking 8.8.8.8 you're breaking the free & open nature of the internet. You've done the thing you're ranting against and censored the internet.
It is in fact strange that a device that facilitates streaming from a variety of servers needs to resolve a particular dns server to function. Its obvious that it should need to resolve SOME dns server to function but not a particular one.
Clearly it can't update if it can't talk to google but why shouldn't it be able to play local content or stream netflix without talking to a particular google IP?
By controlling the DNS server, user can early point doubleclick.net, google analytic to 0.0.0.0. That might be why google wants to control that in the Chromecast.
It is a continue war between Jedi the Hackers and the Empire. The young Anakin Skywalker - Do no evil Googlers have felt the (share holders) power of Dark Side. The power felt stronger as the G stock price kept going up.
BTW, one can also config a raspberry pi / openwrt device to have subdomain ip of 8.8.8.8 and still resolve the doubleclick.net or all other tracking websites to 0.0.0.0.
May the source be with you.
By replacing parts of the internet that were open with non-open solutions, the intent and the consequence are clear.
But I will say that that bridge has been crossed long ago. 8.8.8.8 has been hardcoded in so many places today that it may as well be a fixture of the internet, like the search thing, like many other properties of Google that are maybe not monopolies but are 80% of one. There is no internet that does not depend on Google (except in certain Firewalled countries). It's already too late.
Why does it need to depend on Google Cloud at all? Sure, Google connectivity can enhance it, but you don't need Cloud to make a device like this useful.
Same thing with the Title routers, where your local network collapses if the Cloud has a problem.
Which reminds me of:
> Secretary of State Hillary Clinton on Thursday called for uncensored Internet access around the world. Among other initiatives, Clinton said the U.S. government will meet next month with network services companies to advance "Internet freedom."... In remarks aimed at the business community, Clinton said companies shouldn't yield to pressure from foreign governments to censor themselves or violate human rights. She urged companies to resist such pressures even if it means losing business in those countries, and argued that a principled stand would be good for business over the long run... Clinton said the State Department will host a meeting in February with network services companies to address the issues around Internet freedom. (from https://www.business-humanrights.org/en/hillary-clinton-says...)
> Increasingly, U.S. companies are making the issue of internet and information freedom a greater consideration in their business decisions. I hope that their competitors and foreign governments will pay close attention to this trend. The most recent situation involving Google has attracted a great deal of interest. And we look to the Chinese authorities to conduct a thorough review of the cyber intrusions that led Google to make its announcement. And we also look for that investigation and its results to be transparent.
https://2009-2017.state.gov/secretary/20092013clinton/rm/201...
Chris Messina, open web advocate at Google at the time, was present (check his website now http://chrismessina.me/b/13865613/leaving-google).
edit: damn... almost ten years ago.
Let's ignore the fact that every other tech company such as Microsoft and Apple are in China, and the fact that Google already does censor content in most other countries. Let's also ignore all the other things Google does for OSS and the web.
I'm just amazed at all the random places people manage to bring up and force their disagreement about Dragonfly into any discussion around Google.
Pointing out the actions of other companies, the good things Google has done, or the fact that they censor content in most countries doesn't negate that fact. Those are just mediocre argumentative tactics to try and downplay a public relations disaster.
We're not even dealing with the same Google from 9 years ago. Here's some good reading for everyone about how Google went out of it's way to protect Chinese dissidents and refused to comply with the Chinese government. Now they're doing the opposite:
https://googleblog.blogspot.com/2010/01/new-approach-to-chin...
Granted, in this case if you block Google's DNS servers from routing, Chrome will use your system's name resolution configuration.
This has been discussed to death. Slippery slope, etc., etc.
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 disheartening christmas experience, when I first assured my mother that no, we could skip this stuff with your phone, only to find out that no, she would indeed have to make that sacrifice.
Especially frustrating is that my same devices, validated with the old method, continue to function just fine.
Does anyone with more knowledge than I have know of a reason for this that isn't data-greedy or consumer-hostile? From my perspective, "Don't be evil" has been dead long enough that the bones are sunbleached.
But my actual takeaway is, "Legends of the CS world write informal, pithy rants to Google just like the rest of us mortals."
>Are you looking for https://support.google.com/chromecast/contactflow ?
>And [wasting our time] as well.
And to be fair, I would've expected a personal blog post rather than an IETF post. This is definitely quaint, though it gets the point across.
my ISP blocks 8.8.8.8.
I cannot activate chrome cast.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 only allow 1.1.1.1 out for DNS, I can't use my cast device? That's screwy.
https://www.reddit.com/r/vivaldibrowser/comments/a23071/how_...
Regardless of their reason, many of us don't want to use Google DNS and the just using their control over these devices to force people to 8.8.8.8/8.8.4.4.
I haven't checked how Pie behaves yet but it provides an option in the UI to specify private DNS.
Also, I found some time ago, and am not sure if it's still the case, but some of their first-party apps hard coded Google DNS, so seeing one at the system level was irrelevant.
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.
Anything else would be weird.
Nothing Google makes will ever respect your DHCP-server or local network settings ever again.
dig +short TXT whoami.ds.akahelp.net
Then set to other DNS provider and do the same
You will see that Google DNS is delivering ECS which helps with directing traffic to nearest CDN.
I have quite secure DNS setup but still forward some queries to Google DNS (HBO, Spotify, etc.) just to take advantage of using ECS.
I've seen so many instances of computers configured with DNS servers which are extremely slow, or provide garbage results, that adding a known good DNS server to the list, and then parallel resolving across all of them is a perfectly legitimate thing to do.
https://docs.netgate.com/pfsense/en/latest/dns/blocking-dns-...
Smart TVs in particular should not be a thing. The TV manufactures have proven themself incapable of writing and maintaining software, so at this point they should accept defeat and just produce the TVs with enough HDMI connections.
I admire your sentiment but recognize that on the current path that means at some point in the future this choice will mean "I don't have a TV." What is missed here, and alluded to in other comments, is that the costs for things are being subsidized by selling the digital exhaust they generate. Creating more exhaust means more margin, less (or even zero) exhaust means less margin. Since consumer electronics compete on price, a zero exhaust device will cost more and won't sell as well. So the market won't produce them. Further, the ability to convert a consumer device to one that generates zero exhaust will get targeted, and since there is no way to "win" that race, the final act will be a consumer device that refuses to operate if its ability to spew digital breadcrumbs is disrupted. Just like HP "all in one" printers will refuse to scan a document if they are low on ink. They don't need ink to scan, but the purpose of the printer is to create a recurring revenue stream for high margin ink, so all functions are in service to that purpose. Allowing utility that would mitigate the need to buy ink is unacceptable.
sudo iptables -t nat -I OUTPUT --dst 8.8.8.8 -p tcp --dport 53 -j REDIRECT --to-ports 53
sudo iptables -t nat -I OUTPUT --dst 8.8.4.4 -p tcp --dport 53 -j REDIRECT --to-ports 53
sudo iptables -t nat -I OUTPUT --dst 8.8.8.8 -p udp --dport 53 -j REDIRECT --to-ports 53
sudo iptables -t nat -I OUTPUT --dst 8.8.4.4 -p udp --dport 53 -j REDIRECT --to-ports 53
Its an ugly hack, but things like PiHoles can reliably do this with little to no extra load, and keep the google spy engine off your tracks. But then we'll have to discuss using a chrome..
Hardcoded DNS servers are common. Extremely common in a bunch of IOT devices, given how broken some ISPs are. This is a non-story and the only reason it's being upvoted is because Google is doing it, and they also control the DNS server.
You know what would be an actual story though? If Google used Google DNS to spy on people. If anyone has concrete evidence that they're doing that, that is a big fucking deal. Not some email about a google-complaint-of-the-week.
Edit: To be clear I'd agree that in a high quality product there needs to be a way to change the DNS servers. Then again, this is a $30 device to hook up TVs, and I've seen $200 routers lacking that ability.
----
Edit 2, elaborating on the above: You make a cheap device that will likely end up in millions of homes and your #1 support issue is "It doesn't work [because my ISP is terrible therefore my network configuration is shit]!". What do you do? Do you tell your consumers to suck it up and talk to their ISP? Or do you… hardcode a DNS server that you at least know will work?
"Issues" like this one are non-issues and distract from the myriad of very real privacy issues coming out of Google. Yes, this should be configurable at the very least… then again, Google products aren't exactly known for their wonderful configurability.
Is this the Paul Vixie?
https://allaboutchromecast.com/chromecast-how-to-guide/compa...
Why? Because ISPs and home networks are awful a non-trivial amount of time. It also gives leverage to Evil ISPs to hold Google ransom for the DNS queries needed to make the thing work propertly.
I dont think the average person knows or cares how fragile the internet actually is (unless, of course, you happen to live in China, which activiely manipulates and breaks DNS routinely for glorious reasons)
Recently I wanted to buy home speakers and realized that all devices with top reviews need an app to function, and I need to agree to some privacy terms, etc.
We need to have have old school products where I am giving you X bucks and you leave me alone.
Like controlling your phone exchange, one can either watch who you connect to, or connect you to other phones regardless of the phones you try to connect to.
So Google/Chromecast only knows what DNS lookups Chromecast makes, which changes nothing with regards to privacy or anything else. It can't watch what you're doing, it can't snoop on your web traffic, etc...
https://developers.google.com/speed/public-dns/docs/dns-over...
>To address these problems, Google Public DNS offers DNSSEC-validating resolution over an encrypted HTTPS connection using a web-friendly API that does not require browser or OS configuration or installing an extension. DNS-over-HTTPS greatly enhances privacy and security between a client and a recursive resolver, and complements DNSSEC to provide end-to-end authenticated DNS lookups.
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 nation state, and actively do things about it (like not buy their hardware). Otherwise, shut yo trap.
It's not nice, but it's not Google who started this.
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..
Why would ______ want to do _______ with their ______ device?
You can make a locked down device that only does a very limited subset of functions, but you really should make that known to the user before hand. "This device requires access to $X servers to function".
If you have secret requirements that go far beyond user expectations, expect that your users might get pissy about it.
I believe at one time TPUG members (https://www.tpug.ca) would bring their PETs to Starbucks for meetings. I know I've banged out work on a TRS-80 Model 100 at Coffee Bean.
By all means offer fall-backs to Google DNS if it's not behaving correctly, for the reason you mention.
I've found it's also, quite poorly implemented, particular on CC Audios, I had an instance last year where my internet connection went down at my ISP, my DNS saw 10s of thousands of DNS queries per-device from each of my Chromecast Audio devices in the time I was out at work. It was almost 40k DNS queries in ~12 hours, per device.
Almost everything else on my network behaved normally, but the Google devices just went mental spamming the network with insane numbers of impossible requests, back-offs are a thing, they should use them.
Still 2 years ago that rate limit was pretty easy to hit by accident with a Selenium browser farm accessing through single public IP.
My initial reaction to the post above was "ship a known-good DNS if you must, but honor the user-chosen service unless it's not answering." This makes sense as a more common reason you'd want to hardcode a DNS, and a reason to honor your setting over whatever is coming back from the customer's DNS.
I still can't see a good rationale for only using the hardcoded DNS, though. Not only does it strip user control, it opens the door to all kinds of secondary stupidity like breaking every Chromecast in Turkey by insisting on a blocked DNS.
There should be a better way to fight it, but I fear Google may win here because I haven't been able to find anything wrong with the way their servers work. I.e., 8.8.8.8 isn't doing anything evil afaict... Yet.
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'll happily enjoy the benefits.
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 really hard to block).
I think the Chromecast is the ideal Google device, and a preview of what Google's model is: It slowly removes features through updates that you cannot turn off, and would rather fail completely than not be able to serve you ads.
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.
Google is an ad company; if you don’t watch the ads, you’re not a useful product.
It doesn’t matter you “bought a product”, this behavior is their corporate DNA. It’s the Office to their Microsoft. Time and time again, we see a clear behavior from Google: that everything feeds the ad machine — or else!
here i thought DoH was the panacea, solving all our DNS troubles. but this is one case where DoH doesn't help at all. on the contrary. with DoH we will have no control at all where our apps resolve their DNS requests.
No it didn't, it just queried 8.8.8.8 instead of whatever DNS server your DHCP configuration told it to use.
Putting "nameserver 8.8.8.8" in /etc/resolv.conf and marking it read-only would have the same effect. Doesn't look like much trouble does it?
this. I highly doubt Google is actually using DNS for tracking or connecting queries to someone's account, especially when they say they don't [1].
Many people say "use Cloudflare DNS if you're worried about privacy", but Google effectively makes the same claim as Cloudflare that they don't use DNS to track you. The only plus you get from Cloudflare is how they get KPMG to audit and ensure they're not logging IPs forever.
CloudFlare doesn’t make their money off of brokering my attention, they have a decent track record of doing the ‘right’ things (or at least not the ‘wrong’ things), and they’ve made some decently pro-privacy statements in the past.
It seems that everyone wants to collect data on everything and figure out how to sell it off, so I’m not putting it out of the realm of possibility that CloudFlare could do shady stuff and abuse my privacy as well- but their general line of business doesn’t require it the way Google’s does.
All things otherwise equal, I’m gonna trust the company who’s business isn’t selling my profile a bit more for most things. I used to use Google DNS a lot, now I use CloudFlare’s. I trust them both more than Comcast, AT&T, and Verizon with respect to technical competency and security at the very least.
Cloudflare doesn't need to analyze my data to make money -- they offer a great service that people will throw money at them to use.
But pi-hole (or other privacy dns appliances/services) also block tracking targets. By enabling/enforcing the "free and unaltered internet experience" Google also ensures access to tracking.
Why do you doubt it? This behavior would be consistent with Google's behavior generally.
> You know what would be an actual story though? If Google used Google DNS to spy on people. If anyone has concrete evidence that they're doing that, that is a big fucking deal.
I'm an optimist, but I'm also cynical enough to foresee the same complaints — it's not a story! everyone does it — if that came to pass.
Prevention is important because in real life you can almost never recoup the losses as easily. You can take it to the courts etc. but if your data leaks, it's out there, you can't undo it.
You're right, I'm sorry. I edited my post a bit to soften it.
> I'm an optimist, but I'm also cynical enough to foresee the same complaints
Well, maybe. I would hope not, specifically because Google has made previous guarantees that they do not use that data for spying.
It's different when it's your ISP, which already does tons of shady shit and buried somewhere in your TOS that they do this stuff.
I don't find it any more acceptable, but it would or at least should be a bigger story if Google was doing it with Google DNS.
Google's smart though. They know that rolling out unsavory ideas in small pieces keeps it under the radar.
They didn't, for example, push the organic search results under the fold all at once.
This could be innocuous, or part of some larger agenda.
Are you seriously thinking they don't store/analyse/use that kind of information??? (That's every site you visit, at minimum.)
They don't. They guarantee they don't.
The spooky answer is they don't need it.
RE: configurability ... I thought one of the main reasons people went with Google over Apple, specifically with Android, was precisely because of their configurability. Every person I talk to that left iOS tells me this.
Android also seems to be going the way of iOS on many fronts, because as it turns out, this philosophy makes things hard to maintain.
In general data that exists can be supoenaed, and if the logs don't exist a court order can make them begin to exist.
Common != Right.
I can totally see how they and other IoT vendors would want to do that. What boggles my mind is that so many people believe the feature implemented was "Use 8.8.8.8 and break otherwise so we can trojan our DNS into places" instead of "Hardcode 8.8.8.8 so it works in most cases".
What is paranoid IMO is some commenters' (as well as seemingly Paul Vixie's) implication that Google does this trick with the Chromecast to better spy on people, which completely goes against Occam's Razor.
It's not "spying". Google DNS just "monetizes data sent through Google servers". Like they do with Chrome Data Saver, or Amp, or Calendar, or Contacts, or Voice, or GKeyboard, or Photos, or Maps, or Gmail, or Search, or...
What constitutes "spying" to you? Do you honestly believe Google isn't mapping your IP address to your account and monitoring your DNS requests to influence the ads they serve to you?
> 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.
Indeed. And they're terrible. Maybe making a stink about a big player like Google doing this might encourage others to rethink the practice.
Probably not, of course, but the alternative of just shutting up and taking it isn't any better.
https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#No...
Seen far, far more instances of:
- ISPs shipping shitty network devices / awful factory settings
- ISP's own DNS servers being terrible in various ways
- Uncle Steve "the IT guy of the family" having messed with the network settings and nobody knows why 1 youtube video in 20 doesn't load but we just ignore it.
Nitpick, but more like $70; you may be confusing Chromecast Ultra with the base Chromecast.
All cast apps & authentication are provided by Google's servers. Once it begins streaming from Netflix then Google isn't involved, but they handle initiation of that connection. Same for local content. And they don't exactly need to hijack DNS to figure out that you're watching Netflix after they launch the Netflix app.
And they know when streaming stops. Hence why it switches back to the slide show screensaver when you leave Netflix stopped for a minute or two.
But you seem to have forgotten this device exclusively runs Google software on it. Why would they be using doubleclick.net on a device with no user input or interaction? Why wouldn't they just build the analytics into the OS?
What IETF standard is violated by a device using a known DNS server rather than the one offered by DHCP?
Fortunately, you can currently still spend a little extra to "stupify" a smart TV --- figure out what LCD panel it uses, then replace the "smart" part of it with a suitable driver board (search the Internet for "HDMI LVDS" --- these are basically what computer monitors use.) Interfaces are reasonably standard so they're compatible with a wide range of panels. Example: https://www.aliexpress.com/item/10-bit-lvds-controller-for-p...
Your general concept for "digital exhaust" is good though. It's extremely clear in phones. I can either pay a for Apple and limit my exhaust, or I can get an Android phone and pay the difference with my data.
Which is to say, I trust them both to try to screw me, but the ISP has already done so to the extent that they were able. But Google is just warming up, and they're more competent.
Phishing by a random bad actor taking advantage of lack of TLS verification is far more likely than Google putting a sandbox escape in a phone app they distribute to steal information from you. I really hope most people's threat model doesn't match yours in this respect.
But then again, I de-Googled myself ages ago, so mostly not a problem.
Like somebody said below, this is pretty much a non issue unless google starts to force DNSSEC and certificate pinning.
For that I use this
https://www.amazon.com/TP-LINK-TL-WR810N-Wireless-Adapter-Re...
It lets me connect to one WiFi network and bridge and create a second private network. You can then connect and authenticate from another device and the Roku worked.
We don't know this.
(Maybe not this, just an example to note that motivation can be hard to discern)
You might find Google's DNS privacy policy to be of interest: https://developers.google.com/speed/public-dns/privacy
To be clear, I use 8.8.8.8, but I understand the aversion. Google is a data vacuum, and being forced to give them more data than they are entitled to is a valid concern.
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 configured to connect to a network. And both the app and your browser can connect to the same remote server. Chromecast activation can't work that way, since it occurs as a necessary prerequisite to connecting the Chromecast to a network.
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.
A more plausible version - google knows most of the people use shitty ISP provided DNS servers, so instead it's using faster DNS that wouldn't inject shit as your ISP will.
EDIT: never mind. It's for ads.
All I have to do now is explain to my mother-in-law that she hasn't paid "enough". I'm sure she'll totally understand.
Injecting a route into your IGP is pretty trivial, any ISP with an engineer with more than 6 month's experience could manage this.
> though I haven't seen any evidence that any of them do that
Unless you've actually looked, and performed pcap analysis of what your dns request/response looks like to try and determine if your ISP is intercepting, you can't be sure.
That said, several ISPs used to do this quite transparently (pun not intended) in the early 2000s, to return advertising pages whenever a DNS query failed. Some of them would do this on their own DNS servers (that were the default pushed to your CPE, which was then the default for your network), some of them would actually hijack anything going to udp/53. This used to be prevalent for a while.
Then again, who's making more money monetising your activity? Your ISP or Google? Given that your ISP can already see every IP you visit and how much traffic you exchange with that counterparty, who would you rather protect your DNS requests from? Them or Google?
Yep. This was what spurred me to start running and using my own DNS server in the first place.
> who would you rather protect your DNS requests from? Them or Google?
I don't think one of them is better than the other on that count.
My ISP does the blocking slightly - the DNS response is fine, but they inject a redirect into the HTTP response.
Don't like it? Use TLS and verify certificates.
Both CloudFlare and Google are for-profit corporations which want to take actions to maximize their profits. Insomuch as they are profit maximizing, we should expect them to take actions where the expected gain is greater than the expected cost, and to prioritize actions which have the maximum gain over actions which are only barely profitable.
If the cost -- in terms of extra labor and reputation if the data-selling becomes public -- is estimated to be less than people are willing to pay for the data, why would any profit-seeking corporation choose not to sell your data?
We can't trust companies not to sell poisoned food, even though that's a huge reputational hit. We can't trust companies manufacturing herbal, vitamin or nutritional supplements to actually put the herb, vitamin or nutritional factor they claim they are in the bottles they sell. We can't trust the makers of USB cables to produce cables that actually meet the USB specifications. Why should we believe that any corporation, regardless of whether or not you pay them for their goods and services, would leave the money to be made selling your data on the table, even if there's a potential reputational hit if the practice becomes public?
But Cloudflare's business model is different: they get rich by making the internet faster. Plus, it's great publicity for them. Their customer acquisition focuses largely on winning developers (by letting them use a great, barely cut-down-at-all service for free) so they use it in companies later. This helps with that a lot.
* 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)
Well... all of the benefit to the user. Google doesn't get to use your DNS requests to sell ads.
How do you envision this working on the product in question? When are you ever making arbitrary DNS lookups in a Chromecast?
Seriously take the tinfoil hat off for a minute and think rationally. Google owns the entirety of the software on the device, and all connections to & from it. There's nothing they gain in terms of data harvesting from hard-coding their DNS here. There is no user input in play at all here. What are they going to harvest from a device that only ever does DNS lookups for their own hostnames?
If this was happening on Chrome, or Android, or something where user input & interaction was actually a thing then sure. But this is a goddamn Chromecast. All it does is watch YouTube and similar. How in any way, shape, or form can those DNS requests in any way help sell ads?
i.e. I suspect Google force their own DNS so that one cannot so easily use e.g. PiHole to filter out DNS lookups for servers that stream e.g. YouTube adverts.
?
DNSSEC do not protect against this.
Smartphone manufacturers can and do have absolute control over the software you run on your device. That was not true in the 90s.
https://www.statista.com/statistics/195680/share-of-keywords...
What does following local laws of one specific country have to do with the open global internet? You do realize that Chinese internet is already behind a firewall, and is not open, right?
> Google went out of it's way to protect Chinese dissidents
And we have absolutely facts about what they were working on with Dragonfly, except leaks from a source which was very clearly biased against the project. For all we know, they were coming up with new tech that allowed them to provide services to Chinese citizen while still protecting them.
That to me makes much more sense as to why they were considering re-entering, than the baseless "they were only doing it for the money" reasoning.
Why are you doing PR for them?
That's simply not Google's choice. The people with guns and tanks in China decide that. Judge Google by what they do the Internet where they have power, with browser tech and HTTP standards and AMP and DNS and YouTube and whatever.
I don't see why Google wouldn't actually prefer if China didn't have such draconian restrictions. At the very least it would reduce their regulatory compliance work in China drastically.
What I've done is, first, to block the HTTPS port from going anywhere except to my proxy. If you want to use HTTPS in my network, you have to install my cert. That cert is used to negotiate the HTTPS connection to the proxy. The proxy then has access to the plain-text data stream. If that data stream is a DNS request, then it's diverted to a DNS-over-HTTPS server that I run (which uses my local DNS server to resolve the request). Otherwise, the proxy just transfers the data to and from the destination site using an HTTPS connection from the proxy to the destination.
I suspect the answer is "I don't use them", but that's going to be a blocker for mostly everyone.
But there are a very large number of potential HTTPS ports (a reasonably well behaved system could, as well as 443, use anything that isn't well-known or registered, or which was registered for the particular use, even if the underlying protocol was HTTPS.)
https://developers.google.com/speed/public-dns/privacy
So, while it can't be traced back to you, it is absolutely useful information for their business. Why do you think they offer the service? To be nice?
You tell me how to do that.
"By using service X you are agreeing to be bound by the terms located at .... "
They claim that they don't. You have no way of knowing if they're lying or not, though, so it boils down to "do you trust Google?"
You do, and that's fair. I don't, and that's also fair.
pass in quick on { $lan $wireguard } proto udp to { 8.8.8.8 8.8.4.4 } port 53 rdr-to 192.168.2.1
Locally I run Unbound for caching, local dns zones and ad/malware domain blocking[2]. I have a DNS forwarder in Unbound configured to a local Stubby[1] instance that does dns over tls to Cloudflare.
Having done "big data" contract work for the largest telco in my current country of residence who are some of the worst skilled people I have ever work with, your local ISP is highly likely abusing your DNS history profiling your household for various questionable things just as much as Google. At least with Cloudflare they have a clear privacy policy[3] and I have faith their technical skill to anonymize data and use it can't be as bad as my ISP.
[1] https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+... [2] https://github.com/StevenBlack/hosts [3] https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
These days you have no chance of getting any form of tech support or even issue acknowledgement unless you have a large follower count online.
Especially if you're using it to, say, watch YouTube, as Paul Vixie was.
Chromecast connecting to Google is not a "secret requirements that go far beyond user expectations." Expecting a cloud-connected product to continue to work when you've randomly blacklisted IPs that belong to that company is, however, an unreasonable expectation.
https://security.stackexchange.com/questions/62273/can-dns-s...
It is similar in some ways to Facebook tracking users across the internet through Facebook "Like" and "Connect" buttons across the internet, even when the user's aren't on the Facebook site and did not opt-in to having their browsing tracked by Facebook outside of Facebook.
It's a Chromecast. You literally can't make non-Google queries on it at all in the first place.
So what, exactly, is the privacy concern here? What specific flow of events does the Chromecast using 8.8.8.8 impact your privacy?
Someone above says an update prevented this somehow, though.
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 <salted hash of current timestamp>.com. Google DNS could be coded to respond accordingly.
So no DNS response, or not the response you were expecting = not Google DNS.
DNS over TLS and DNS over HTTPS will change that. Google has pushed encryption in all their other products, and is pushing these implementations so do not be surprised when their end user devices use it by default.
All you've done is framed the situation in a way that makes it seem like Google isn't responsible for it's own actions.
Then Google should have nothing to do with it. Otherwise they are not supportive of 'a free and open internet', but are actively supporting a close, censored and controlled internet.
It's pretty simple.
Evidently, they are:
https://en.wikipedia.org/wiki/DNS_over_HTTPS
https://developers.google.com/speed/public-dns/docs/dns-over...
Curse it all you want, but forcing all DNS lookups to be resolved by a particular server is often an important security measure.
That's why whenever companies change their ToS you get email/notifications/actual mail informing you of the changes.
You can't do that for DNS.
Legally speaking, yes it does. It's a free service. The only obligation they have is to make their terms freely accessible, and to publicize any major changes.
You seem to be implying that Google and other free DNS providers have never changed their privacy policies since there's no good way to notify the users. Google's own website (and the Internet Archive) totally contradict this.
https://developers.google.com/speed/public-dns/privacy
"Last updated October 29, 2018."
There is no mandate or expectation that all DHCP clients always use the advertised DNS settings. If there was than alternate DNS services like 1.1.1.1 or 8.8.8.8 wouldn't even exist in the first place, as your ISP would be in complete control of your DNS settings unless you splurged for a static IP.
The cast client decided to use its own DNS settings as many clients do - you can override the DHCP settings on just about any general purpose OS, for example. Even though they are DHCP clients. Do you call Linux allowing you to specify a DNS server as "circumventing how the internet works at a pretty basic level", too?
There's a vast difference between "users can configure it to what they want" and "it's hardcoded and can't be changed".
Either that's circumventing how the internet works or it isn't.
Sounds like you agree that it's not, in fact, circumventing how the internet works?
I think it's fine to want that configurable and maybe, maybe even expect or ask for it.. But I believe concocting conspiracy and assigning malicious intent so readily, as many are, displays either an ignorance of how products get built for the mass market or a feigning of such. As others who have worked on IoT devices have pointed out, there are rather valid user experience concerns behind baking these "preferences" into the products.
I barely use Chrome anymore (just for testing really) but the thought that any domain I wish to go to can be overridden by the browser by default - that's scary.
I mean what if Google doesn't like your website's content. They can block it on their DNS server and 99.999% of Chrome users would think something was wrong with your site.
Thank you, I hate it.
Actually it was just annoying, not funny.
https://bugs.chromium.org/p/chromium/issues/detail?id=432236
(I'm obviously a bit biased on the matter because it affected me and cost me a silly amount of time to track down.)
They also claimed Firefox was doing the same thing, which is false and not really sufficient justification for not supporting things that MUST be supported.
[0] https://bugs.chromium.org/p/chromium/issues/detail?id=700354
In my haphazard experience, the networks that block access to UDP port 53 are more than likely to have gelded broken name servers that e.g. serve empty NXERROR results for anything but A/TXT, and receptionists that say, "uh, let me check" and then check that their browser can open the google home page. (Insert invectives here.)
I've seen be fixed. Once. One meeting I attended started with a quite broken network, but it was an IETF meeting, and the IETF tools team reconfigured the AP channel layout, the DHCP server and the caching name server at that hotel and after that it was fine.
> As others who have worked on IoT devices have pointed out, there are rather valid user experience concerns behind baking these "preferences" into the products.
Which is something that I have not denied. What I assert is that there absolutely needs to be a way to change that behavior if users wish. The lack of that ability is, in my opinion, something that is harmful, both technically and socially.
You think you're guaranteed to be querying 8.8.8.8 with "nslookup hostname.tld 8.8.8.8"?
This is looking at things and totally backwards. You have a local problem, a broken router and you suggest we fix this by changing how all edge nodes on the internet works.
In the age of ever increasing, untrustworthy IOT-devices, you don’t solve this problem by taking control away from the network operator. You need to increase his control. Taking DNS out of his hands is literally madness.
Good luck trying to block their attempts to spy and report on you now!
DNS over HTTPS is going to cause a shitload more problems than it solves.
Oh, absolutely. What I wonder is if people don't notice this, or they do but believe Google is right in pushing fundamental internet design decisions that prioritize Google's incidental access to surveillance data over a high quality and resilient network for everyone.
A good way of bypassing this would be to simply have Google run their DNS server in a port other than 53. But I don't believe you can set a different port in /etc/resolv.conf
And I don't have access to the /etc/resolv.conf on my Chromecast, that's the problem! Anyway, there's a new thread on this specific phenomenon. I'm glad I'm not the only one: https://news.ycombinator.com/item?id=19170671
I agree that on a privacy level, hiding DNS requests from Google when your Google Chromecast is calling Youtube seems like closing the stable door after the horse is gone. But there are reasons other than privacy that relying on Google's DNS might go wrong; it can be blocked (or trigger suspicion) by a government, ISPs have occasionally broken their routing to 8.8.8.8 specifically, and Google DNS itself has even had (very rare) outages.
None of those issues are enormously common, except perhaps Turkey's censorship, but they're all totally avoidable. Using 8.8.8.8 as a default and failing over to the user's DNS if necessary seems to be strictly better than this approach from a consumer viewpoint.
The reason doesn't matter. We should be in control of our own networks. Google shouldn't be deciding for us.
Map 8.8.8.8 to the machine of your choosing.
This isn't the same as coming into your home and forcing you to use Public DNS, sure, but I think people are justified in being annoyed if they buy something, then find an arbitrary and unannounced dependency in it.
(I can't find any mention of the DNS requirement by Google, just extensive threads elsewhere about working around the problems it's caused people. It looks like there is a 15-day return window for working devices. That's something, but if I stopped allowing Public DNS on day 16 and my device stopped working, I'd hardly feel like I had fair notice unless it was explicit somewhere in the instructions.)
Bold claim. Citation needed.
If an error occurs or a reasonably short timeout expires, the device can: if it has UI the user will see, it can report the problem to the user and ask if it's ok to try a common fix (which can be explained in detail in an optional "[technical details]" popup). If the user approves, then retry with the hardcoded DNS server (or any other workaround). If the device doesn't have a UI that could realistically ask this type of question, automatically trying the fix when the DNS test fails might be appropriate.
TL;DR - don't make assumptions about the user's situation, even if you think it is "market-smart". Test for the required behavior and fail-safely by enabling the common workarounds.
I don't trust they aren't evil, they are. I trust they are also smart.
By control, what I mean is that once DoH usage to G servers hits critical mass, they can decide who can visit what. Not that they would, but they can. People generally do what people can do.
The performance characteristics are also rather unfortunate. TCP handshake + TLS handshake with multiple public key operations + TCP protocol overhead adds quite a lot of both latency and computation vs. UDP DNS. DoH is even worse. There would have been ways (e.g. DNSCurve) to get equivalent or better security with less latency and computation if it weren't for horrible middleboxes breaking everything they don't understand.
And all that complexity is attack surface.
If we create internet infrastructure (like DNS over HTTPS) which prevents network operators from actually operating their networks, I’m 100% confident we will find it has bad, unintended and irreversible consequences.
Also: ISPs behave nice almost everywhere in the world where there is proper regulation.
What you have in the US is not a technical problem. It’s a regulatory one.
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.
These networks block all DNS traffic to 'random' DNS servers, including 8.8.8.8 to prevent any number of different attacks. The security device can examine the DNS packet and say 'youtube.com = allowed', or 'yourtube.com = not allowed'. It can also to the reverse "if youtube.com 'expected_ip_set' then allow". By requiring this device to use outside DNS servers you are punching holes in the network for no particularly valid reason.
Unfiltered and uncontrolled DNS is a security risk. I can transmit all your company information out of your network easily with DNS queries.
get a $UUENCODED_DATA.sequence_id.attack.comThe bigger picture here is that Google has a lot of power and any time they do something like hard-coding their own DNS server in a product (which could be construed as saying "we ARE the internet") people get worried and annoyed, whether this was a benign oversight, innocent mistake or a deliberate act.
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.
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 hardcoded DNS server (or similar workarounds) automatically. (If the device is literally a lightbulb and the only "UI" is if the lightbulb is on or off, user interaction doesn't make sense; just failover.
> And what should the user do with that information?
At a minimum, the are informed that something about their network required using a workaround. However, you seem to be missing the point: the minimal amount of user interaction I'm suggesting isn't (primarily) about informing the user. It's about asking permission to use their network contrary to how their network asked to be used. You are a guest on their network..
(if the DHCP server didn't provide a DNS serer, then there is no problem; just use a known server)
More importantly, I'm mostly talking about testing and failing over to a the builtin DNS server, instead of simply assuming it's needed in "some" cases and turning it on for everyone. This shouldn't be difficult. The DHCP already happened, do the DNS lookup and check a special URL over TLS. If it fails or times out change the DNS to Cloudflare or Google's service and retry.
Using 8.8.8.8 is exactly the opposite of an assumption. It always works in any config, that's the point.
EDIT: Besides, obviously, the OP's extremely unusual config, where he is effectively just blocking the service with his firewall. Why isn't he outraged about having to unblock all of YouTube's other IPs? What's special about 8.8.8.8?
Just because your network provides a DNS server does not mean that it makes sense to use that DNS server for every single IP address lookup in every piece of software. It's there for general internet browsing purposes, not specialized proprietary purposes like this.