HabrAugust 7, 2026🇷🇺Translated from Russian

One Request, Five Observers: What Websites, Providers, DNS and VPNs Learn When Loading a Page

The phrase “I have HTTPS, so my provider sees nothing” sounds convincing until one asks what exactly counts as “nothing.” Site name, specific article, message text, external IP, account, browser language and connection time are different data points that appear at different points along the route and reach different parties. This turns most privacy debates into exchanges of half-truths.

Consider an ordinary request to https://news.example/articles/privacy?from=mail from a home connection, standard browser and correctly configured HTTPS site. Corporate networks, antivirus products that replace certificates and decrypting proxies are separate cases where the network administrator can see more.

Browser knows the full address before any packet is sent

Before the first network packet leaves, the browser already possesses the complete URL, including path and query parameters, plus any stored state such as cookies, site data and login tokens. It applies strict rules when deciding what to send to each origin. Scripts on the page can read language, timezone, screen size and graphics API results, yet localStorage remains isolated by origin, HttpOnly cookies stay invisible to JavaScript, and the site cannot enumerate all open tabs or full history.

DNS resolver learns only the domain name

To reach the server the browser must resolve the domain. An unencrypted DNS query can be observed by the local network and ISP. The resolver itself sees the domain and client IP but never the URL path or credentials. DNS over HTTPS and DNS over TLS encrypt the query between device and chosen resolver, shifting trust to that resolver while the ISP sees only the connection to the resolver service.

ISP observes metadata but not HTTPS content

Once the IP address is known, the browser performs a TLS handshake followed by the encrypted HTTP request. The provider normally sees client and destination IPs, port 443, traffic volume, duration, unencrypted DNS queries and the Server Name Indication (SNI) unless Encrypted Client Hello (ECH) is used. Even with ECH the destination IP, volume and timing remain visible. One IP address frequently hosts many domains behind a CDN, so IP alone does not reliably identify the site.

Destination site receives the richest set of signals

The site (or its CDN) decrypts the traffic and obtains the client IP, full URL path and parameters, HTTP headers including Referer (subject to Referrer-Policy), cookies, authorization data, User-Agent information and any values collected by page scripts. Account login creates a stable identifier that survives IP changes. Browser fingerprinting combines language, timezone, screen dimensions and rendering behaviour to probabilistically link visits.

Third-party resources introduce additional observers

A single page often loads images, fonts, analytics scripts and widgets from multiple domains. Each third party receives its own request headers, cookies and identifiers. Removing cookies for one site therefore does not eliminate tracking performed by other origins.

VPN changes the route but adds a new observer

With a full-tunnel VPN the home ISP sees only the encrypted connection to the VPN server. The destination site sees the VPN exit IP. The VPN provider itself becomes the new observer that knows the user’s real IP and all destination addresses. HTTPS still protects content from the VPN, provided the user has not installed a trusted interception certificate.

A comparison of visibility with and without VPN:

  • Site: home or mobile IP → VPN exit IP
  • ISP: direct connections and sometimes DNS/SNI → connection to VPN and tunnel metadata
  • VPN service: not involved → user IP, final destinations and DNS depending on configuration
  • DNS resolver: domain and client IP → domain and VPN exit IP if DNS travels inside the tunnel
  • Cookies and account: remain in the browser in both cases
  • Browser fingerprint: largely preserved in both cases

Incognito mode clears local state, not network visibility

Incognito opens a temporary session whose cookies and storage are discarded when the window closes. Network observers, the destination site and any active VPN still see the same traffic metadata. Chrome documentation explicitly states that sites, the ISP and network administrators may continue to observe activity.

Effective privacy therefore requires first defining the precise information one wishes to hide and from whom, then selecting the appropriate combination of HTTPS, secure DNS, VPN routing, separate browser profiles and reduced third-party scripts.

Related articles

HabrPrivacy & Surveillance

pg_anon Open-Source Tool Receives Major Updates for PostgreSQL Data Masking and Partial Database Operations

Tantor Labs has released version 1.11.0 of pg_anon, an open-source utility designed to mask personal data in PostgreSQL databases while preserving structure and relationships. The update introduces packaging as a standard Python package, support for partial dumps and restores using whitelist and blacklist dictionaries, and improved handling of complex schema elements such as partitioned tables, generated columns, and custom types. Performance improvements include switching the dump engine to asyncio, single-query metadata collection, and on-the-fly gzip compression to reduce memory usage on large databases. New CLI options allow clean or drop operations on target databases, privilege ignoring, and passthrough of pg_dump and pg_restore flags. A REST API was added to enable integration into CI/CD pipelines and automated self-service systems for nightly masked database refreshes. The tool helps organizations comply with data protection requirements by creating pseudonymized copies suitable for development, testing, and contractor environments.

BoletimSecPrivacy & Surveillance

Pegasus Spyware Returns in Serbian Surveillance Campaign via Zero-Click iMessage Exploit

A Serbian student activist's iPhone was infected with the Pegasus spyware through a zero-click exploit in iMessage, allowing silent installation without any user interaction. The infection, confirmed by Citizen Lab in collaboration with the SHARE Foundation, showed indicators of compromise between December 2025 and January 2026. Apple later sent the target a notification warning of a mercenary spyware attack attempt. The exploit granted full access to photos, messages, files, and enabled covert microphone and camera activation. The vulnerability was addressed in the iOS 18.4.1 update released on April 16, 2025. The incident forms part of a wider surveillance wave in Serbia, with at least 14 individuals including students, activists, a parliament member, and a local political representative receiving similar Apple alerts. Additional targets were hit with Android spyware variants linked to NoviSpy.

AntiMalwarePrivacy & Surveillance

Mozilla Adds Built-in Ad Blocker to Firefox for iOS Devices

Mozilla has integrated a native ad-blocking feature directly into its Firefox browser for iOS. The update allows iPhone and iPad users to block third-party advertisements and associated trackers before web pages load, eliminating the need for separate extensions. Apple’s App Store policies have long restricted the use of third-party content blockers on iOS compared to desktop and Android platforms. The new functionality targets intrusive elements such as pop-up windows, content-overlapping banners, and other advertising formats. By handling blocking at the browser level, Firefox for iOS improves user privacy and reduces exposure to tracking mechanisms without requiring additional software installation.

HabrPrivacy & Surveillance

De-Clouding IoT Devices: Local Control for Midea Air Conditioners and Tuya-Based Cat Feeders

A security researcher detailed a methodical approach to eliminating vendor cloud dependency for Wi-Fi IoT devices in a smart home setup. After acquiring a cat, the author was forced to integrate several Tuya-based appliances that only worked through proprietary cloud apps. Using hardware analysis tools including UART adapters, multimeters, and soldering equipment, the devices were disassembled and their controllers identified. The Midea air conditioner controller based on TYWE3S ESP8266 was reflashed with ESPHome to enable direct Home Assistant integration. For the Tuya WBR3-powered cat feeder running on an RTL8720CF chip, OpenBeken firmware was installed after extracting the original firmware with ltchiptool. Detailed UART communication analysis between the Wi-Fi module and MCU allowed full recreation of scheduling and control functions locally via MQTT.