Very exciting to see progress on this longstanding problem! On Sat, Feb 15, 2025 at 3:35 AM Kyra Seevers <kyraseev...@chromium.org> wrote:
> 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 > As you note below, this isn't a real specification of the behavior you're proposing to ship. Instead, it contains that behavior in a non-normative appendix. It's therefore unclear to what extent the behavior here represents cross-browser consensus, and what types of interop and compat risks this is leaving us up to. Can you say more about what's missing from getting a cross-browser agreed-upon algorithm specified by the CSSWG? Are there other candidate algorithms that other browsers are championing, which we might be in conflict with? > > 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. > Couldn't this be tested with reftests <https://web-platform-tests.org/writing-tests/reftests.html>? > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXY%3D2PpZ9cQ5EQBLDwi2F6O7gocPDm7cZEw-6C2huodEmg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAM0wra8yFJeNMjti6yfo2D-1Jmyg5nLLafAbXiqUceX3Z8ZSZg%40mail.gmail.com.
