LGTM3 One question raised <https://x.com/miketaylr/status/1808452993504739821> elsewhere was around same-origin links, where links to origin B visited from origin A should be then marked as visited when linked directly from B. I see there's an open issue <https://github.com/kyraseevers/Partitioning-visited-links-history/issues/6> on this. It'd be good if one of the experiment's goals would be to determine if this is a blocker or not for initial shipping.
On Wed, Jul 3, 2024 at 10:12 PM Daniel Bratell <bratel...@gmail.com> wrote: > LGTM2 for a low percentage finch experiment in M128-M130 (inclusive) > > /Daniel > On 2024-07-03 22:02, Chris Harrelson wrote: > > LGTM1 > > (probably 3 needed because this is a non-standard experiment) > > On Wed, Jul 3, 2024 at 12:28 PM Kyra Seevers <kyraseev...@chromium.org> > wrote: > >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXbJX%2BW5m9351o8qZV56SAnsmEfDbSwTr6YHPrpQUx%3DG2Q%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/c88842b3-894d-49c6-be1a-d83f7fdae7ea%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c88842b3-894d-49c6-be1a-d83f7fdae7ea%40gmail.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/CAOmohSLzt-06_bsRvJzNm%2BDgkGaV15bE3QiY%3DaoN-krLY8NSOQ%40mail.gmail.com.
