The latest browser privacy feature brings new dangers of its own

As the internet has shifted to securing data and encrypting traffic by default, one surprising privacy hole has remained, which leaves a trail of sites you visit open to sniffing by network ne’er-do-wells. A proposal to remedy this is being rolled out slowly—by Mozilla in its Firefox browser and by Google in Chrome.

This new technology approach, called DNS-over-HTTPS (DoH), can shield your browsing habits from ISPs such as AT&T, Comcast, and Verizon, who have at times showed a propensity to track users by using supercookies and other techniques. (Sean Captain offers advice on how to use DoH in “Here’s how to stop Comcast, Verizon, and other ISPs from spying on you.”)

But security can be a two-edged sword. This technology for shielding your actions from ISPs, public hotspots, and other institutions has the potential to introduce a new privacy risk: the centralization of browsing habits. It also highlights existing privacy leaks that DoH doesn’t solve and could exacerbate.

What’s in a name? Everything

Unless you use a virtual private network (VPN) connection, someone with access to a public network you use can determine every web site you visit, every email server you contact, and every other kind of online server your mobile device or laptop connects with, even when each connection is encrypted. This is also true on any shared network in which network traffic isn’t shielded from other users on the same network, or which administrators can monitor.

That’s because of the last truly exposed plumbing fixtures of the old internet: DNS, or domain name service. DNS is an ancient system developed when the number of computers on the internet outpaced people’s ability to manually update lists of them. Yes, it’s that old. Instead, DNS provides a way to map a human-readable and typeable name, such as fastcompany.com, to the appropriate machine-oriented address, like 151.101.1.54 or 2607:f8b0:4004:814:200e. (The former number uses the long-running IP version 4 notation; the latter, IPv6, allows for vastly more unique numbers and has rolled out slowly as an eventual replacement for IPv4.)

Not only do you not want to type those numbers in or memorize them; DNS has grown vastly in complexity since its early days, allowing a single name to map to many different machine identities to allow “round-robin” access that helps balance traffic loads. It’s also used by content-distribution networks (CDNs), such as Akamai and Amazon CloudFront, to offer a server address that’s geographically closest to the device requesting it, reducing the number of internet hops and thereby improving performance.

And DNS is also a way to stash a lot of other additional information related to a domain and its owners. So-called text (TXT) records allow any arbitrary information to be added to a DNS entry. Google allows a TXT record to verify a domain ownership, just like a message is sent to an email address to validate that someone has access to that mailbox.

When you make a network connection via Wi-Fi, Ethernet, or cellular, one of the things your device receives is a list of DNS servers. Your device sends the query to the DNS server, which consults a master list of all TLDs (top-level domains), like .com, .aero, and .uk. Using a hierarchy from right to left, separated by periods, the DNS server eventually finds an “authoritative” DNS server that provides an answer, and then that answer is handed back to your device. Not exactly simple, but at least somewhat straightforward.

For instance, a browser trying to reach fastcompany.com starts by consulting the .com hierarchy for where fastcompany.com has its entries stored—the servers that feed out DNS information are called “nameservers”—and then consults the fastcompany.com nameserver directly to receive the records required to create a direct connection by machine address. Fast Company uses a CDN, like most sites that see a lot of traffic, and the machine address you receive may be different from someone 2,000 miles away, or possibly even 100 miles away.

The trouble is that every time a DNS lookup occurs, the domain names are sent in the clear, even if the rest of the communication is encrypted, as web and email connections are likely to be, thanks to the massive uptake of encryption in the post-Snowden era. A PC might send thousands of DNS requests a day, due to all the tracking components and third-party elements used on modern websites.

Because of CDN retrievals, someone monitoring domain lookups and the IP address responses may be able to derive a cluster of information about your habits and whereabouts, sometimes with incredible granularity.

DNS is fusty and obscure. It’s such a mess that in 2008, security researcher Dan Kaminsky uncovered a fundamental flaw that affected nearly every operating system and server in the world. He worked diligently to keep it secret until Apple, Microsoft, Google, and other firms could paper over it. (It’s never been fully fixed.) In 2015, a bug in a popular DNS server—software that handles responding to queries—allowed trivially easy denial-of-service attacks.

DNS also lacks verification, allowing “DNS poisoning,” in which a wrong answer can be provided to a device asking for a domain name lookup without that device being able to know the answer was subverted. This is most likely to happen at a coffee shop or other public network, but it can happen on a country-wide level too.

DNS-over-HTTPS would fix privacy and some of the integrity issues. Instead of a DNS query being passed in the clear and using the local network’s DNS server, Firefox and Chrome effectively create a VPN only for DNS. The query is sent through an encrypted tunnel to a central service that provides the answer. This prevents local poisoning and interception locally and at all points in between. The entity running the central server can perform queries to other DNS servers to retrieve answers without leaking anything about the requesting parties too.

