Partitioning :visited links history

[kyraseevers]

こんにちは TAG-さん!

I'm requesting a TAG review of “Partitioning :visited links history.”

The goal of this feature is to eliminate user browsing history leaks by styling anchor elements as :visited if and only if they have been clicked from this top-level site and frame origin before. On the browser-side, this means that the data structure storing the :visited links would be partitioned via "triple-keying", or by storing the following for each visited link: <link URL, top-level site, frame origin>. By only styling links that have been clicked on this site and frame before, the many side-channel attacks that have been developed to obtain :visited links styling information would become obsolete, as they would no longer provide sites with new information about users.

• Explainer: https://github.com/kyraseevers/Partitioning-visited-links-history
• User research: N/a
• Security and Privacy self-review: See below
• GitHub repo (if you prefer feedback filed there):
  https://github.com/kyraseevers/Partitioning-visited-links-history/issues
• Primary contacts (and their relationship to the specification):
  • Kyra Seevers (@kyraseevers), Google, contributor
  • Artur Janc (@arturjanc), Google, contributor
  • Mike Taylor (@miketaylr), Google, contributor
  • Tab Atkins-Bittner (@tabatkins), Google, Selectors Level 4 editor
• Organization/project driving the design: Google
• External status/issue trackers for this feature:
  • https://chromestatus.com/feature/5101991698628608
  • https://bugs.chromium.org/p/chromium/issues/detail?id=1448609

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WebAppSec WG
• The group where standardization of this work is intended to be done: most likely either WebAppSec or CSSWG
• Existing major pieces of multi-stakeholder review or discussion of this design: N/A
• Major unresolved issues with or opposition to this design: N/A
• This work is being funded by: Google

We'd prefer the TAG provide feedback as:
💬 leave review feedback as a comment in this issue and @-notify:
kyraseevers, arturjanc, miketaylr

---

Security and Privacy self-review

(1) What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

This feature does not expose new information to websites or other parties. It aims to restrict the information exposed by :visited links. The difference between unpartitioned and partitioned :visited links, is that unpartitioned :visited links exposes global user-browsing history state, whereas, partitioned :visited links only exposes what links have been visited from this site before (information that is already known to sites via other methods).

(2) Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes, no new information is exposed.

(3) How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

This feature does not deal with personal information, PII, or any information derived from them.

(4) How do the features in your specification deal with sensitive information?

It does not handle sensitive information.

(5) Do the features in your specification introduce new state for an origin that persists across browsing sessions?

No, there isn’t any new state introduced.

(6) Do the features in your specification expose information about the underlying platform to origins?

No, this feature does not expose information about the underlying platform.

(7) Does this specification allow an origin to send data to the underlying platform?

Yes - the link URLs are passed to the platform, however, this is already done by the current :visited links implementation.

(8) Do features in this specification enable access to device sensors?

No, there is no access to device sensors.

(9) Do features in this specification enable new script execution/loading mechanisms?

No, there aren’t any new script execution/loading mechanisms.

(10) Do features in this specification allow an origin to access other devices?

No, this feature does not allow an origin access to other devices.

(11) Do features in this specification allow an origin some measure of control over a user agent’s native UI?

Yes, but no more than the existing :visited link styling capabilities.

(12) What temporary identifiers do the features in this specification create or expose to the web?

None - no new identifiers are created or exposed.

(13) How does this specification distinguish between behavior in first-party and third-party contexts?

First and third parties BOTH must abide by triple-key partitioning. However, there are some edge cases where a first-party embed may display a site not previously visited in that frame (i.e. when a site embeds a iframe containing itself and the user has clicked on a link on this site in a previous visit, the link in both the top-level frame AND the iframe will be styled as visited.)

(14) How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

In private browsing/incognito mode, :visited links are not styled at all.

(15) Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

Selectors 4 has some existing language for both privacy and security considerations - https://www.w3.org/TR/selectors-4/#priv-sec

(16) Do features in your specification enable origins to downgrade default security protections?

No, all origins are partitioned equally.

(17) How does your feature handle non-"fully active" documents?

History is only written to the :visited links database and hashtable once navigation is complete. We are not making any alterations to the timing of when the renderer requests the :visited status of a given link during CSS parsing.

(18) What should this questionnaire have asked?
Nothing to add.

[plinss]

Taking a look at this we have some concerns about user experience and expectations, specifically when users will be seeing visited links appearing as unvisited. We understand this may not be on the majority of use cases, but wonder if any research has been done about the scope of the impact and user reactions.

Also, is there any feedback from other engine implementers?

[kyraseevers]

Thanks for the question! In an upcoming implementation phase, we will write a "signal loss" metric. This metric will allow us to understand what percentage of links that were styled as :visited in the current model would no longer be styled as :visited in the partitioned model. We'll keep you updated with those results.

We haven't solicited official positions from other browsers yet, but we have had positive feedback and interest from other browsers at TPAC and WebAppSec WG meetings.

Thanks!

[plinss]

We appreciate the problem you're trying to solve and agree that this is a really important privacy issue. Architecturally, this isn't a huge issue. We want to make sure this is good for users. We think this is fine for experimentation but we would like to see some results of that experiment regarding the impact on users.

We'd also like there to be multi-stakeholder consensus on this to avoid user confusion.

We're going to close this for now. When you have more info to share, can you please re-open this or open a new issue?

[kyraseevers]

Hi TAG!

I’m re-opening this issue, as you requested, to give an update regarding our implementation and experimentation for partitioned :visited links.

First, we have heard positive signals from Firefox and Safari regarding partitioning. Based on this and other feedback from TPAC, we believe that there is multi-stakeholder interest in the feature and plausible consensus on the approach.

Second, we have had positive results from our experiments as well. We’ve run multiple experiments on a percentage of both pre-release and stable traffic since July 11th, 2024 (Chrome Version 128). In addition to nearly 6 months of experiment data, we also began a Developer Trial and added the corresponding self-links flag to ExperimentalWebPlatformFeatures in Chrome Version 133.

During this time, our only bug report was regarding support for context clicks (i.e. right clicking on a link and making it turn purple in a partitioned environment). This functionality was added in Chrome Version 133 and will be part of the model we ship. During these six months of experiments, there have been no changes to Chrome vital metrics including memory footprint, rendering speed, or loading performance.

Finally, we have found that this partitioning model still captures a good chunk of visited links, within an acceptable threshold. Considering that the goal of this feature is to get rid of any “global” :visited state available to bad actors, we expected a portion of visited links to no longer be shown as :visited under the new partitioning model. We do not believe that user experience is compromised by this reduction, because the core behavior associated with :visited links still remains - “when I click on a link, it turns purple.” What has gone away, in the partitioned model, are all the other times a link turned purple, on sites that a user had never visited before - which was behavior that users may have even found surprising or confusing. Ultimately, we feel this is an acceptable change in user experience to improve user privacy and security.

Thanks! (Also @plinss or @rhiaro the UI says I don't have permission to reopen the issue, so would you be able to do that for me? - thanks so much)