Contact emails kyraseev...@chromium.org, miketa...@chromium.org, a...@google.com
Explainer https://github.com/explainers-by-googlers/Partitioning-visited-links-history Specification https://drafts.csswg.org/selectors-4/#visited-privacy Summary To eliminate user browsing history leaks, anchor elements are styled as :visited 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. There is an exception for "self-links", where links to a site's own pages can be styled as :visited even if they have not been clicked on in this exact top-level site and frame origin before. This exemption is only enabled in top-level frames or subframes which are same-origin with the top-level frame. The privacy benefits above are still achieved because sites may already know which of its subpages a user has visited, so no new information is exposed. This was a community-requested exception which improves user experience as well. Blink component Blink>History>VisitedLinks <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EHistory%3EVisitedLinks%22> 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 Satisfied with concerns Risks Interoperability and Compatibility There has been lots of word-of-mouth and official interest from the Web Platform in adopting this feature cross-browser. Gecko: Positive (https://github.com/mozilla/standards-positions/issues/1040) WebKit: No signal (https://github.com/WebKit/standards-positions/issues/363) Web developers: No official signals, see below for more details Other signals: Positive or neutral initial signals from security and privacy researchers at the XS-Leaks summit. There are no security concerns about this design and lots of interest in finally resolving this exploit. 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 via renderer compromises. WebView application risks There is no risk for WebView based-applications because WebView has its own History system and stores :visited links using different code from the other platforms. For this reason, we are not shipping triple-key partitioning to WebView. 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? No This feature is not tested by automated Web Platform Tests because the :visited selector, in its current state, 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 a manual test <https://chromium-review.googlesource.com/c/chromium/src/+/6262650/8> which relies on users visually confirming the correct links are :visited, or unit and integration tests internal to Chrome. DevTrial instructions https://github.com/explainers-by-googlers/Partitioning-visited-links-history?tab=readme-ov-file#how-to-experiment Flag name on about://flags #partition-visited-link-database-with-self-links Finch feature name PartitionVisitedLinkDatabaseWithSelfLinks Requires code in //chrome? True - code is added to 2 areas of //chrome code: 1. chrome/browser/history/history_tab_helper.h/.cc to add explicit parameters for top-level site and is_ephemeral to HistoryAddPageArgs and populate them; we later access this information in non-chrome code to add navigations to the history database 2. chrome/browser/chrome_content_browser_client.cc to add a navigation throttle which intercepts the origins of incoming navigations (doesn’t actually throttle) to calculate its per-origin salt. This was added as part of the mitigations to prevent the entire table being leaked in the event of a renderer compromise. Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1448609 Launch bug https://launch.corp.google.com/launch/4330864 Availability expectation Other browsers have expressed interest in implementing :visited links partitioning at TPAC 2023 and 2024. I expect that the feature is available across the Web Platform in the next couple of years. Non-OSS dependencies Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function? No Estimated milestones Enabled by Default on Desktop and Android* 135 Stable 100% via Finch on Desktop and Android* 133 Multi-Arm Finch Experiment Began 128 Multi-Arm Finch Experiment Ended 133 Database Finch Experiment Began 118 Database Finch Experiment Ended 121 DevTrial on Desktop and Android Began 132 * We intend to launch to Stable 100% via Finch configuration, which will have a min milestone of M133. The corresponding ENABLED_BY_DEFAULT chromium CL will likely land in M135. Anticipated spec changes The current CSS Selectors spec language is broad enough to support partitioning :visited link history. However, we have added specification that UAs MUST take some action to protect user browsing history [1], with a note which describes our triple-key solution [2]: [1] https://drafts.csswg.org/selectors-4/#link [2] https://drafts.csswg.org/selectors-4/#visited-privacy Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5101991698628608?gate=5127548398206976 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/d/msgid/blink-dev/CA%2BmmbXYy4CSMuPLY0HJuTbZt0qPz5ZUsGUToFJuCE%2BTfC86umA%40mail.gmail.com Intent to Experiment (Phase 2): https://groups.google.com/a/chromium.org/g/blink-dev/c/U5AX0OXaxM8/m/tIGr4bJJBgAJ?utm_medium=email&utm_source=footer Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/lg73meqgggo/m/dgqIFrveDgAJ?utm_medium=email&utm_source=footer 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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXY%3D2PpZ9cQ5EQBLDwi2F6O7gocPDm7cZEw-6C2huodEmg%40mail.gmail.com.
