One point of clarification: we are intending to experiment for one milestone (M128), but would like to request 3 milestones (M128 - M130) in case of any delays.
Thanks so much! On Wed, Jul 3, 2024 at 2:16 PM Kyra Seevers <kyraseev...@chromium.org> wrote: > 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%2BmmbXbJX%2BW5m9351o8qZV56SAnsmEfDbSwTr6YHPrpQUx%3DG2Q%40mail.gmail.com.
