Chrome to Fix Decades-Old Browsing History Privacy Leak Problem

Web browsers have long exposed users to a subtle but powerful privacy risk: the ability for malicious sites to detect which links a user has previously visited.

In 2025, that issue may finally be resolved. A new proposal — now implemented in experimental builds of Chrome — introduces partitioned visited link history, a significant change in how browsers record and expose link visit data.

The issue stems from the CSS ‘:visited' pseudo-class, a design feature that allows browsers to visually differentiate between visited and unvisited hyperlinks. This seemingly benign function has enabled side-channel attacks for over a decade. First disclosed widely in the early 2000s and mitigated in 2010 with limitations on CSS styles and computed properties, the flaw has nevertheless persisted through increasingly sophisticated exploits — including DOM inspection, timing analysis, pixel-level color detection, and even processor-level attacks like SpectreJS.

The concern is far from academic. Browsing history can expose intimate details about users, such as health-related searches, financial activity, or political preferences. Studies — including one by privacy researcher Łukasz Olejnik — have demonstrated that browsing histories are highly unique and stable, effectively acting as biometric identifiers. Browser telemetry from large-scale studies has confirmed that 99% of users have distinct patterns in their browsing data, making deanonymization trivial.

Chrome's proposed solution, developed by the Chrome Platform Hardening Team and spearheaded by engineer Kyra Seevers, replaces the global visited links database with a triple-keyed partitioned model. This system stores visited link states based on:

Link URL – the destination of the hyperlink
Top-Level Site – the main domain the user is visiting
Frame Origin – the origin of the frame where the link appears

A link is now only rendered as :visited if all three conditions match a previous navigation initiated from that same context. For example, if a user clicks a link to https://private.com from https://search.com, that visited status will not carry over to a page on https://attacker.com that also includes a link to https://private.com. This isolates browsing data contextually and prevents cross-site history leakage.

The change significantly strengthens privacy protections without removing useful visual cues users rely on when navigating the web. Importantly, the design maintains usability for intra-site navigation, with a “self-links” exception that allows a site to style links to its own pages if those pages have been visited previously from any context — provided the rendering context is not cross-origin.

How to enable on Chrome now

Chrome version 132 introduced this feature behind a flag for testing purposes, with broader deployment expected once feedback and stability testing conclude. Google continued refining the implementation in Chrome 133 and 134, but as of writing, it remains behind a flag on the latest stable release, meaning it's off by default. However, users can enable it manually by entering chrome://flags/#partition-visited-link-database-with-self-links on the URL bar and switching the option to ‘Enabled.'

Mozilla and Apple have not yet publicly committed to similar changes in Firefox or Safari, but given the scale of the privacy improvement, cross-browser standardization may follow.

This architectural change brings an end to a cat-and-mouse game between attackers and browser vendors that has lasted over a decade. It renders most historical side-channel attacks on link visitation useless by ensuring that styling data cannot be leveraged outside of the frame and domain context in which the visit occurred.