But it’s the “central” part that’s a problem.

Who watches the DNS watchmen?

The trouble with DoH isn’t its concept. Rather, it’s in how different browsers propose to enable it by default in upcoming releases. Mozilla’s Firefox is starting with U.S. users only, after testing for over a year and picking Cloudflare as its anointed partner. Google will soon begin testing DoH in Chrome but will initially only enable it for people who have already chosen a set of ISPs that have a DoH option available.

Most consumers have DNS service provided by their ISP, either through preconfigured settings in a router provided by the ISP or by entering the IP addresses for DNS servers provided by the ISP. (In a chicken-and-egg problem, a DNS server is required to look up a name, so you have to start by entering the IP addresses for servers to prime the pump.)

Millions of people and organizations have already shifted from ISP-provided DNS to one of several public DNS providers, such as Google, OpenDNS, and Cloudflare. These services arose when most ISPs ran DNS servers without much care, leading to lengthy delays as sites were looked up. Well-optimized public DNS sped that up.

The end result is a de facto centralization of DNS, with most users entrusting their internet activity to a few huge companies, such as Comcast, Verizon, and Google. However, DoH could centralize that further. While Google’s Chrome tests will simply upgrade users who have already picked one of a few public DNS providers who are already offering DoH, Mozilla will shift people’s Firefox browsing from relying on their ISP or public DNS to Cloudflare’s DoH offering. (Parents who use a filtering service that relies partly on DNS for blocking and corporate users with internal-only DNS lookups will be opted out of DoH, though how effectively remains to be seen.)

Even though DNS by itself is insecure, it’s also a sort of jumble that makes it hard to track back and associate a set of DNS requests from a single device. By creating secure https connections, DoH allows all requests to be strongly associated.

Centralization provides strong incentives for organizations that have access to data to engage in off-white, gray, and black hat behavior. “Beige” companies might be tempted to aggregate “anonymous” information that can be reassociated with individuals or used to extract insights that DoH users haven’t directly consented to provide. Ethically ambiguous parties might extract or attempt to intercept information about connections. And outright black-hat crackers could focus all their energy on penetrating the security of firms offering centralized services. DNS is a hoary protocol, and DoH is stapled on top of it.

Many other objections have been raised to a variety of competition- and privacy-reducing aspects that critics call “Centralized DoH.” A draft paper submitted to the IETF (Internet Engineering Task Force) notes that the rapid deployment of this mode skips over the fact that ISPs are interested in or planning to deploy DoH service and that shifting to central DoH bypasses protections and agreements in place between ISPs and customers.

Three of the paper’s four authors work for big ISPs: BT, Comcast, and Sky. And many of the concerns raised are identical to public DNS, such as creating fewer, bigger single points of failure, reducing the number of people who understand and work on maintaining and improving DNS software, and concentrating power in fewer hands with less responsibility.

However—and it’s a big however—people who use public DNS have almost always made a conscious decision to do so. With Mozilla’s Firefox move, users are being pushed into DoH. Google’s initial plan for Chrome isn’t as aggressive, but that could change.

The folks behind the open-source PowerDNS lay out a host of reasons why centralized DoH adds additional privacy leaks, because while DNS already spews data all over the place, pushing DoH to one location adds additional parties into the mix and more direct session tracking.

Expedient, but not ideal

Securing DNS is way overdue. As a cranky old piece of the internet’s lifeblood, it’s baked in so deeply and it’s so decentralized in its nature that it—like mail server communications—is hard to upgrade without scrubbing the slate clean.

But hasty action is often worse than considered plans. DoH would work best at an operating system level or as a user-installed system-level component, where it can be used as a proxy for all DNS queries—not just in a browser, but for all services. While ISPs have their own privacy issues regarding their users, the direct financial relationship for service provides the potential for more accountability than if DoH is provided by a third party you aren’t paying.

DoH has been cited as a way for people at risk of action by their governments or populations in repressive countries to avoid scrutiny. But single points of service, like central DoH addresses, are far easier to block than VPNs that constantly shift IP ranges to evade censors and government agents.

If you don’t use a VPN on insecure networks—whether they’re managed by a coffee shop or an entire country—DoH is a potential improvement. But a VPN is a choice and one you can evaluate and implement. Centralized DoH, by contrast, appears to be on a path to becoming a de facto piece of plumbing rather than something individuals choose to buy into.

DNS’s future is encryption, but centralizing a service that has thrived in its creaky, weird old way for decades is only an expedient solution, not a great one.