Encrypting the Page Is Not Encrypting the Address
Android 17 can hide a destination inside the TLS handshake, but DNS, app libraries, and servers still decide whether the address stays private.
HTTPS can hide every sentence on a page while the connection introducing that page still says its name out loud.
The leak sits near the beginning of a TLS connection. A client traditionally sends the website’s hostname in the Server Name Indication field of its ClientHello so a server hosting many sites knows which certificate and configuration to use. The page content is encrypted, but a network operator watching that hello can still learn the destination.
Google’s August 27 Android 17 announcement says the operating system now supports Encrypted Client Hello, or ECH, across its networking platform. ECH wraps the private hello, including the real server name, inside an encrypted outer hello. The destination can open it with a published key. Somebody carrying the packets between them gets the envelope, not the name written inside.
That is a meaningful privacy improvement. I am also wary of the phrase “Android supports ECH” doing more work in a headline than the feature can do on a real connection.
Privacy belongs to the whole route
The ECH standard is unusually direct about one dependency: “ECH requires encrypted DNS to be an effective privacy protection mechanism.” Encrypting the server name during TLS does not help if an ordinary DNS query announced the same name a moment earlier. Android therefore pairs ECH with Private DNS, which protects the lookup used to obtain both an address and the server’s ECH configuration.
The app has to participate too. Android 17 supplies new pieces in its DNS resolver and TLS implementation, but the developer documentation describes networking libraries as beginning to adopt them. Google’s announcement tells developers using OkHttp to upgrade to version 5.5.0 and enable ECH. An app with its own network stack does not become private because the operating system learned a new protocol underneath it.
The destination has another job. It must publish a usable ECH configuration and operate a front end that can decrypt the inner hello. Google carefully limits its promise to supported websites and apps. The Hacker News independently reported that servers without ECH support remain part of the rollout problem, while Android sends randomized ECH-shaped extensions to unsupported sites so protected and unprotected attempts are harder to distinguish on sight.
ECH is a property of the whole route. Encrypted DNS keeps the lookup private. The app asks for and uses the ECH configuration. The server accepts the encrypted hello. Miss one section and the hostname may return to clear text.
Putting support into a mobile operating system still matters. A common platform implementation gives browser engines and app libraries something consistent to adopt. Developers do not each have to invent their own TLS privacy layer, and users do not have to recognize a Server Name Indication field before they receive protection.
The platform also cannot turn ECH into network invisibility. A carrier or Wi-Fi operator can still see that a device connected to an IP address, when it connected, and how much traffic moved. Shared hosting can make one address correspond to many possible sites, which gives ECH a useful anonymity set. A dedicated address can narrow that set sharply. The website itself still knows who arrived, and logins, cookies, browser fingerprinting, and app analytics keep their own records. ECH closes a specific metadata leak. It does not make the rest of the connection anonymous.
Coverage decides what users get
I like the engineering shape of ECH because it repairs a piece of old protocol history instead of asking people to browse more carefully. HTTPS became visually synonymous with a private connection long before it concealed every useful clue around that connection. Encrypting the ClientHello brings the machinery closer to what the padlock has implied to ordinary users.
The Android rollout also exposes an awkward truth about privacy infrastructure. A specification can be finished, a major operating system can ship it, and the protection can still arrive unevenly by app and destination. Early coverage will be difficult for a user to inspect. Two apps may contact the same service through different libraries. One site may publish ECH while another at the same company does not. A connection can quietly fall back without producing the kind of obvious failure that would tell someone the hostname leaked.
That is where Google’s claim should be measured. “First major mobile OS to enable broad ECH support” is a useful starting fact, not the outcome. I want Android to expose aggregate, non-sensitive diagnostics that let researchers see how often ECH is offered, accepted, rejected, or bypassed by incompatible stacks. App developers should be able to test the whole path rather than stop at an API call that returned successfully. Large services should publish their deployment status and explain fallback behavior. Privacy coverage needs evidence just as uptime does.
I would rather Android ship broad support with fallback now than wait for every server and app to be ready. Refusing every connection without ECH would break old servers, captive portals, unusual enterprise networks, and apps that have not caught up. Fake ECH extensions also help prevent the act of asking for privacy from becoming its own identifying signal.
Fallback has a less comfortable side: the connection keeps working when the protection does not. That trade is defensible during rollout, but users and researchers need some way to see where it happens.
Android 17 now protects a hostname that HTTPS used to expose. The remaining measure is coverage: whether private DNS carries the key, app libraries use it, servers answer, and public diagnostics reveal the gaps.