# Android 17 Hides the Site Name, Not the Whole Journey

> Android 17 brings Encrypted Client Hello to mobile connections. It closes a revealing gap beside HTTPS, but the address, timing, app, and destination can still leave clues.

- **Author:** Kubilay Tunca
- **Published:** 2026-08-28
- **Category:** For Experts
- **Tags:** Network Privacy, Android, Encrypted DNS, TLS
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/experts/news/android-ech-hides-the-name-not-the-journey

---

Your phone can encrypt every word sent to a website while still announcing the website's name to the network carrying it. The hotel cannot read your bank balance over HTTPS, but a device on the path may still learn that your phone asked for `your-bank.example`. That name can reveal plenty before anyone sees a page.

Android 17 closes one of the old windows that made this possible. On 27 August 2026, Google announced broad support for Encrypted Client Hello, usually shortened to ECH. The change encrypts the destination name inside the opening TLS handshake when the app, network stack, and server all support it. Used beside encrypted DNS, ECH makes a simple list of visited domains much harder for a local network or internet provider to collect.

That is real progress. It also has a hard edge. The observer can still see an encrypted connection, its timing, its size, and the network address it reaches. A server that does not offer ECH cannot receive an ECH-protected name. An app that uses an older network library may take the familiar route. The improvement deserves attention precisely because we can say what it covers without pretending that an Android update turns a phone invisible.

## The name that HTTPS used to leave on the envelope

Open a website and several conversations happen before its page appears. Your phone must learn where to send the connection. It then negotiates encryption with the server. Only after that setup can the browser request a page inside the protected channel. Each early step has historically exposed a different clue.

DNS handles the first job. It turns a name such as `clinic.example` into a numerical network address. Plain DNS sends that question in a form the network can read. Encrypted DNS puts the question inside an encrypted connection to a resolver, which prevents a nearby observer from reading the lookup directly. The resolver still receives the query because answering it is the resolver's job.

TLS handles the next job. Modern HTTPS uses TLS to verify the server and encrypt application traffic. A single network address can host hundreds of unrelated sites, so the opening handshake has to tell the shared service which certificate and site the phone wants. That clue is called Server Name Indication, or SNI.

