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
Yandex Details Alice Voice Assistant Audio Buffering and Data Handling in Android Apps
Yandex has issued a detailed technical response to an analysis of its Android applications that raised concerns over potential collection of audio, contacts, bank card data, and other sensitive information. The company acknowledged the existence of a cyclic audio buffer that retains approximately 1.5 seconds of sound before an activation phrase and 0.5 seconds after it, with some pre-command audio possibly transmitted to servers for speech recognition quality checks. Yandex clarified that the Alice assistant only listens locally for the wake word when the app is open and does not continuously record conversations. Access to contacts was explained as necessary for voice commands such as calling entries from the address book, with the full book sent on first sync and only changes thereafter, without hashing to support accurate speech processing. The firm rejected claims of reading messaging app conversations and stated that bank card details are routed directly to an isolated PCI DSS-compliant environment rather than standard application servers.
Windscribe Releases Open-Source PowerShell Script to Remove Microsoft's Persistent Global Device Identifier from Windows
Windscribe has published an open-source PowerShell script called deGDID that removes Microsoft's Global Device Identifier (GDID) from Windows systems and prevents the creation of new identifiers. The persistent tracker survives IP address changes and operates below the VPN layer, allowing Microsoft to maintain device tracking even when users employ privacy tools. The script was developed after the FBI used GDID to identify a suspected hacker, raising concerns about undisclosed device fingerprinting. deGDID modifies registry access control lists and blocks the DeviceAdd interface to stop Windows from regenerating the identifiers after reboots or server contacts. While effective at disabling the tracking mechanism, the tool can break authentication to login.live.com and disrupt certain Microsoft cloud services. It is intended only for unmanaged consumer devices and will not run on domain-joined or corporate-managed systems. The project is described as experimental and cannot delete identifiers already transmitted to Microsoft servers.
Yandex Apps Leak Pre-Trigger Audio Buffers, Payment Data, and Contacts via Reverse Engineering
Reverse engineering of Yandex Search and Yandex Browser APKs reveals extensive data collection practices on Android devices. The apps maintain a server-controlled pre-trigger audio buffer that captures up to three seconds or more of microphone input before the wake word Alice is detected. WiFi fingerprinting, full contact book synchronization via ContentObserver, and transmission of PAN and CVV details to mobpayment.yandex.net occur before tokenization. Additional findings include 94 JavaScript Bridge methods, logcat exfiltration with AES encryption, hardcoded Yandex DNS servers, and a native surveillance library named libquarkenstein_daemons.so. The analysis also covers passive geolocation, cell tower data collection, and inventory of installed applications including competitors such as Chrome, Firefox, WhatsApp, and Telegram. These mechanisms operate under remote configuration flags and bypass several Android privacy restrictions through manifest queries.
TSPU Filtering Disrupts Timeweb Cloud Servers: Diagnosis, CDN Failures, and Reverse Proxy Bypass
Russian hosting provider Timeweb Cloud experienced widespread TSPU-based DPI filtering starting in early June that selectively blocked TLS handshakes on port 443 while leaving SSH, ICMP, and TCP connectivity intact. The issue affected multiple providers including Beget and Selectel, was publicly acknowledged by Timeweb on June 5, and proved highly variable by region, operator, and time of day. Attempts to mitigate via new IP addresses or Timeweb's own CDN failed due to poisoned caches and platform outages, while Yandex Cloud CDN blocked all POST requests required for WordPress functionality. A working solution involved deploying a minimal nginx reverse proxy on another Russian cloud VPS that preserves full HTTP methods, handles certificate synchronization, and routes ACME challenges correctly. Timeweb support later closed tickets without resolution after requesting ineffective mtr traces that cannot detect DPI behavior. The case highlights systemic challenges in diagnosing state-mandated filtering and the limitations of standard network diagnostics against selective TLS interference.