Intent to Experiment: Partitioning :visited links history Phase 1
Kyra Seevers
Intent to Experiment: Partitioning :visited links history Phase 1 (Begin storing triple partition keys for :visited links)
Contact emails
Explainer
https://github.com/kyraseevers/Partitioning-visited-links-history
Specification
None yet - currently getting feedback from the Web Platform community on where (if anywhere) this should be spec’d
Summary
The goal of this Finch experiment is to slowly roll-out the new VisitedLinkDatabase to users. This database is Phase 1 of the “Partitioning :visited link history” project. The purpose of the VisitedLinkDatabase is to store navigations being added to the HistoryDatabase as triple-keys (i.e. with the information needed to construct the triple-key partitioned :visited link hashtable from disk). Once the feature is rolled-out to users, we will let this database accumulate triple-keys for at least 90 days, so that when we run the Phase 2 experiment (only rendering triple-key partitioned :visited links), we have an initial database to load into memory and users will not begin with a blank slate (and have appropriate recovery data in the event of corruption).
The goal of the entire “Partitioning :visited link history” project (broader than the scope of just Phase 1 experiments) is to eliminate user browsing history leaks. In the proposed model, anchor elements are 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 is now 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. No code affecting the VisitedLinks hashtable or renderer is included in this first experiment.
Blink component
Search tags
visited links, :visited selector, partitioning history
TAG review
https://github.com/w3ctag/design-reviews/issues/896
TAG review status
Pending - Untriaged
Chromium Trial Name
N/a
WebFeature UseCounter name
N/a
Risks
Interoperability and Compatibility
Gecko: No official signals yet
WebKit: No official signals yet
Web developers: 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.
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.
WebView application risks
No - 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. We will need to complete a separate design for WebView :visited links in the future.
Goals for experimentation
Our intent is to run a Finch experiment (not a trial based on opt-in at this time). The goal is threefold: (1) observe the deployment of the new VisitedLinkDatabase, (2) ensure that triple-keying does not cause undue disk burden or key explosion, and (3) eventually roll-out the feature to all users for at least 90 days to collect a sufficient amount of triple-keys so that the second phase of the "partitioning :visited links history" experiment does not start with a completely empty hashtable.
We will observe History.VisitedLinkTableCount closely, as well as other related History metrics like History.DatabaseFileMB, Profile.HistorySize, and other History UMA to fulfill goal #2.
Risks of experimentation
As this is a Finch experiment, it is per-client rather than per-site. The biggest potential risk to clients is an increase in the history file size stored within a user's profile. However, based on pre-experimental metrics analysis, we believe that there is a low probability of key explosion. In the event that this occurs, we will flip our kill switch via Finch.
Ongoing technical constraints
None
Debuggability
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, 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 - there is no public facing endpoint or API that can be tested for this experiment phase.
Flag name on chrome://flags
N/a
Finch feature name
PopulateVisitedLinkDatabase
Requires code in //chrome?
Yes
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1448609
Launch bug
https://launch.corp.google.com/launch/4259382
Estimated milestones
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5101991698628608
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
This intent message was generated by Chrome Platform Status.
Yoav Weiss
Intent to Experiment: Partitioning :visited links history Phase 1 (Begin storing triple partition keys for :visited links)
Contact emails
Explainer
https://github.com/kyraseevers/Partitioning-visited-links-history
Specification
None yet - currently getting feedback from the Web Platform community on where (if anywhere) this should be spec’d
Summary
The goal of this Finch experiment is to slowly roll-out the new VisitedLinkDatabase to users. This database is Phase 1 of the “Partitioning :visited link history” project. The purpose of the VisitedLinkDatabase is to store navigations being added to the HistoryDatabase as triple-keys (i.e. with the information needed to construct the triple-key partitioned :visited link hashtable from disk). Once the feature is rolled-out to users, we will let this database accumulate triple-keys for at least 90 days, so that when we run the Phase 2 experiment (only rendering triple-key partitioned :visited links), we have an initial database to load into memory and users will not begin with a blank slate (and have appropriate recovery data in the event of corruption).
The goal of the entire “Partitioning :visited link history” project (broader than the scope of just Phase 1 experiments) is to eliminate user browsing history leaks. In the proposed model, anchor elements are 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 is now 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. No code affecting the VisitedLinks hashtable or renderer is included in this first experiment.
Blink component
Search tags
visited links, :visited selector, partitioning history
TAG review
https://github.com/w3ctag/design-reviews/issues/896
TAG review status
Pending - Untriaged
Chromium Trial Name
N/a
WebFeature UseCounter name
N/a
Risks
Interoperability and Compatibility
Gecko: No official signals yet
WebKit: No official signals yet
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5101991698628608
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
This intent message was generated by Chrome Platform Status.
--
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%2BmmbXb8DvTh7T6OzRFeiTAOnukLY6R1fJ9%2BfErdeBeBOX2%2B1g%40mail.gmail.com.
Kyra Seevers
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXhaUo22f6HGb1zBj65uTUHqH%2BpPhJ31AhNzb12mMnJRg%40mail.gmail.com.