Intent to Experiment: Partitioning :visited links history Phase 1 (Begin storing triple partition keys for :visited links)
Contact emails kyraseev...@chromium.org 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 Blink>History>VisitedLinks <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHistory%3EVisitedLinks> Search tags visited links <https://chromestatus.com/features#tags:visited%20links>, :visited selector <https://chromestatus.com/features#tags::visited%20selector>, partitioning history <https://chromestatus.com/features#tags:partitioning%20history> 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 <https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-06-21-minutes.md> - 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? 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 Finch Trial on desktop 118 Finch Trial on Android (not WebView) 118 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 <https://chromestatus.com/>. -- 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+unsubscr...@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.
