Intent to Experiment: Partitioning :visited links history Phase 2 (User-facing partitioning for :visited links) Contact emails
kyraseev...@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 <https://www.w3.org/TR/selectors-4/#link>: “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 <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 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 <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. - 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? 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 <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%2BmmbXYy4CSMuPLY0HJuTbZt0qPz5ZUsGUToFJuCE%2BTfC86umA%40mail.gmail.com.
