Your internet service provider sits between your devices and everything else. Every connection you make passes through their infrastructure first. Understanding what that means in practice — what they observe, what HTTPS hides, and what survives encryption — is essential to reasoning honestly about network-level privacy.
Most privacy discussions focus on the applications and services you use. Far fewer focus on the infrastructure those applications run over. Your ISP is not incidental to the conversation — they are structurally positioned to observe more of your internet activity than almost any other single entity, including the websites you visit.
What ISPs Can Observe at the Network Level
At a minimum, your ISP can see the following for every connection you make:
- IP addresses — the destination IP of every connection your device initiates, and every source IP that initiates a connection to you
- Port numbers — which service protocol the connection is using (port 443 for HTTPS, port 993 for IMAP, etc.)
- Timing and volume — when you connect, for how long, and roughly how much data flows in each direction
- DNS queries — if you use your ISP’s default DNS resolver, every hostname you look up is visible to them in plaintext
- Unencrypted traffic — any HTTP (not HTTPS) connection is fully readable: URLs, page content, form data
The shift to HTTPS across most of the web in the 2010s substantially improved the picture. Your ISP can no longer read the content of your web traffic when you visit HTTPS sites. But HTTPS is not a complete solution to ISP-level surveillance, and understanding where it falls short matters.
What Survives HTTPS: The Metadata Layer
Even with HTTPS, significant information remains visible to your ISP:
The destination IP address is always visible. Knowing that you connected to Google’s IP ranges tells your ISP you are using Google services. Large services like Netflix, Cloudflare, and Amazon have distinctive IP ranges that are well-documented. Your ISP can make accurate inferences about your browsing habits from IP patterns alone, even without reading a byte of your traffic content.
Server Name Indication (SNI) historically revealed the hostname you were connecting to even inside a TLS connection, because the hostname is transmitted in the ClientHello message before the encrypted channel is established. For years, visiting private-forum.example.com over HTTPS would still tell a network observer exactly which site you were accessing.
Encrypted Client Hello (ECH), standardized as part of TLS 1.3 extensions, addresses this by encrypting the ClientHello using a public key published by the server in DNS. ECH is supported by major browsers and CDNs including Cloudflare, but adoption is incomplete. DNS-over-HTTPS or DNS-over-TLS is a prerequisite for ECH to close the observable hostname gap, since the DNS query that fetches the ECH key must also be hidden from the network observer.
The SNI gap: Until ECH is universally deployed, connecting to an HTTPS site reveals the domain name to your ISP even if the content is encrypted. DNS-over-HTTPS hides your lookup; ECH hides the SNI itself.
Traffic analysis and timing correlation is a more advanced technique but a real one. The size and timing of encrypted packets can reveal information about what you are doing — loading a specific page, making a specific API call, watching a video at a specific resolution. For targeted surveillance of known individuals, timing correlation is a documented technique.
DNS: The Cleartext Directory
Traditional DNS is unencrypted and unauthenticated. Every time your device looks up a hostname — to visit a website, to connect to a messaging server, to check for software updates — that query travels in plaintext to your configured DNS resolver. If your resolver is operated by your ISP (the default on most consumer connections), your ISP receives a log of every hostname you look up.
DNS queries happen before any HTTPS connection, which means the list of sites you visit is observable separately from the connection content. Even if you use a VPN for your web traffic, if your DNS queries leak outside the VPN tunnel, your ISP can see the domains you are resolving.
DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) both encrypt DNS queries, preventing your ISP from reading your lookups. They shift the DNS visibility to your chosen DoH/DoT provider instead. The short version: it helps against passive ISP surveillance but introduces a dependency on the DoH provider.
US Data Retention Law vs. the EU
The legal framework governing what ISPs must do with the data they collect differs substantially between jurisdictions.
| Region | Mandatory Retention | Legal Access Mechanism |
|---|---|---|
| United States | No general federal mandate for broadband ISPs | NSL (no judicial oversight), subpoena, court order; ECPA governs stored communications |
| European Union | Data Retention Directive struck down by CJEU (2014, 2016); member states vary | Varies by member state; GDPR requires data minimization |
| UK | Investigatory Powers Act 2016 requires 12-month retention of internet connection records | Police, intelligence agencies, many government bodies can access records |
| Canada | No federal mandatory retention law; PIPEDA governs commercial data handling | Court order, production order |
The practical implication in the US is that your ISP is not legally required to retain your browsing data — but they are also not prohibited from doing so. ISPs in the US have sold anonymized browsing data to third parties, and without a federal privacy law governing ISP data practices, the constraints are primarily contractual and reputational.
What Actually Helps — and What Doesn’t
DNS-over-HTTPS/TLS hides your DNS queries from your ISP. It does not hide destination IP addresses, traffic volume, or timing. Enable it in your browser settings or at the OS level. Firefox and Chrome both support it natively.
A commercial VPN shifts your traffic’s visibility from your ISP to your VPN provider. Your ISP now sees encrypted traffic to a VPN endpoint rather than your actual destinations. Your VPN provider can see everything your ISP previously could. This is useful if your ISP is a higher-risk party than your VPN provider — for example, on a corporate or hotel network. It does not provide anonymity; it provides a different trust relationship.
A VPN is not a privacy tool — it is a trust delegation tool. You are choosing to trust your VPN provider instead of your ISP. That choice is sometimes correct and sometimes makes things worse, depending on who your adversary is.
Tor provides stronger network-level anonymity by routing your traffic through multiple relays, each knowing only the previous and next hop. Your ISP can see that you are using Tor, but not what destinations you are reaching. Tor introduces significant latency and is not suitable for all use cases, but for users with strong network anonymity requirements, it is the more rigorous option.
Encrypted Client Hello, once universally deployed, will close the SNI observation gap for HTTPS traffic. Using a browser that supports ECH (Chrome, Firefox) and services that deploy it (Cloudflare-fronted sites, among others) gets you its protections when available.
The Part Nobody Talks About: Your Home Router
ISP-provided routers — the modem-router combos that most residential customers use — often run firmware the ISP can update remotely. In some cases, ISPs have used this access to enable diagnostic modes, collect telemetry, or implement DNS hijacking. Using your own router, rather than the ISP-provided equipment, removes this additional access layer and gives you direct control over DNS settings, firewall rules, and firmware update schedules.
The practical step: buy a router you control, configure DoH on it for your entire home network, and use it instead of the ISP’s equipment. This alone does not block ISP traffic analysis, but it closes several incidental data collection channels.
Originally published at havenmessenger.com
Top comments (0)