Mozilla has said it plans to make a privacy technology called DNS-over-HTTPS (DoH) the default setting for US users of Firefox within weeks.
As our previous coverage explains, DoH encrypts Domain Name System (DNS) queries, which browsers use to resolve website addresses to their underlying numeric IP addresses.
Normally, these requests are sent in the clear, which means that ISPs and governments can see which web domains someone is visiting, which is where the privacy concerns begin.
In the US, ISPs have been accused of selling this data to advertisers. Although not a perfect shield against DNS snooping, DoH makes that a lot harder.
The technology’s been inside Firefox since mid-2018 although until now users had to enable it manually. In September 2019, Mozilla started testing DoH-by-default in the US – with that completed, from next month DoH will become a setting that users have to consciously opt to turn off.
Users can do this via Options > General > scroll down to Network Settings at the bottom of the page and then click Settings. The ‘Enable DNS over HTTPS’ tick box is the last one on the page.
Notice how buried this setting is? Having backed DoH development since its earliest days in 2017, Mozilla doesn’t want to make it easy to turn off something it thinks is against the user’s interests.
Just below the tick box, there’s a second setting that allows users to choose which trusted DNS resolver to use. Cloudflare, Mozilla’s long-time DoH collaborator, is the default but recently users gained the ability to choose a second, NextDNS.
Trusting DoH providers
This aspect has bothered some critics – using companies such as Cloudflare effectively centralises DNS resolution for the tens of millions of people who use Firefox.
It’s a weak argument. People already set alternative DNS resolvers for performance reasons (Google’s 126.96.36.199, for instance) so the idea of using one service provider is hardly new. And is the alternative of routing DNS queries through an ISP’s servers any less centralised?
From an internet topology perspective, perhaps. But browser users don’t care about that. What bothers them more is: Who is recording the websites they go to?
As Mozilla reminds us, currently in the US, 80% of traffic travels through the DNS servers of only five broadband providers. All that using Cloudflare or NextDNS requires is that users trust these companies’ promises to protect privacy in the same way they do for any service provider. It’s a personal choice.
What to do
There are currently no plans to turn on DoH by default outside the US, most likely to defuse criticism by government agencies that it will, in the short term, make it harder to keep tabs on illegal activity by citizens. Google, which also backs DoH, is experimenting more cautiously than Mozilla.
Similar arguments were once made about the risk posed by HTTPS security and, in the 1990s, the spread of encryption more generally. But anyone who is serious about evading web surveillance can already do that in several ways that are more effective than using DoH, for example using Tor or firing up a VPN.
For non-US users, DoH can be turned on using the same settings mentioned above.
The technology can also be configured with slightly more difficulty in rival browsers such as Chrome, Edge, Brave and Opera although not, so far, in Apple’s Safari. The technology is coming to Windows 10 at some point.
Latest Naked Security podcast
Click-and-drag on the soundwaves below to skip to any point in the podcast. You can also listen directly on Soundcloud.
4 comments on “Firefox rolling out DNS-over-HTTPS privacy by default in the US”
Is there any downside to enabling DoH for browser users?
You might consider it a downside that you are now letting your browser decide which third-party company to trust with your DNS lookups (there aren’t yet that many DoH servers to choose from) – same sort of concern you need to have when picking a VPN provider.
You also need to remember that this only shields your browser’s DNS lookups from snooping, not all the other myriad lookups by other software you use – in other words, it might not give you as much additional privacy as you first thought.
Some critics have therefore suggested that, because this issue really ought to be fixed at an OS level, browser-specific fixes are a sort of halfway-house that gives a false sense of security and might delay adoption of a proper solution.
Critics of those critics say that “owts better than nowt”, and because DNS lookups by your browser give away more about you than lookups by pretty much any other app, this is a good start.
Excellent answer, thank you very much. I would have to align myself with those you describe in your closing line. Stated another way, “Never let Perfect be the enemy of Good”.
The one thing I really don’t like about that “never let perfect get in the way” aphorism is that it can be rewritten with pretty much the same meaning with the words “that’s just about good enough and we’re going to stop there because we can use the ‘law of diminishing returns’ as an excuse”.
The next TLS bridge to cross is SNI (server name indication), which is the phase in a TLS connection setup where you tell the other end which hostname you want (because hosting services may run 1000s of different sites from one IP) in order to get the right certificate up front for the URLs you will be asking for later.
At the moment, a lot of (most?) TLS sessions start with an SNI part that is *unencrypted*, which leaks at least as much data about your browsing habits as a DNS request.
The latest implementations of TLS allow encrypted SNI, but lots of sites still don’t support it.