こんにちは 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.