Intent to Experiment: Partitioning :visited links history Phase 2

38 views

Skip to first unread message

Kyra Seevers

unread,

4:43 PM (3 hours ago) 4:43 PM

to blink-dev

Intent to Experiment: Partitioning :visited links history Phase 2 (User-facing partitioning for :visited links)

Contact emails

kyras...@chromium.org

Explainer

https://github.com/kyraseevers/Partitioning-visited-links-history

Specification

We plan to specify our solution before shipping. This work currently falls under the wording in CSS Selectors Level 4: “UAs may treat all links as unvisited links or implement other measures to preserve the user’s privacy while rendering visited and unvisited links differently.”

Summary

To eliminate user browsing history leaks, anchor elements will be styled 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 VisitedLinks hashtable will now 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 are now obsolete, as they no longer provide sites with new information about users.

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/1040)

WebKit: Under Review (https://github.com/WebKit/standards-positions/issues/363)

Web developers: No signals

Other signals:

Positive initial signals from presentation at WebAppSec from both Apple and Firefox
At the XS Leaks Summit, Firefox stated exploration of :visited links partitioning in their privacy goals for the upcoming year at the XS-Leaks Summit

Positive or neutral initial signals from security and privacy researchers at the XS-Leaks summit. No security concerns about this design. Interest in understanding user behavior around this new model of what constitutes a :visited link.
Feedback from UX that CSS extensibility is in-demand from developers right now, and this work would pave the way for less restricted CSS on anchor elements. In addition, support from various developers who believe that taking care of this long-standing privacy leak will allow their own security and privacy solutions to advance once history sniffing is no longer an issue.

Ergonomics

This design is asynchronous and not used in tandem with other APIs.

Activation

Since this is a Finch roll-out, there are no additional activation risks.

Security

For this design we worked with the Chrome Security Architecture team to ensure reasonable precautions were taken against leaks of the :visited links hashtable via renderer compromise.

WebView application risks

This experiment will not run on WebView. This feature deals with platform-specific code and the WebView implementation of :visited links does not integrate with the History Database.

Goals for experimentation

Our intent is to run a Finch experiment. This user-facing experiment will use the traditional Finch roll-out schedule. We will utilize newly added UMA to determine the percentage of links styled as :visited under partitioning, as well as observe the size, efficiency, and impact of the newly partitioned infrastructure in comparison to the unpartitioned (original) codepaths.

Experiment Risks

As this is a Finch experiment, it is per-client rather than per-site. The biggest potential risk to clients is a visible change to which links are styled as :visited once they enter the experiment. However, based on pre-experimental metrics analysis, we believe that most links the user sees will remain unchanged. In the event of an issue during the experiment, we will flip our kill switch via Finch.

Ongoing technical constraints

None

Debuggability

No DevTools support is required.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

This feature is not currently supported on iOS or Android Webview. For iOS, this feature requires WebKit to alter its CSS parsing to support triple-key partitioning. Android Webview relies on an entirely different system to populate history, so it will require a separate design.

Is this feature fully tested by web-platform-tests?

This feature is not tested by Web Platform Tests because the :visited selector cannot be queried via JavaScript (https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector). As a result, we can only test :visited-ness via manual tests which rely on users visually confirming the correct links are :visited, or unit and integration tests internal to Chrome.

Flag name on chrome://flags

N/a

Finch feature name

PartitionVisitedLinkDatabase

Requires code in //chrome?

True

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1448609

Launch bug

https://launch.corp.google.com/launch/4330864

Estimated milestones

Shipping on desktop

128

Shipping on Android

128

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5101991698628608?gate=4821248529137664

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXbbLWwmRYH5SWx0%2BMWkfB2UY2miOAq4r0MZc34i_sWqBw%40mail.gmail.com

Intent to Experiment (Phase 1): https://groups.google.com/a/chromium.org/g/blink-dev/c/U5AX0OXaxM8/m/tIGr4bJJBgAJ?utm_medium=email&utm_source=footer