6 ms·

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

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

FakeComments 8y ago
> would rather fail completely than not be able to serve you ads. 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!
- SmellyGeekBoy 8y ago
  As always, don't let facts get in the way of a good rant.
  - FakeComments 8y ago
    There is a continual and persistent trend in Google’s behavior, across a broad range of products. While any lone action might be explainable, as a pattern, they’re poor conduct.
scrollaway 8y ago
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.
- quickben 8y ago
  At a maximum rate of $58 per tenis ball: https://www.statista.com/statistics/195680/share-of-keywords-prices-in-google-adwords-advertising/ https://www.statista.com/statistics/195680/share-of-keywords...
  - mrep 8y ago
    Mesothelioma cost 319$ 5 years ago and I'm pretty sure it's only gone up since then: https://www.adgooroo.com/the-most-expensive-keywords-in-paid-search-by-cost-per-click-and-ad-spend/ https://www.adgooroo.com/the-most-expensive-keywords-in-paid...
- disiplus 8y ago
  i don't think its totally unreasonable. the same thing could be said about the people who used adblock back in the day, but im sure google knowing what they know now would never let it thru. im pretty sure they are actively thinking about it now and how to ensure that they can deliver what they want directly to our eyes no matter what. from the position of google everything else would be stupid, im pretty sure they learned the lesion.
  - scrollaway 8y ago
    Google would certainly be aware of pi-holes and the potential of the threat, but to put things back in context we're talking about a mass-market device which has to deal with bad network config, bad isps, bad routers, etc. What's more likely?
- apostacy 8y ago
  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.
fixermark 8y ago
How is "hardcoding 8.8.8.8" a "massive amount of trouble?"
pexaizix 8y ago
>My Chromecast went through massive amount of trouble to use Google's DNS servers 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?
- adsadadsad 8y ago
  Maybe. But it's trivial, for your ADSL/DSL/Fiber shitty $30 router to intercept port 53/(udp|tcp) bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP. When I say trivial I mean I've seen it happen on several setups, old me - we'll just change the DNS on this box to bust the cache here to 1.1.1.1(CF)/8.8.8.8(EvilG) but still end up a shitty ISP dns servers (and their poisoned cache regardless). There's a reason for the push for DNS over HTTPS. You think you're guaranteed to be querying 8.8.8.8 with "nslookup hostname.tld 8.8.8.8"?
  - pexaizix 8y ago
    Yes I know. I've had it happen to me with a Huawei HG556a. You could disable it with admin access... which the ISP would not give you. Fun times. 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
    - adsadadsad 8y ago
      Possibly feasible with local netfilter/iptables rules or maybe userland proxy/rerouter. set /etc/resolv.conf to localhost:53, have that forward to 8.8.8.8:1053 or whatever, but without encryption it could be detected I'm guess with deep packet filtering (hopefully beyond the thoroughput constraints of eyeball ISPs)
  - josteink 8y ago
    > bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP... There's a reason for the push for DNS over HTTPS. 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.
mgoetzke 8y ago
how is it showing you ads ? Haven't seen any yet.
- rmoriz 8y ago
  pi-hole also blocks tracking services. And I'm sure chromecast is full of tracking to enhance the value of your account.
  - SmellyGeekBoy 8y ago
    Surely you'd know, right? As Pi-Hole logs all of this stuff.
    - rmoriz 8y ago
      just install apps or use chrome to browse (on Chromecast Ultra of course)
steelframe 8y ago
I really gave Chromecast an honest run for the money. One day at the start the of the weekend, it started hanging at 80% when initiating streaming content I had purchased on the Play store. The forums had a ton of other people who were complaining about the same thing. Google had pushed out an update that they apparently hadn't event done the most rudimentary testing on. They didn't roll back, and they didn't fix it until after the weekend. I replaced it with a Roku, and I no longer trust Google to do consumer devices.
deleted 8y ago
[deleted]
FactolSarin 8y ago
The Chromecast doesn't serve ads. Individual services you run on it might, but I doubt those are being served through Google's DNS server.
- alias_neo 8y ago
  The Chromecast hard-codes Google DNS so _any_ service you run on it resolves through Google DNS.
Legogris 8y ago
Could you solve this by just routing 8.8.8.8 to your own DNS inside your network?
- alias_neo 8y ago
  This is how I solved it. Someone above says an update prevented this somehow, though.
  - jrockway 8y ago
    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.
    - alias_neo 8y ago
      I also don't see a way they could do it, but then I only know just enough to be dangerous, as they say.
    - mthoms 8y ago
      >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 <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.
      - cwkoss 8y ago
        Clever, kind of reminds me of how map makers insert fake 'trap streets' to prove copyright theft.
znpy 8y ago
I was going to post something similar. This is not an accident or a mistake. This was done on purpose.
em-bee 8y ago
hmm, won't that all get worse with DND over HTTPS? 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.

