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 > -- 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/CAOmohS%2BAfFmXHwXd2gHa_v2mSSNYPvEqSCJhh-8%2BqD_aW%3D0DJQ%40mail.gmail.com.
