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/CAOMQ%2Bw9dR_stuWyALv3xQDzGC90_vddoiMEsZfuBGmDSL_oHnA%40mail.gmail.com.
