Intent to Experiment: Partitioning :visited links history Phase 2

[Kyra Seevers]

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.

Blink component

Blink>History>VisitedLinks

Search tags

visited links, :visited selector, partitioning history

TAG review

https://github.com/w3ctag/design-reviews/issues/896

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)?

No

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?

No

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

This intent message was generated by Chrome Platform Status.

[Daniel Bratell]

What milestones do you plan to run the experiment in?

(Also, why isn't it enough to key on frame origin? I'm sure there is a good reason but it's not obvious.)

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXYy4CSMuPLY0HJuTbZt0qPz5ZUsGUToFJuCE%2BTfC86umA%40mail.gmail.com.

[Kyra Seevers]

Update: I wanted to update the thread that WebKit left positive indications of support for this proposal in the request for position recently: https://github.com/WebKit/standards-positions/issues/363.

Daniel: Thanks for the question! We will be using a traditional Finch experiment rollout starting with Canary/Dev in M128. I will update this thread with any changes to the experiment that occur.

As for why we chose our keying structure: top-level site allows us to prevent cross-site leaks and frame origin allows us to adhere to the same-origin policy and avoid cross-frame leaks. For example, if I have an iframe c.com embedded in both a.com and b.com, keying by top-level site removes the opportunity for cross-site tracking to occur between these two iframes. For a visual example of this, please see the explainer (especially Key Scenarios #2 and #3): https://github.com/kyraseevers/Partitioning-visited-links-history?tab=readme-ov-file#key-scenarios.

Thanks all,

Kyra

[Kyra Seevers]

One point of clarification: we are intending to experiment for one milestone (M128), but would like to request 3 milestones (M128 - M130) in case of any delays.

Thanks so much!

[Chris Harrelson]

LGTM1

(probably 3 needed because this is a non-standard experiment)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXbJX%2BW5m9351o8qZV56SAnsmEfDbSwTr6YHPrpQUx%3DG2Q%40mail.gmail.com.

[Daniel Bratell]

LGTM2 for a low percentage finch experiment in M128-M130 (inclusive)

/Daniel

[Yoav Weiss (@Shopify)]

LGTM3

One question raised elsewhere was around same-origin links, where links to origin B visited from origin A should be then marked as visited when linked directly from B.

I see there's an open issue on this. It'd be good if one of the experiment's goals would be to determine if this is a blocker or not for initial shipping.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c88842b3-894d-49c6-be1a-d83f7fdae7ea%40gmail.com.

[Kyra Seevers]

Hi all,

FYI: we have had some delays in the experimental rollout and will be continuing with low-level (Stable 1% or lower) Finch experiments in M131 (and probably in M132 as well). 

Feel free to respond with any questions or concerns - thanks so much!

@Yoav Weiss due to the extra development time we were able to include this concept (what we're calling self-links) in our multi-armed experiment to determine if it is feasible!

Thanks,

Kyra

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLzt-06_bsRvJzNm%2BDgkGaV15bE3QiY%3DaoN-krLY8NSOQ%40mail.gmail.com.

--

Kyra Seevers (she/her) |

Software Engineer |

kyras...@google.com |

kyras...@chromium.org

[Yoav Weiss (@Shopify)]

On Tue, Oct 15, 2024 at 10:47 PM Kyra Seevers <kyras...@google.com> wrote:

Hi all,

FYI: we have had some delays in the experimental rollout and will be continuing with low-level (Stable 1% or lower) Finch experiments in M131 (and probably in M132 as well). 

Feel free to respond with any questions or concerns - thanks so much!

@Yoav Weiss due to the extra development time we were able to include this concept (what we're calling self-links) in our multi-armed experiment to determine if it is feasible!

Awesome!!