Theoretically I think you need to send a new intent, but I don't think it'd be helpful here.
LGTM to continue experimenting in M133 On Tue, Jan 14, 2025 at 7:44 PM Kyra Seevers <kyraseev...@google.com> wrote: > Hi all - Happy New Year! > > As an FYI, due to some extra time spent in debugging and analysis, will be > continuing with low-level (Stable 1% or lower) Finch experiments in M133. > Luckily this is within 6 milestones of our original experiment request date > (I will be sure to just go ahead and request 6 next time :)). > > Please feel free to respond with any questions or concerns - thanks so > much! > > Thanks, > Kyra > > > On Tue, Oct 15, 2024 at 10:32 PM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> >> >> On Tue, Oct 15, 2024 at 10:47 PM Kyra Seevers <kyraseev...@google.com> >> wrote: >> >>> 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! >>> >> >> Awesome!! >> >> >>> >>> 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 >>> >> > > -- > > 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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BiXHDMEmU%3DLyBfVHoPnFGTEW%2BuMNjEJ4TeknTeG_fOkA%40mail.gmail.com.