TLS 1.3 encrypted most of its handshake, but SNI remained visible in the first message from the client. The [IETF's March 2026 ECH standard calls plaintext SNI “perhaps the most sensitive information left unencrypted in TLS 1.3”](https://www.rfc-editor.org/rfc/rfc9849.html). The phrase is unusually direct for a standards document. Anyone on the path could read an explicit destination name even when the content that followed was protected.

Picture a sealed letter with the recipient's organisation printed across the envelope. The carrier cannot read the pages inside. It can still sort every envelope marked oncology clinic, addiction service, union office, opposition newspaper, or dating site into separate piles. Content encryption protects the message. The exposed name describes the relationship.

The distinction matters because browsing metadata is often enough to support an inference. A connection to a general news service says little by itself. Repeated connections to a specialist legal practice shortly before a public disclosure narrow the story. A visit to a particular medical provider after a call to an insurer can narrow it further. No one needs the page path when the organisation at the destination carries the meaning.

Google's [27 August Android announcement describes that old condition plainly: HTTPS could protect a connection while leaving website and app domain names visible to network operators and eavesdroppers](https://blog.google/security/new-android-network-security-protections/). Google says those names can support profiling or targeted scams. The Android 17 change aims at the explicit label on the envelope.

ECH creates two versions of the opening TLS message. The inner version carries the real destination name and other sensitive fields. The phone encrypts it with a public key advertised for the ECH service. An outer version carries enough ordinary-looking information for the connection to reach the front door, along with the encrypted inner message.

The client-facing service opens the protected message and sends the inner handshake to the correct destination. An observer on the path sees the shared front door rather than the private site name behind it. Where many sites share that service and behave similarly from the outside, they form what the standard calls an anonymity set. The observer knows which provider received the connection but has a harder time telling which member of the set the phone selected.

This gives ECH its value and its limit in the same mechanism. If a private site sits behind a large shared service, the crowd can be useful. If the site occupies a dedicated address that no one else uses, hiding its name changes little because the address already points to one answer. Privacy comes from both encryption and company.

## Android changed the default path, not every path

Browser privacy features often arrive as a toggle that only careful users find. Android 17 matters because operating-system support can make ECH ordinary across more connections. A protection used by default creates a crowd; a protection reserved for specialists can make those specialists stand out.

Google describes Android 17 as the first major mobile operating system to enable broad ECH support. The company built the work with Jigsaw and says it is working with service providers and app developers to expand adoption. That platform claim was [independently reported by 9to5Google on 27 August](https://9to5google.com/2026/08/27/android-17-network-security/), along with the requirement that app developers move to a compatible network stack.

The word “support” carries work for several parties. The phone needs an ECH implementation. Its DNS path needs to obtain the service's ECH configuration. The app must use a compatible library rather than bypassing the platform path. The destination or its fronting provider must publish and accept ECH. Remove one participant and the private name may return to view.

Google's concrete instruction to Android developers is to upgrade to OkHttp 5.5.0 and enable ECH. OkHttp is a common library through which Android apps make web requests. Apps with their own networking code have to follow Google's technical recommendations for retrieving HTTPS DNS records and handling the connection correctly. A new operating system cannot rewrite every private network stack shipped inside every app.

That difference will make early measurements messy. One app on the same Android 17 phone may protect a destination name while another exposes it. A browser may use ECH for one website and lose it for the next because the second host has not published a working configuration. A person looking at a settings screen cannot safely infer that every connection now behaves alike.

ECH GREASE helps with one part of that uneven rollout. GREASE is a compatibility technique that sends a harmless ECH-shaped value even when a real ECH configuration is unavailable. The goal is to stop network equipment from assuming that the extension is rare or safe to block. If middleboxes see the form during ordinary traffic, implementations are less likely to freeze around an old handshake shape.

GREASE does not hide a destination that lacks ECH. It makes ECH-looking handshakes common enough that genuine use does not advertise itself merely by carrying the extension. This is valuable maintenance work, but it cannot conjure the server key needed to encrypt the private name.

The server side has its own failure modes. A stale DNS record can advertise an old key. A fronting service can reject a configuration it no longer recognises. Network software can interfere with the newer handshake. The standard defines a retry path so a client can receive a fresh configuration, but a privacy feature that breaks too many connections will be disabled or bypassed. Compatibility is part of the security boundary.

For organisations, the practical test should happen on the wire. Take a current Android 17 device and a representative build of the app. Capture traffic on a network you control. Check whether DNS is encrypted, whether the destination advertises ECH, whether the handshake accepts it, and what happens after key rotation or failure. A release note proves availability. A trace proves your path.

For users, the situation is simpler. Keep the operating system and apps current. Use Private DNS where Android offers it, unless a workplace or specialist setup gives you a reason not to. Expect protection to improve across the web rather than arrive everywhere at once. Anyone selling ECH as a finished anonymity layer is getting ahead of the deployment.

## Encrypted DNS and ECH close two different windows

A private handshake can still be betrayed by a public lookup. Before the phone encrypts the site name inside TLS, it often asks DNS where that site lives and whether it advertises an ECH key. If that question crosses the local network in plaintext, the observer learns the destination without reading the handshake at all.

This is why Google's announcement says ECH works in tandem with Private DNS. The two protections cover different steps. Encrypted DNS hides the lookup from the nearby network and ordinary internet path. ECH hides the destination name in the subsequent TLS opening. Running only one leaves the other window open.

The DNS resolver occupies a special position. It must know enough to answer the question, so encrypted DNS shifts trust rather than removing it. Your hotel may lose a readable list of lookups while the selected resolver gains one. Resolver policy, logging, jurisdiction, account linkage, and network address therefore remain part of the threat model.

A phone can also reveal destinations through its choice of resolver connection. If it sends all encrypted DNS requests to one large service, a local observer sees the resolver but not each question. If an app ignores the system and uses its own resolver, that app creates a separate pattern. Centralising queries can improve the local privacy set while concentrating knowledge with the resolver operator.

ECH configuration delivery adds another dependency. The client usually learns the public key through HTTPS DNS records. Those records tell it which shared public name to use, which key can protect the inner message, and which parameters the service accepts. Incorrect or stripped records can prevent ECH before TLS begins.

The IETF standard says this plainly. [RFC 9849 warns that ECH alone cannot protect server identity because plaintext DNS and visible server addresses can reveal the target through other channels](https://www.rfc-editor.org/rfc/rfc9849.html). It points to DNS over HTTPS, DNS over TLS, and DNS over QUIC as ways to conceal lookups from network inspection. The standard makes no promise that one encrypted field erases the rest of the route.

Consider a journalist using airport Wi-Fi. Encrypted DNS can stop the airport network from reading a lookup for a source-protection service. ECH can stop it from reading the same name in the opening TLS message. The airport still sees an encrypted connection to a particular network address at a particular time. The DNS resolver sees the query. The service sees the connection from the phone's public address or VPN exit. Each party holds a different slice.

Add a reputable VPN and the slices move again. The airport sees an encrypted tunnel to the VPN. The VPN can see destination addresses and may see DNS requests depending on the setup. ECH can reduce the explicit site names visible at the VPN's exit and on the path beyond it. The destination sees the VPN's address rather than the airport's address. No party vanishes; the observation points change.

Tor takes a stronger approach for destination separation. The local network sees a connection into Tor, while the exit side sees the destination connection without the user's original address. ECH can still reduce explicit names beyond the exit when the site supports it, but Tor's route design does the heavier work of splitting who knows the user from who knows the destination. Customising the browser or mixing personal accounts back into the session can still join the pieces later.

This is the recurring privacy lesson. Encryption protects a field between particular endpoints. It does not dissolve trust. Ask which party could read the field before, which party can read it now, and which other fields still describe the same event. Those three questions cut through most claims about “private” networking.

## The address, timing, and shape still speak

After ECH succeeds, the local observer loses a clean domain label. It does not lose the connection. Packets still need routable source and destination addresses. Their lengths and timing remain visible. The service may respond in a pattern that distinguishes it from neighbours sharing the same front door.

An IP address can be broad or precise. A large content network may host thousands of domains behind one range, creating a useful crowd. A small service may use a dedicated address, making the hidden name easy to infer. Public routing data and active measurements can help an observer map addresses back to providers and services.

Traffic volume adds another clue. Loading a text login page creates a different pattern from streaming a film or downloading a large software image. Modern encrypted protocols can multiplex requests and change their shape, while caches and background traffic add noise. The observer may not recover a page with certainty, but correlation rarely demands certainty.

Timing can be sharper. Imagine a source sends a reporter a message at 14:03. At 14:04, the reporter's phone opens an encrypted connection to a niche document service. At 14:06, a newsroom system downloads a file of the same approximate size. ECH removes the service name from one handshake. It does not remove the clock.

The endpoint knows more. The destination has to see the requested account, page, or API call so it can respond. Login cookies, device fingerprints, push identifiers, payment records, and recovery addresses can connect the session to a person after transport privacy has done its job. A perfect network tunnel cannot protect an identity volunteered inside the tunnel.

Apps introduce another seam. A phone may contact analytics, crash-reporting, advertising, notification, and configuration services around the same time as its main destination. Those auxiliary domains can identify the app even if the primary domain sits behind a useful ECH crowd. A rare combination of background requests can work like a calling card.

Certificate behaviour can leak structure too. ECH encrypts sensitive client fields and TLS 1.3 protects the server certificate after the opening stage, but servers must present consistent external behaviour to share an anonymity set well. Different protocol versions, cipher choices, connection errors, or response timing can separate one backend from another. The RFC explicitly notes that even implementation details such as extension ordering and record boundaries can affect what remains distinguishable.

A capable observer can combine weak clues. Address says provider. Packet shape suggests service class. Timing lines up with an outside event. A background domain hints at the app. One clue may be common. Four together can make the crowd much smaller.

This does not make ECH pointless. Removing a direct, machine-readable destination name raises the cost of broad collection. A network operator can no longer build the same clean log by reading one field from every compatible handshake. It must rely on inference, maintain address maps, process traffic patterns, and accept more uncertainty. Privacy often improves by making surveillance expensive, brittle, and noisy.

The Anonymity Playbook uses that cost model throughout. You cannot demand that every observer forget you exist. You can deny them the cheap join key that turns separate observations into one tidy history. ECH removes one such key. Compartmentation, route separation, ordinary browser configurations, and disciplined accounts have to handle the rest.

## The rest of Android 17 shows the same boundary logic

Google announced ECH beside three other network changes. They address different observers and different openings: local-network scanning, fraudulent certificates, and forced 2G connections. Grouping them is useful only if we keep their boundaries separate.

Local Network Protection changes what an app can see inside the home or office network. Before this enforcement, an app could scan for televisions, cameras, game consoles, printers, and other nearby devices without a dedicated user permission. That inventory can describe a household and expose services that were never meant to face every app on the phone.

Starting in Android 17, Google says apps must ask before scanning or connecting to local devices. For casting, developers can use a system picker that lets the person choose a television without giving the app a map of everything else. The design grants the requested effect while withholding the surrounding inventory.

That is a stronger pattern than a broad permission followed by a promise of restraint. An app that needs to put a video on one screen receives a capability for one selected screen. It does not need a silent census of the router, camera, printer, and children's devices. The operating system enforces the smaller shape.

Certificate Transparency covers a different seam. A browser or app trusts certificate authorities to vouch for website identities. If an authority issues a fraudulent certificate, an attacker may be able to impersonate a service under the right network conditions. Public, append-only certificate logs make issuance visible to domain owners, monitors, and auditors.

Android 17 enables Certificate Transparency by default, according to Google's 27 August announcement. The log does not prevent every bad certificate from being issued. It makes concealed issuance harder to sustain and gives defenders evidence to detect and respond. Transparency turns a private mistake into an inspectable event.

The 2G change addresses radio downgrade attacks. A false base station can transmit a strong signal and push nearby phones away from newer cellular protocols toward older 2G behaviour. Google says portable “SMS blasters” use this route to bypass modern spam defences and inject phishing texts. Android 12 added a manual hardware-level 2G switch; Android 17 lets participating carriers turn 2G off by default for subscribers.

Carrier participation is the limit. A person on a participating network may gain protection without finding a buried setting. Another carrier may leave the old path open. Travel and roaming can change what is available. A default controlled outside the phone should be verified rather than assumed.

These four changes share one useful idea: give each party only the view or protocol it needs. The local app does not need the whole household map. The network path does not need the private destination name. Certificate issuers should not act without a public record. Modern phones do not need to accept an obsolete radio mode merely because a stronger signal asks them to.

They also show why “Android 17 is more private” is too vague to guide anyone. ECH protects one stage of internet setup. Local Network Protection constrains apps on nearby networks. Certificate Transparency improves auditability of server identity. The 2G default removes an old cellular route where carriers take part. Different mechanism, different observer, different failure.

## What to check on a real phone or app

Most people should not turn network privacy into a packet-analysis hobby. The platform, app, and service owners carry most of the deployment work. A few checks still separate a useful default from a comforting label.

1. **Install Android 17 updates and restart the phone.** The network stack can only protect connections when the running code contains the change. Check the Android security update date after the restart rather than assuming a downloaded package completed installation.

2. **Keep browsers and important apps current.** Google specifically tells developers to use OkHttp 5.5.0 and enable ECH. An app carrying an older network library may miss the platform's protected path even on a current phone. Updates are how those libraries reach you.

3. **Review Private DNS.** Android's Private DNS setting should normally remain on its automatic mode or point to a resolver you deliberately trust. A workplace, filtering service, or captive portal may need a different arrangement. Remember that the resolver receives the questions it answers, so its operator and policy matter.

4. **Treat ECH as opportunistic during rollout.** Some destinations will support it; others will not. Use a browser or controlled network test if a particular route matters to your work. A general OS version screen cannot prove protection for one specific service.

5. **Check local-network permissions.** When an app asks to find nearby devices, ask whether its job truly requires the household map. A casting app can use a system selector. A calculator has no credible reason to scan your cameras and printers. Deny first and grant later if a feature genuinely breaks.

6. **Disable 2G manually where the phone and carrier permit it.** Android 17 gives participating carriers a zero-click option, but participation may vary. If you face targeted phishing, travel through dense public spaces, or protect sensitive accounts, verify the mobile-network setting instead of relying on a carrier assumption.

7. **Keep connection metadata in the threat model.** A local observer can still see addresses, timing, and volume. Use a VPN for protection from the local network when that matches your risk. Use Tor or a carefully designed separation setup when the party who knows your access point should not know the destination.

8. **Separate sensitive activity from named activity.** ECH cannot help after you log into a personal account, pay with your usual card, or open a tracking link tied to your email. Use separate browser profiles or devices where two roles must not meet. Do not customise a high-risk browser until its fingerprint becomes unique.

9. **Test organisational services from both ends.** Teams that own Android apps or websites should capture a real handshake, inspect DNS delivery, confirm ECH acceptance, and test key rotation. They should also watch for a fallback path that restores plaintext SNI after a middlebox or library error.

10. **Write down the honest claim.** “Our current Android app supports ECH when the destination advertises it” is testable. “Your browsing is hidden” is not. Good privacy documentation names the observer, protected field, required conditions, and fallback behaviour.

For a household, steps one through five are enough. Someone protecting sources or organising under surveillance needs the later boundaries as well. The right amount of work depends on who may observe the route and what a mistaken link between activities would cost.

Developers have one additional responsibility: avoid quiet bypasses. A diagnostic SDK, ad library, or custom HTTP client can create connections outside the tested stack. Inventory every networking dependency and the domains it contacts. The app's privacy is set by its least private active path.

Network administrators should expect visibility tools to change. Products that classify traffic from plaintext SNI will lose a clean signal on successful ECH connections. Blocking ECH to restore that signal pushes users back toward exposure and can break modern services. Security controls should move closer to managed endpoints, authenticated service policy, and destination allowlists where the organisation has authority, rather than preserving passive inspection by degrading public privacy.

Website operators should publish ECH carefully and monitor it. Shared hosting can create a larger anonymity set, but only if front-facing behaviour remains consistent enough that one service does not stand out. Rotate keys, retain compatible configurations during propagation, and measure rejection. A feature that silently fails for half the clients supplies a privacy claim without dependable protection.

## A missing label is still worth removing

Android 17 removes an old absurdity from compatible connections. HTTPS could protect the page, password, message, and search while the opening handshake named the site in public. ECH seals that label and hands it to the service that can open it.

The improvement is substantial for broad, cheap observation. A hotel, employer, internet provider, or compromised router loses a direct list of domain names when encrypted DNS and ECH both work. An observer must fall back to addresses, timing, traffic shape, auxiliary services, or control of another point in the route. More work produces less certain answers.

The remaining clues matter most when the stakes are high. A dedicated address can identify a small service. A login can identify the person. A notification service can identify the app. Timing can connect a source event to a newsroom event. ECH protects the site name inside one handshake and leaves those other joins for other controls.

Use the change. Keep the phone and apps current. Keep Private DNS on a route you trust. Deny local-network access that an app cannot justify. Verify 2G settings when targeted text attacks belong in your threat model. For sensitive work, separate identities and routes instead of asking one encrypted field to carry the whole burden.

Privacy improves one cheap clue at a time. Android 17 takes a useful clue away from the network. The next job is to make sure the address, account, app, and clock do not simply put it back.

If you want calm, practical security and privacy analysis without a daily alarm bell, join the newsletter. It is one email per month.

## Sources

- [Google: 4 new ways Android is protecting your network connections](https://blog.google/security/new-android-network-security-protections/), accessed 2026-08-28
- [9to5Google: Android 17 boosts network security by hiding domain names, lets carriers disable 2G](https://9to5google.com/2026/08/27/android-17-network-security/), accessed 2026-08-28
- [IETF: RFC 9849, TLS Encrypted Client Hello](https://www.rfc-editor.org/rfc/rfc9849.html), accessed 2026-08-28
- [BleepingComputer: Android 17 adds ECH support to make web browsing harder to track](https://www.bleepingcomputer.com/news/security/android-17-adds-ech-support-to-make-web-browsing-harder-to-track/), accessed 2026-08-28

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._