Big ISPs aren’t happy about Google’s plans for encrypted DNS
arstechnica.com
arstechnica.com
We still need to encrypt the accessed resource and DNS queries everywhere.
Even once that’s done, things like opencaching will be used by SPs to gather tons of data where they participate.
edit: you can see this clearly in the way they pay lip service to "breaking up big tech" (whether or not that's a good idea, this comment is not a statement of opinion on that subject) because it's politically sexy on both sides, while all these other, arguably more egregious abuses of consumer data are so far off the radar that most people probably aren't aware they're happening.
I'm guessing we're just trusting Google here (and Cloudflare 1.1.1.1 who now also does 10gb free VPNs) + the good will of engineers with access to this information within Google.
But the limits of using google DNS (or even encrypted DNS) is that most commercial websites aren’t sharing IP addresses, so I bet the ISP can pretty much reconstruct the data it would get from DNS with very little effort just by looking at your IP traffic and mapping IP addresses to domains from other users DNS queries.
Thinking knowledge, intelligence or capability correlates with ethics is a category error.
Courses like that don't fix unethical people, but they make the rest of us aware that ethical concerns exist. Software/Computer Science is such a young discipline that, industry-wide, I don't think we've learnt that one from the other industries yet.
Cisco collects more than 24TB of DNS query data every day. Here's a Cisco employee demonstrating the kinds of horrifying analytics they perform on this data https://www.first.org/resources/papers/conf2018/Mahjoub-Dhia...
Implementing the mis-feature on a public ISP will be done by people who think the matter isn't worth risking their job by taking a stand on, and just saying no once the decision has been made several levels above their rank won't help anyone because if they don't implement the feature their replacement will.
The age-old answer: money.
Developers may be in a pretty sweet situation, generally, but if you don't have money saved or another job lined up you don't have much choice.
I also think that people are great at finding excuses for what we're doing. I've read somewhere about a hypothesis that conscious thought is mostly just intellectual justification for subconscious urges.
Modern silicon valley is built off people implementing similar pervasive tracking, without it there is no google, facebook and many other startups. Not to mention online newspapers and everyone who makes money indirectly from the tracking.
I agree it's a bad thing, but that ship sailed long ago and things like the GDPR are only just starting to bring it back.
https://techcrunch.com/2018/06/25/nsa-att-intercept-surveill...
And that's why I use VPN services. But the same is true for VPN services, regarding US and/or other TLAs. So I use nested VPN chains, to make it harder to get complete data.
And when it really matters, I add Tor to the mix. Even if it's heavily infiltrated by US TLAs, there's at least the chance that it's also heavily infiltrated by TLAs of US adversaries. So, Dog willing, maybe they cancel each other out, at least somewhat.
I don't agree with that argument. Because ISPs can already do that. And for most people, their ISP is far more likely to be cooperating with their local adversaries than some random VPN service is.
And for what it's worth, one of Tor's inventors (Paul Syverson) has agreed publicly that there are reasons to access Tor through VPNs. Basically, when you don't want your ISP to know that you're using Tor. Indeed, if I were a CIA agent using Tor in Iran, I probably wouldn't want the ISP to know that I was using Tor.
But I don't trust VPN services either. So I use nested VPN chains. That's basically the same approach that Tor itself uses, routing traffic through multiple (three) relays. So no one relay (or for me, VPN service) knows both who I am, and what I'm doing online.
There's also the issue of trusting the Tor network. Some argue that it's compromised by US TLAs. So with a nested VPN chain between me and entry guards, I'm less concerned that some TLA is running them. But even if that's just paranoia, there have been bugs that deanonymized users.
For example, some years ago, CMU researchers exploited the "relay-early" bug to allow malicious entry guards and exit relays to exchange information, and so learn that they were routing the same circuit. That allowed said CMU researchers to deanonymize Tor users. The FBI learned of this, and subpoenaed the data. And lots of people went to jail over it. Mostly drug dealers and child pornographers, but whatever.
However, routing VPN services through Tor is a totally different matter. If you do that, your anonymity depends entirely on how anonymously you've obtained, paid for, and used the VPN service. If you used an email address that's linked to you, you're screwed. If there's a money trail in paying for the VPN service, you're screwed. If you ever use the VPN account without Tor, you're screwed.
And even if you manage all that anonymously, the very fact of using a VPN through Tor decreases your anonymity. That's because Tor by default switches circuits at ten minute intervals. But when a VPN is connected through a Tor circuit, that circuit is pinned. So by using a VPN through Tor, you've blocked one way it increases anonymity.
Almost by definition, that means you're worth taking a closer look at.
Once you're under the microscope, you'd better hope your opsec is flawless or that your activities are completely boring, or else the $TLA knows exactly what you've been up to, TOR or not.
Disclosure: my activities are completely boring, and I don't use Tor, VPNs, or anything like them.
And anything that likes a persisted connection is likely to get a lot of connection resets. Like websockets (slack) or irc
- How was the DNS logged?
- Was every query logged, or only unique queries?
- Was it combined with other data?
- How long was it searchable for?
- What were the DNS queries used for? Simply sold to 3rd parties? If so, who was buying?
And in anonymous, aggregated form (e.g. only include domains that were accessed by multiple customers, the frequency per day and domain name, maybe geographical data precise to a region corresponding to a million people), I would be perfectly fine with this, even if it gets sent to ad companies. I'd not like it, but I'd also not see the harm and there is a lot of money involved, so if we can't stop it then I'll be fine with it in a basic form (aggregated). At least until we decide that trying to optimize manipulating/influencing people is brainwashing (I'm undecided whether playing psychological tricks on people while they try to get groceries or look for information online or whatever is morally okay).
https://arstechnica.com/tech-policy/2017/03/for-sale-your-pr...
https://arstechnica.com/information-technology/2017/03/how-i...
all the major ISP lobby groups signed on to a voluntary set of privacy principles based partly on the FTC framework. They specifically pledged to follow FTC guidance for opt-in consent before sharing sensitive information and to “offer an opt-out choice to use non-sensitive customer information for personalized third-party marketing.” Browsing history would be subject to an opt-out system.
Harris encourages Internet users to go to their ISP’s website or call the ISP to figure out exactly how they can opt out of tracking. It’s not convenient, but the option should be there.
But I’m fascinated by the legal implications. Right now in Portugal sites are DNS-blocked for copyright reasons (IIRC without the need for what you’d call full legal oversight, just a sort of loose arbitration with the local equivalent of the RIAA), and this is going to play merry havoc with that.
(Uber’s website was also DNS blocked for a while due to hassles with licensed cabs, which was interesting because the mobile app never stopped working — can’t remember if it was an actual court order, but this should give you an idea of how technically clueless some people are over here...)
I also use my own router so I assume it doesn't affect me or does this mean that their network doesn't allow other DNS servers?
How would that affect a VPN? I use PIA and they have their own DNS servers.
I'll need to experiment with this when I get home I think.
If your DNS requests are going over the VPN then you will be fine as they will be in the encrypted tunnel before they travel through your router so it can't do anything about them. A change to the router firmware won't be able to override DNS server settings on other individual hosts.
If your router is providing the local VPN endpoint then that is another matter, but IIRC PIA runs on your local station. Do check that it is in fact setting your machine to send DNS requests over the link. I'd be surprised if it wasn't, but you never know.
Say I manually set my dns to 1.1.1.1, is there a way to tell if the replies are really from 1.1.1.1?
Setup a simple DNS resolver in an external VM (use a service like DO where you can pay by the hour, and the test will cost you at most tens of pennies), configure it with a DNS zone that the rest of the Internet does not know about (thisdoesnotreallyexist.net). Then if you try query for that domain from that server but get an NXDOMAIN response your query was probably intercepted (of course test from other locations too, to make sure the problem isn't a mistake in the new resolver's config).
Or you could configure the test resolver to give different answers for an existing domain, of course, and check for which addresses you get back instead of checking for address or error - that would essentially be the same test.
Or, he says, thinking of the obvious after explaining the more long winded, if you have a DNS server in your control, simply turn on the relevant logging options and run a query against it and see if your query turns up in its logs.
This assumes they are intercepting and NATing all standard DNS requests (usually on UDP & TCP port 53), rather then just DNS traffic going to a list of known alternative DNS services. If they are doing the latter then there are tests you can do that rely on timing and TTL settings (get their server to cache a result, change the name->address mapping, then ask 8.8.8.8 or similar and see what answer you get).
If you run your own dns server at your local machine you can enable DNSSEC, which will protect against manipulations for domains that has that enabled. A recursive dns server is pretty easy to setup and it a step towards running your own authoritative server in the future for private domains.
If you want to resolve using googles DNS servers and be sure it is really them then the only method that I know that is also supported by google would be DoH. The other encryption method they support, DoT, do not provide authentication and draft-bortzmeyer-dprive-resolver-to-auth-00 is to my knowledge not implemented by google.
If you want a bit more privacy and have a mix of the two above then go with a VPN or build one yourself. Just note that without DoH you won't be authenticating between the VPN and google, so I would just use a resolver at the VPN.
So far I have been unsuccessful in my attempts to get through to a technician who knows anything other than "try turning it on and off again". I suspect this policy is deliberate.
'cause DNS logs & users data brings them good money, so they just defends business.
Their tech support (the one that's "if we solve the problem we'll charge you") said they could not solve this for me.
For one some ISPs run content filtering services. Some users prefer to concede extreme privacy for what they view as a safer browsing experience. It might not be your jam, but it exists.
DNS is designed to be provider independent. It literally does not matter if a Google or Cloudflare or OpenDNS or DNSFilter or your ISP resolves requests. It was designed this way so that the system could be distributed and so that there is not a single point of failure for the internet’s arguably most important system.
Its distributed nature means there are technical performance advantages to doing the above: reduced request latency, localized traffic routing and reduced bandwidth, etc. You don’t need a giant any cast network to serve DNS. You just need to use the servers closest to you.
In Europe ISPs are under much stricter rules about data privacy and generally cannot do things like the above. Having worked for several ISPs here I’ve never found them misusing DNS data (although sometimes it was logged for a time for management / troubleshooting.)
For a European; with reasonable trust in my ISP, I don’t want Mozilla sending all my queries to a US company which can be forced to reveal that to the US govt, or use it for some other nefarious purpose.
FWIW I’ve never used my ISP DNS though have always run my own recursor at home.
My issue with this is that I've never been with an ISP that had a faster response time than Cloudflare/Google - and one would think they should, after all, my ISP should be able to reach me as quickly (or quicker) than any other corporation.
My current ISP has the fastest DNS benchmarks I've seen, and they're at 81ms for an uncached response, vs Cloudflare's 63ms and Google's 69ms. Cached response is similar (since I have a local cache).
In addition, my ISP does not provide DoH/DNSCrypt/DNSSec. None. Just 'vanilla' DNS. Furthermore, they also don't provide an unaltered DNS service: they block some websites from resolving, the list isn't made available, and is decided via extrajudicial means. You cannot opt-out, and all ISPs in the country adhere to this. They're not forced by law to do so. I'm also not in a normally thought of as a repressive country: it's a member state of the European Union, after all.
There are very good reasons for people to be outright hostile to ISPs and their shady underhanded practices, as you're seeing in this discussion. I feel that it is in any mostly online-based organisation's best interests to expose those practices.
Would Cloudflare/Google?
Cloudflare and Google pay ISPs for the latency they get, FWIW. If I made my own resolver service today I would not be able to compete with your ISP without forking over $$$.
Regarding content filtering services, in that case the user is specifically opting in to that service, so they won't need or care to use an alternate resolver.
I agree that, ideally, you would use a resolver that's close to you in order to minimize latency and increase reliability, but:
1) This requires you to trust your ISP. Many people don't, and with good reason.
2) ISP DNS isn't exactly always the most reliable or fast thing anyway. I easily get better latency from Cloudflare or Quad9 (their old-school Do53 stuff, not the new-fangled DoH) than from Comcast's resolver.
And regardless, if your DoH provider of choice goes down, you can always fall back to a different one, or to your ISP's resolver.
But that is not a valid use case for filtering dns requests to other services.
Mozilla's move to reconfigure Firefox to use DoH is a bit sneakier, but it fits with their privacy stance and their low market share does give them cover.
At least Cloudflare has KPMG audit them on their privacy claims. Better than nothing.
There is this: https://en.wikipedia.org/wiki/KPMG#Controversies
and then there is this:
https://home.kpmg/content/dam/kpmg/us/pdf/2019/01/2018-trans...
At the end of the day, any grouping of individuals are a (partially biased) sample of the society in general. The role of media and education is fairly decisive in forming social norms. We may have one or two lost generations of engineers following orders, but as Joe said 'The future is unwritten".
This isn't true. If you're hosting it, you can control it and you can make sure that it's always operational. The last thing you want is a 100 phone call of "my internet isn't working" and then trying to explain it's not your fault, but rather it's "some other guy".
Regardless, impressive step to take.
They’ve also injected permanently unique cookies in http requests.
ISPs can’t be trusted as dumb pipes, they’re closer to “clueless criminal” pipes.
But I agree with you, I don’t particularly trust google either.
Because that seems MUCH more sensible than a lot of the stories/comments about this recently make it seem.
So in other words trust them with everything.
Google has promoted its own DNS service over others in the past, including for non-chrome users, and presumably would do the same when DoH (in whatever form) is the norm.
I was simply saying we already know that ISPs misbehave, but presuming that Google wouldn’t is not necessarily a clear cut decision.
There exist pure technical reasons too, from address translation to DNS-level routing and load balancing. For example for ipv6-only network to access ipv4 resources there needs to be something like NAT64 embedding ipv4 addresses into ipv6 ones, but that would require overwriting DNS responses with DNS64 to actually work [1]
[1] https://en.wikipedia.org/wiki/IPv6_transition_mechanism#DNS6...
Keep in mind, encryption is not privacy. Encrypting DNS queries to a 3rd party resolver doesn't improve your privacy, it's a fight for control, not privacy. ISPs will still violate your privacy to the same extent, except said 3rd party will be able to do that too. If your ISP is not trustworthy the only way to save yourself from it is to use something like a VPN which effectively gives you a different ISP of your choice.
How do you mean? Why should my ISPs hijack communication between me and a content provider and reroute it? This is as if I'm in a phone meeting and when I say "let me call you back at 15:00" the phone company injects "19:00" instead, because that's a time the phone network is less loaded so it'd help them.
> NAT64 embedding ipv4 addresses into ipv6 ones
NAT64 is a good point, actually. But at least in 2019 if you're on IPv6 and switch to your own DNS server that doesn't do DNS64, then it just plain won't work. I doubt Firefox or Chrome will have implementations that break like that.
> If your ISP is not trustworthy
Or country.
>Moreover, the centralized control of encrypted DNS threatens to harm consumers by interfering with a wide range of services provided by ISPs (both enterprise and public-facing) and others. Over the last several decades, DNS has been used to build other critical internet features and functionality including: (a) the provision of parental controls and IoT management for end users; (b) connecting end users to the nearest content delivery networks, thus ensuring the delivery of content in the fastest, cheapest, and most reliable manner; and (c) assisting rights holders’ and law enforcement’s efforts in enforcing judicial orders in combatting online piracy, as well as law enforcement’s efforts in enforcing judicial orders in combatting the exploitation of minors. Google’s centralization of DNS would bypass these critical features, undermining important consumer services and protections, and likely resulting in confusion because consumers will not understand why these features are no longer working. This centralization also raises serious cybersecurity risks and creates a single point of failure for global Internet services that is fundamentally at odds with the decentralized architecture of the internet. By limiting the ability to spot network threat indicators, it would also undermine federal government and private sector efforts to use DNS information to mitigate cybersecurity risks.
If your DNS server is in the cloud, your ISP can still see your unencrypted queries to that server. If it is at home, your ISP can still see the unencrypted queries of that server to the root servers.
Unless you encrypt the traffic, DNS is transparent to the ISP whichever way you set it up.
And unless you are also using a VPN, the ISP can learn most of what it can learn with DNS just by looking at the IPs you send packets too. Most commercial websites that matter aren’t sharing IPs.
And as you and others have said, it can be done by looking at IP addresses i connect to as well.
What I do achieve is that nobody has a "full" picture of me, but only some subset of data that I transmit.
I also use two independent ISPs in a loadbalancing/failover configuration, so that helps with the cause as well, thougb my primary use is fail-over since I am in this internet business :)
China is attacking it, ISP's are attacking it, all with loose arguments and fear-mongering.
First of all, I think the extent of the data collection that many companies engage in is sketchy.
That aside, if a website runs analytics that you don't like, you can stop using it. There are usually alternatives, if you're willing to give up some convenience. But if your local ISPs are monitoring you, not using the internet isn't really an option these days.
I really wish we didn't have to treat our ISPs as adversaries in that regard, but we've been at that point for a while.
I hope somebody in regulation will finally stop Google and others to monopolize the web.
let’s not munge it up either. they don’t care about encryption per se. they care about 3rd party resolvers.
So yeah, its going to chop off some of their revenue and they don't like it.
Google pissed in the punch bowl by offering google fiber.
This forced the carriers to perceive google as an existential threat they are absolutely dependent upon for cheap ass android and ISP revenue from YouTube.
The only move they could make was to make google bleed. So they start offering content monetization and competing advertising platforms. Their goal isn’t to win, it’s to HURT GOOGLE. Advertising prices go down when there is meaningful competition. So shitty content monetizatuon from Comcast and VZ & ATT forces the price of google advertising down.
There is a big part of me that is pulling for the carriers on this front. I’m bummed more people don’t see it this way.
Interference from browsers with network level operations is my real worry. As far as I'm concerned, as long as the browser speaks HTTPS to my router, and my router speaks HTTPS to the servers, no problem. I'm worried about the "to protect the users we've hijacked their DNS directly via the browser" possibility though.
I know it used to be that using ISP DNS servers gave you access to some of their local caching and such. I don't hear that talked about much in these discussions. Is that no longer a thing, and thus we truly don't need ISP DNS?
I don't understand how trading one ISP for another (Cloudflare?) is an improvement long-run. The system itself needs to be resilient, not just depend on the kindness of the upstream gods.
Mozilla and Cloudflare negotiated a special privacy policy for Firefox DoH requests [1] that limits what Cloudflare can do with the data – in particular, most information must be deleted after 24 hours. There is no technical measure holding them to that policy, but it’s a contract enforceable through the courts. Nothing similar applies to your average American consumer ISP.
[1] https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
That link isn't very reassuring. Who are parties to the contract? Who can enforce it? What does it cost to breach?
That's the main mechanism for enforcement, but there are a few additional ways it could theoretically be enforced:
- The FTC and state attorneys general can sue companies for violations of their own privacy policies, as "unfair and deceptive acts and practices". For example, they sued Cambridge Analytica recently. [1]
- The California attorney general in particular would also be able to sue under the California Consumer Privacy Act once it goes into force.
- As for ways for individual consumer to sue... well, it's more difficult, but possible. For instance, a class action suit against Facebook on a grab bag of claims, also related to Cambridge Analytica, recently survived a motion to dismiss. Among other things, the judge held that users could sue for breach of contract if Facebook violated its privacy policy. [2]
[1] https://www.ftc.gov/news-events/media-resources/protecting-c...
[2] https://www.cand.uscourts.gov/filelibrary/3755/Order-re-Moti...
So without DoH an ISP knows everything you request, even if you have a different DNS server set, and if they really wanted to they can simply hijack any connection you make.
Just seems very wrong to me to take the control away from the user/network-admin in any way. I mean, if you're gonna do it, go whole-hog. Delete HTTP from the browser entirely, right? I don't think that would go over well either, although it could certainly be justified by the same logic.
Maybe I'm misunderstanding something about the issue, there has been a fair bit of FUD, but I simply don't feel good about the browser taking authority outside it's "please render this code into a webpage" scope.
You are confusing the network admin and the user. Most users have little reason to trust their router, they often don't own it, update it or have any clue about it. Even experts change roles here when they use any other entities network.
I understand your use case, but I personally think the end devices should increasingly allow interception by network devices only with user consent, not implicitly.
In other words, opt-in on the device with DNS settings and certificates. If you don't own the device (e.g. have root/admin/etc), you don't get to control it - beyond blocking it.
It’s not being deleted, but Chrome at least has been gradually phasing in a warning in the address bar whenever you visit an HTTP site. [1] (Firefox will apparently do the same starting soon.) I wouldn’t be surprised if the warning UIs get more aggressive a few years down the line, as HTTPS adoption continues to increase.
[1] https://blog.chromium.org/2018/05/evolving-chromes-security-...
Basically, you just give it the bad IP addresses and it will replace every query result containing them with an NXDOMAIN.
So moving the DNS to Cloudflare only means “now Cloudflare have my entire browsing history as well as my ISP.”
I do appreciate there is a draft on ESNI but it’s not there yet.
DoH is not a privacy boon.
DNS, whilst plaintext is at least federated, and is a network level service. That is, its not tied to a single session in a browser.
as I understand it, there is nothing stopping a browser from appending metadata to the get request, or putting extra headers in. This means that its perfectly possible to nail your complete browsing history, down to the server you've been given.
The browser isn't interfering in any of your network operations.
Sounds like interfering with the way my intranet operates to me.
This change is explicitly protecting users from malicious network operators. Since you control the endpoints it should be no big deal, you apply GPO, run Puppet, whatever and everybody is talking to your local DNS again but it is absolutely right to not trust local unencrypted DNS by default for every network you connect to.
Aren't there some "hijacks" that are actually valuable to users? For example, if I run a network inside an extremely limited internet environment, I can hijack the user's DNS and redirect them to a "Hey, we're sorry, but running Netflix here will ruin the network for everyone, we hope you understand" page. If their browser is ignoring my local DNS server my option would seem to be simply black-hole netflix packets in the firewall, which is a lot less friendly to the user. Would I be a malicious network operator in this case?
There has been work on allowing networks to communicate out-of-band to browsers for administrative purposes. Even this is risky in general because of the phishing possibilities, among other things. Showing users arbitrary messages from network operators in the middle of the users' other browsing activities is likely to make it even easier to confuse the users into taking actions that they really didn't intend to do.
There's a strong case to be made that the vast majority of Chrome users aren't equipped to evaluate this question. These users are very unlikely to know if they're on an untrusted network and thus unable to make use of the kind of very useful switch you wisely suggest.
Perhaps offering a configuration option for the small percentage of technically sophisticated users who are willing to look in settings for it? Certainly Chrome Enterprise (which is a configuration management system, not a pay-for enterprise software offering) offers strong settings management tools.
Strictly from a security perspective, you always assume your network is untrusted and untrustworthy (and use protocols designed to work just fine in such situations). Especially when serving users who aren't equipped to make their own educated decisions. Can you help me understand why Chrome might want to behave otherwise?
For example redirecting the user to a fake webpage asking for their username and password.
A user will learn that there's blocking if they try and access Netflix and it doesn't work.
You can get something like a Juniper SRX firewall which can recognise applications via signature and do blocking that way. Rather than against IP ranges only.
Also as a network admin you're not saying why you won't be able to block DNS over HTTPS providers.
Unless you're thinking there's going to be some unknown DNS server used by the browser.
But if that's your fear you'll need to block all the online DNS lookup websites.
What if a user just types the IP address directly? Totally circumnavigates DNS.
(And yes, I set up a similar easy makeshift DNS solution to "authenticate" for the un-encrypted WLAN i had many years ago)
The network is compromised. This is the fundamental assumption of networks. If you operate from this position you are much less likely to get burned.
Mozilla and Google become unsatisfied with gethostbyname but they cannot change that part of OS. So they are solving their problems on their side.
> the browser speaks HTTPS to my router, and my router speaks HTTPS to the servers
Usually this isn't the case. Browsers that aren't configured to use a proxy connect directly to some web server using TCP and as speak HTTP to it. On a lower level, it's being facilitated by IP traffic routed by your own router, the ISP and the Internet.
There are "Forward" HTTP proxies (e.g. software like Squid) that act like HTTP clients on the web and provide the real user with results. I suppose they're being set up at large organizations by IT, or at home by privacy geeks but I know no consumer router that does that out of the box.
The question is whether Chrome is going to ignore system settings by default.
If a malicious app was to use their own DoH server then there's nothing you can do.
Well you can get a MITM web security product to inspect traffic.
Or only allow internet traffic through a proxy on your network and then block DNS providers.
Local caching via DNS? Perhaps on unencrypted HTTP traffic.
Google's plans being usually "obviously good" is a highly subjective opinion.
That doesn't mean that AMP is a great idea.
> And Google's employees have a large incentive to not see any issues with collecting all the personal information that exists.
I can only speak from personal experience. But I would not agree.
Collection of data needs to be covered in a privacy document. You must argue why you're collecting it. There has to be a retention plan, such that data is purged when the user account is deleted, and/or the data expires over time.
You can of course get exemptions, IF there is a valid business reason. But all of this needs to be reviewed and approved by privacy people.
If you want to get things done. The paperwork is a strong incentive to avoid keeping data you don't need.
Note. privacy reviews cover more than I mentioned here. This was just a highlight.
It's easy to make proposals that incrementally increase user security while simultaneously increasing one's own ability to consolidate and exploit user data. Technical appeal needs to be evaluated with a simultaneous critical eye to social impact (QUIC is a perfect example -- it outcompetes TCP on an equivalent link, and falls apart over variable-latency or highly unreliable connections, like those that exist in developing nations -- but of course, Google doesn't care about those audiences).
Do you have a citation for your claims? There is plenty of evidence to the contrary: https://www.blog.google/technology/next-billion-users/ .
Google doesn't even care if you're a paying customer -- they sell phones without expandable storage with the explanation that customers should just use the cloud (i.e., Google Drive) instead.
Laughable.
It was just an example in support of the point made in the parent: as far as Google is concerned, the only people that matter are ones with unlimited, fast and reliable Internet access at all times without exception.
If you thought I was facing some kind of dilemma regarding whether or not to buy a phone that is useless half the time I leave my house, then thank you, but that's not the case.
Still, ISPs are definitely higher up on the evil-o-meter.
Browser vendors generally try not to break millions of webpages overnight.
DoT would be preferable to DoH (no additional metadata / cookies,) but either way ISPs should adopt encrypted DNS.
You are correct it boils down to “who you trust.” In my country the ISP wins hands down over a foreign mega-corp so I end up making a different decision to you.
The key thing is that is a choice for users, not something software just does without knowledge of what’s going on.
encryption doesn't hide anything from whoever's on the other side, just the people in the middle. If the goal is to not let ISPs in on your DNS history, then DoH to the ISP won't do that.
Meanwhile, the Chromecast inexplicably ignores DHCP/NDP-provided DNS servers and uses 8.8.8.8 for all queries.
It kinda works everywhere but for some apps like Chromecast I have to null route two IP addresses (8.8.8.8 and 8.8.4.4) otherwise it doesn't work. Those are both Google's IPs afaik.
So my question is: will I be able to keep doing it after this? I am asking because I am extremely suspicious of Google these days and wondering if they have an ulterior motive to prevent users from doing such host based adblocking in future?
In comparison to your current position, where you're black-holing the hard-coded addresses and the app is falling back to your configured DNS: yes you will be able to continue doing that, assuming the Chromecast will maintain the same fallback behaviour. The exact addresses you need to block and the protocol/ports you need to block may change (eg. to port 443 tcp instead of port 53 udp).
The big thing that DoH will prevent is something that you aren't currently doing, which is: instead of null-routing 8.8.8.8, you could be intercepting DNS requests to 8.8.8.8 and responding to them yourself. You would need to do this if the chromecast didn't fall back to using your proper DNS server. DoH will prevent this kind of interception, so your only choices are to allow it through or block it. And if the Chromecast then refuses to fall back, then blocking it will make the device not work, with no viable workaround short of replacing the firmware.
The goal of DoH is ultimately to prevent your ISP doing the exact same thing to you, ie. intercepting (or just listening in on) your DNS requests even when you want them to go elsewhere. Unfortunately, there's no way to prevent the same protections from extending to a malicious local device trying to circumvent you on your local network.
If using Firefox you’ll need to manually change the DNS settings, as it will by default bypass your local DNS and send it to Cloudflare using DoH. You can easily disable that though.
My view is pretty basic: If I can see your DNS, I can pretty much guess on a very short list what kind of [browsing] behavior you are engaging in.
What you can infer is why and who. Which is the real danger. I would trust google to protect sensitive data like sexual preferences before I trust my ISP.
Google has attempted to allay some of these concerns, but their initial blog post [1] makes it lear that only certain whitelisted DNS providers would be permitted to participate. That does imply a degree of centralization regardless of Google's assurances to the contrary.
[1] https://blog.chromium.org/2019/09/experimenting-with-same-pr...
https://gist.github.com/MatthewVance/5051bf45cfed6e4a2a2ed9b...
Browser -[regular DNS]-> pihole -[regular DNS]-> cloudflared -[DoH]-> 1.1.1.1
So of the 3 hops, only 1 uses DoH. And specifically, the browser itself doesn't talk DoH.
There is a way to configure your network to make Firefox not do this, so that's good. But it's not the default.
Mozilla added a canary domain (use-application-dns.net) that if blocked will default to the local dns resolver. There are several threads in the pihole community about blocking it by default so I expect that will be done before mozilla turns int on for the masses.
That’s what I’m referring to.
It sounds harder than my simple “redirect all outgoing DNS requests to my PiHole” rule that I have set up in my router.
No messing with any DNS settings required.
What is the case, however, is that you could set up a DoH endpoint on some other network and route your DNS there.
Regardless, it’s a tiny thing to give up for more privacy.
Mozilla's method of implementing this has also created a blueprint for malware to avoid network-level detection.
I don't like it. In my view, what's being given up is significant and the privacy gain minimal.
(Right now, Mozilla has a DNS-based killswitch, but how long until all the 'bad actors' Mozilla is targeting have implemented it? I know of one public DNS provider already doing that. They'll take away the killswitch, then all the 'bad countries' will force their populations to install MITM certificates [along with the UK] and the world is going to end up worse off thanks to Mozilla)
So the ISP still has a log of which IPs you’ve visited. They can resolve this back to site names and get the same information on you they had before.
Edit: answer here: https://security.stackexchange.com/questions/200201/how-does...
[0] https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
It seems like it's touching a nerve and advertisers and governments are really sweating losing their ability do low effort snooping.
But it's cute how ISPs are trying to mash deploying of DoH support and default to Google server into one issue.
The last paragraph absolutely seems like fearmongering:
Moreover, the centralized control of encrypted DNS threatens to harm consumers by interfering with a wide range of services provided by ISPs (both enterprise and public-facing) and others. Over the last several decades, DNS has been used to build other critical internet features and functionality including: (a) the provision of parental controls and IoT management for end users; (b) connecting end users to the nearest content delivery networks, thus ensuring the delivery of content in the fastest, cheapest, and most reliable manner; and (c) assisting rights holders’ and law enforcement’s efforts in enforcing judicial orders in combatting online piracy, as well as law enforcement’s efforts in enforcing judicial orders in combatting the exploitation of minors. Google’s centralization of DNS would bypass these critical features, undermining important consumer services and protections, and likely resulting in confusion because consumers will not understand why these features are no longer working. This centralization also raises serious cybersecurity risks and creates a single point of failure for global Internet services that is fundamentally at odds with the decentralized architecture of the internet. By limiting the ability to spot network threat indicators, it would also undermine federal government and private sector efforts to use DNS information to mitigate cybersecurity risks.
I don't see how IoT management is going to be affected by DNS resolution made by a browser. CDN's DNS server in any case sits upstream and should be able to perform needed optimization. Google's or any other US DNS provider is not exempt from complying with the US law and court orders.
Your reasoning sounds like, I'm not going to do breakfast for my family, because, ya know, if I drop dead, they will miss the breakfasts.
That it's not their biggest concern doesn't mean that it won't be a concern, nor did it mean that it's not something he can avoid becoming a concern.
Some of the comments here are taking the piss...let see how you feel when you hold your baby for the first time.
Btw, for context, in the last 3 years I have had perfectly heathy friend that was in perfect shape drop dead from unexpected heart issues at 38. He had 3 kids. Another friend with 2 kids was killing in a car wreak at 44. Looking at the things their family’s have had to deal with is the reason why I am thinking about this.
Look, I did not want to insult, sorry if it came across like that. I just wanted to point out that _in this specific instance_ you may exaggerate the cost of switching from your weird techy stuff to a commodity solution.
That doesn't say anything about your general principle - which is totally reasonable.
That's the only reason I see Google will try a move like that.
DNS privacy is awesome. Filtering malicious and annoying (read: ads) content at the DNS level is mandatory for me..
If providers want to keep vacuuming personal data they can provide DNS over HTTPS and they'll capture the same amount of data.
The ISP can still do a reverse look up of the IP address to see where the traffic is going.
Wait what? Hows that gonna play with my existing pihole setup?
As my mom said - if you cry enough to fill a tank I'll buy you a goldfish.
It wont necessarily be Google... From what I understood from the article, if you're currently using OpenDNS, Cloudflare DNS, etc., after the change you'll still continue to use them, only the protocol used to access them will change...
Directing users to local CDN instances has now got harder, which means its going to cost more for things like netflix
In the US, yes, that means that ISP can't mine youre data, however, you are handing more information to google.
But that status is fragile. The ISP has to act like it knows its obligations in law, and there are things ISPs have been doing to work with LEA for a long long time, which they won't be able to do as simply, or as well, or in some cases at all.
As a customer its easy to assume the only answer is "good" but in fact, its more complex. Society depends on law, and the application of law around what people do online is not trivial, and does not reduce down to 'all snooping is always bad all the time' -Warrants exist to do things, and warrant canaries are a reaction to them but not one which says warrants don't exist: they say silent warrants should not be obligated on the receiver of the interception: They're a position on secret law, not a position on law in itself.
TL;DR DoH and DoT are challenging established law in telecoms and big ISPs who have common-carrier defence depend on interception in DNS and DPI and the like, to perform their role facing LEA demands from the state which in many cases are entirely normal and justified
Not all DoH and DoT stories are good stories for society at large.
Please don't reduce this to a libertarian vs everyone else debate, I would invite you to think about what an ISP is, and what we want from ISPs as a whole, not just as customers seeking pirate bay, but as a society investing in a telecommunications-rich future.
The first casualty of war is the truth. The second (in WWI and WWII) was the deep sea telecommunications cables.
Common carrier defence is not going to be lost from encrypting URLs, the same FUD was spread about encrypted banking then the encryption of most websites. The only thing that has resulted from the increase in encryption is the decrease of ISP injected ads and the decrease of customer tracking information being sold.
Why do you think Mozilla turns this on selectively?
As I understand the current caselaw, whilst an ISP is required to make some efforts, they are not required to make efforts when a task is impossible or difficult.
If an ISP is required to create a porn filter, for example, they aren't also required to try and forward that blocker across Tor.
Rather a "best effort" is exactly what is legally required.
So when a new technology is adopted that makes their previous "best efforts" obsolete, then they will no longer be forced to attempt something that is no longer possible.
However, that whole conversation is mute when it comes to this particular instance.
Google will attempt to use the ISP's own DoH resolver. So the answer is simply to run one, or not. If Chrome can't find a DoH with the current DNS, it'll fallback to today's behaviour. This isn't changing the status quo at all.
It's only a problem if customers move wide-scale away from the ISP's own DNS servers. Which happens when the ISP's interests conflict with the user's already, so again, no change to the status quo.
They can't provide what they don't have. ISPs in the US (and I presume most countries) aren't obligated to ensure their customers don't use encryption.
And it's legislation that no Government is in any hurry to amend because it serves their purposes in maintaining the façade of 'keeping our citizens safe'.
Additionally, this statement is almost entirely the opposite of my understanding. DoH ENSURES that ISPs cannot be held responsible at least for the DNS content since they cannot see it for technical reasons:
TL;DR DoH and DoT are challenging established law in telecoms and big ISPs who have common-carrier defence depend on interception in DNS and DPI and the like, to perform their role facing LEA demands from the state which in many cases are entirely normal and justified
- The hosts file should still take effect (Chromium can read the hosts file and parse it already.)
- The DoH upgrading should not override your default resolver. It works by having a lookup table of providers that support DoH and using DoH if your provider supports it. The list can be seen here: https://cs.chromium.org/chromium/src/net/dns/dns_util.cc?q=D... (note: this URL may become stale over time; there’s ways to improve this but I am on mobile at the moment.)
Google sneezes and this is gone.
We didn't think they'd take away extensions' abilities to block ads, and yet here we are.
We've seriously got to pursue breaking this company up. They're the absolute worst.
How is it a serious misrepresentation?
Manifest v3 cripples the ability to block ads.
Google is an ad company and has the largest browser market share by far.
How is this not abuse?
Google can claim that things like AMP are not intended to rope us into their walled garden, that it's all about improving performance. But at the end of the day, most of the moves they make further their goal of serving more ads.
In twenty years I wouldn't be too terribly surprised if independent websites are largely gone. Disappeared like IRC, RSS, blogging on your own website, and the like.
I'm sorry you disagree. I just don't like what I see happening.
Personally, I would have liked to see strong privacy laws fill the gap, but it looks like DoH is here to stay now.
Absolutely. You can find a dishonest ISP. The difference is that there are thousands of them. And not just one big opaque entity.
Starting with version 78, Chrome will begin experimenting with the new DoH feature. Under the experiment, Chrome will "check if the user's current DNS provider is among a list of DoH-compatible providers, and upgrade to the equivalent DoH service from the same provider," Google wrote. "If the DNS provider isn't in the list, Chrome will continue to operate as it does today."
A single company is easily legislatable, auditable, fineable, and chargeable if offenses are found. A thousand individual bad actors? The odds decrease.