Hi all, FYI: we have had some delays in the experimental rollout and will be continuing with low-level (Stable 1% or lower) Finch experiments in M131 (and probably in M132 as well).
Feel free to respond with any questions or concerns - thanks so much! @Yoav Weiss <yoavwe...@chromium.org> due to the extra development time we were able to include this concept (what we're calling self-links) in our multi-armed experiment to determine if it is feasible! Thanks, Kyra On Wed, Jul 3, 2024 at 10:27 PM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLzt-06_bsRvJzNm%2BDgkGaV15bE3QiY%3DaoN-krLY8NSOQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Kyra Seevers (she/her) | Software Engineer | kyraseev...@google.com | kyraseev...@chromium.org -- 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/CANyVgfBqtNkPPb4-vnocmXxVxVK5U1Cv63xiCBs8ZsAj_yX8MQ%40mail.gmail.com.