FakeComments 8y ago

> would rather fail completely than not be able to serve you ads. 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!

SmellyGeekBoy 8y ago
As always, don't let facts get in the way of a good rant.
- FakeComments 8y ago
  There is a continual and persistent trend in Google’s behavior, across a broad range of products. While any lone action might be explainable, as a pattern, they’re poor conduct.

scrollaway 8y ago

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.

quickben 8y ago
At a maximum rate of $58 per tenis ball: https://www.statista.com/statistics/195680/share-of-keywords-prices-in-google-adwords-advertising/ https://www.statista.com/statistics/195680/share-of-keywords...
- mrep 8y ago
  Mesothelioma cost 319$ 5 years ago and I'm pretty sure it's only gone up since then: https://www.adgooroo.com/the-most-expensive-keywords-in-paid-search-by-cost-per-click-and-ad-spend/ https://www.adgooroo.com/the-most-expensive-keywords-in-paid...
disiplus 8y ago
i don't think its totally unreasonable. the same thing could be said about the people who used adblock back in the day, but im sure google knowing what they know now would never let it thru. im pretty sure they are actively thinking about it now and how to ensure that they can deliver what they want directly to our eyes no matter what. from the position of google everything else would be stupid, im pretty sure they learned the lesion.
- scrollaway 8y ago
  Google would certainly be aware of pi-holes and the potential of the threat, but to put things back in context we're talking about a mass-market device which has to deal with bad network config, bad isps, bad routers, etc. What's more likely?
apostacy 8y ago
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.

fixermark 8y ago

How is "hardcoding 8.8.8.8" a "massive amount of trouble?"

pexaizix 8y ago

>My Chromecast went through massive amount of trouble to use Google's DNS servers 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?

adsadadsad 8y ago
Maybe. But it's trivial, for your ADSL/DSL/Fiber shitty $30 router to intercept port 53/(udp|tcp) bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP. When I say trivial I mean I've seen it happen on several setups, old me - we'll just change the DNS on this box to bust the cache here to 1.1.1.1(CF)/8.8.8.8(EvilG) but still end up a shitty ISP dns servers (and their poisoned cache regardless). There's a reason for the push for DNS over HTTPS. You think you're guaranteed to be querying 8.8.8.8 with "nslookup hostname.tld 8.8.8.8"?
- pexaizix 8y ago
  Yes I know. I've had it happen to me with a Huawei HG556a. You could disable it with admin access... which the ISP would not give you. Fun times. 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
  - adsadadsad 8y ago
    Possibly feasible with local netfilter/iptables rules or maybe userland proxy/rerouter. set /etc/resolv.conf to localhost:53, have that forward to 8.8.8.8:1053 or whatever, but without encryption it could be detected I'm guess with deep packet filtering (hopefully beyond the thoroughput constraints of eyeball ISPs)
- josteink 8y ago
  > bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP... There's a reason for the push for DNS over HTTPS. 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.

mgoetzke 8y ago

how is it showing you ads ? Haven't seen any yet.

rmoriz 8y ago
pi-hole also blocks tracking services. And I'm sure chromecast is full of tracking to enhance the value of your account.
- SmellyGeekBoy 8y ago
  Surely you'd know, right? As Pi-Hole logs all of this stuff.
  - rmoriz 8y ago
    just install apps or use chrome to browse (on Chromecast Ultra of course)

steelframe 8y ago

I really gave Chromecast an honest run for the money. One day at the start the of the weekend, it started hanging at 80% when initiating streaming content I had purchased on the Play store. The forums had a ton of other people who were complaining about the same thing. Google had pushed out an update that they apparently hadn't event done the most rudimentary testing on. They didn't roll back, and they didn't fix it until after the weekend. I replaced it with a Roku, and I no longer trust Google to do consumer devices.

deleted 8y ago

[deleted]

FactolSarin 8y ago

The Chromecast doesn't serve ads. Individual services you run on it might, but I doubt those are being served through Google's DNS server.

alias_neo 8y ago
The Chromecast hard-codes Google DNS so _any_ service you run on it resolves through Google DNS.

Legogris 8y ago

Could you solve this by just routing 8.8.8.8 to your own DNS inside your network?

alias_neo 8y ago
This is how I solved it. Someone above says an update prevented this somehow, though.
- jrockway 8y ago
  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.
  - alias_neo 8y ago
    I also don't see a way they could do it, but then I only know just enough to be dangerous, as they say.
  - mthoms 8y ago
    >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 <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.
    - cwkoss 8y ago
      Clever, kind of reminds me of how map makers insert fake 'trap streets' to prove copyright theft.

znpy 8y ago

I was going to post something similar. This is not an accident or a mistake. This was done on purpose.

em-bee 8y ago

hmm, won't that all get worse with DND over HTTPS? 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.