Update: I wanted to update the thread that WebKit left positive indications of support for this proposal in the request for position recently: https://github.com/WebKit/standards-positions/issues/363.
Daniel: Thanks for the question! We will be using a traditional Finch experiment rollout starting with Canary/Dev in M128. I will update this thread with any changes to the experiment that occur. As for why we chose our keying structure: top-level site allows us to prevent cross-site leaks and frame origin allows us to adhere to the same-origin policy and avoid cross-frame leaks. For example, if I have an iframe c.com embedded in both a.com and b.com, keying by top-level site removes the opportunity for cross-site tracking to occur between these two iframes. For a visual example of this, please see the explainer (especially Key Scenarios #2 and #3): https://github.com/kyraseevers/Partitioning-visited-links-history?tab=readme-ov-file#key-scenarios . Thanks all, Kyra On Wed, Jul 3, 2024 at 10:48 AM Daniel Bratell <bratel...@gmail.com> wrote: > What milestones do you plan to run the experiment in? > > (Also, why isn't it enough to key on frame origin? I'm sure there is a > good reason but it's not obvious.) > > /Daniel > On 2024-07-02 22:42, Kyra Seevers wrote: > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXYy4CSMuPLY0HJuTbZt0qPz5ZUsGUToFJuCE%2BTfC86umA%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXZfYQVP%3DZuT36TirpB_ffk6TpE5xfp0376eC8ODwkLLeA%40mail.gmail.com.
