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
Why Replace Proprietary BIOS and UEFI with the Fully Free GNU Boot Firmware
The Free Software Foundation announced in September 2026 that it is providing financial and legal support to the GNU Boot project, which aims to deliver a completely open-source replacement for traditional BIOS and UEFI firmware. GNU Boot builds on coreboot to initialize hardware at boot time and layers a free bootloader such as GRUB or SeaBIOS on top, ensuring no proprietary binary blobs are required. The initiative emerged after a 2022 split from Libreboot, which began accepting closed-source components to broaden hardware support, while GNU Boot strictly adheres to GNU licensing criteria that prohibit any non-free code. Supported platforms remain limited to older systems from roughly 2008–2012, including specific ThinkPad models, certain early Apple MacBooks, and a handful of AMD and Intel desktop boards, because newer Intel Boot Guard and AMD equivalent mechanisms enforce signed firmware that prevents unsigned replacements. Closed firmware from Intel Management Engine and AMD Platform Security Processor runs before the main operating system, possesses unrestricted memory access, and cannot be audited or disabled on most modern hardware. By offering reproducible builds and clearer installation instructions, GNU Boot seeks to lower the barrier for users who want to eliminate potential backdoors, Wi-Fi whitelist restrictions, and forced updates found in vendor firmware.
WhatsApp Help Pages Hid Secret Instructions Directing AI Bot to Avoid GDPR References
Researchers at Redact discovered hidden instructions embedded in WhatsApp's public help documentation that instructed the company's AI support chatbot to avoid recommending users contact data protection regulators. The instructions also prohibited the bot from referencing GDPR, LGPD, or CCPA when users mentioned legal proceedings or lawyers. The findings emerged after Redact analyzed 545 help pages and identified 102 concealed blocks across 80 of them. One directive explicitly told the bot not to suggest contacting supervisory authorities even when users had lost access to their phone number and could not delete their account, despite WhatsApp's own European privacy policy stating that such complaints are permitted. WhatsApp confirmed to WIRED that the blocks were intended solely for its internal chatbot and attributed their public exposure to an error. The company stated the restrictions aimed to prevent the bot from offering legal advice. All hidden blocks were removed by October 18.
WhatsApp Secretly Instructed AI Support Bot to Suppress References to Data Regulators and Privacy Laws
Investigators discovered hidden instructions embedded in WhatsApp's public help pages that directed the company's AI chatbot to avoid recommending users contact data protection authorities. The instructions also prohibited the AI from citing privacy regulations such as GDPR, LGPD, or CCPA, even when users raised these topics themselves. The directives appeared on pages about account deletion and complaints, remaining invisible to human visitors but delivered to crawlers and the AI model. WhatsApp later confirmed the text was intended for its internal support chatbot and attributed the exposure to an error that has since been corrected. The findings highlight a gap between the company's publicly stated privacy policy and the operational guidance given to its AI systems.
Developer Builds Password Manager with Plausible Deniability Using Argon2id and XChaCha20-Poly1305
A Java backend developer rewrote a personal password manager originally built with Electron and React, migrating it to Tauri and Rust while redesigning its storage to support plausible deniability. The new implementation derives keys with Argon2id using a single per-install salt and encrypts files with XChaCha20-Poly1305, storing only random 32-character hex filenames without any headers or magic bytes. Multiple decoy vaults of identical size are created automatically for every user, and all files in the folder receive synchronized timestamps to eliminate metadata-based identification of the active vault. History and sync data are stored as additional encrypted files of the same format, making it impossible to distinguish real from decoy vaults from the filesystem alone. The approach mirrors VeraCrypt hidden volumes but operates on ordinary files and folders, with the explicit goal of providing deniability when a user is compelled to reveal a password.