Given that this change is not web-exposed nor user visible, an LGTM is not required.
Nevertheless, a non-required LGTM to experiment with this!! :) On Thu, Sep 14, 2023 at 5:18 PM Kyra Seevers <[email protected]> wrote: > Thanks for the questions! > > > Does phase 1 have any web-exposed or user-visible changes? > No. Phase 1 has no user-visible changes - only changes to the > HistoryDatabase backend. > > > Not a blocker for the experiment, but might be worthwhile to file > positions early. > SGTM thank you. > > > How long are you planning to run the experiment? > I'm guessing till at least 120 (inclusive), to get 90 days in the DB? > Yes, [118, 120] is the initial plan - we'll update you if there are any > experimental delays. > > Thanks, > Kyra > > On Thu, Sep 14, 2023 at 1:07 PM Yoav Weiss <[email protected]> wrote: > >> >> >> On Thu, Sep 14, 2023 at 11:02 AM Kyra Seevers <[email protected]> >> wrote: >> >>> Intent to Experiment: Partitioning :visited links history Phase 1 (Begin >>> storing triple partition keys for :visited links) >>> >>> Contact emails >>> >>> [email protected] >>> >>> Explainer >>> >>> https://github.com/kyraseevers/Partitioning-visited-links-history >>> >>> Specification >>> >>> None yet - currently getting feedback from the Web Platform community on >>> where (if anywhere) this should be spec’d >>> >>> Summary >>> >>> The goal of this Finch experiment is to slowly roll-out the new >>> VisitedLinkDatabase to users. This database is Phase 1 of the “Partitioning >>> :visited link history” project. The purpose of the VisitedLinkDatabase is >>> to store navigations being added to the HistoryDatabase as triple-keys >>> (i.e. with the information needed to construct the triple-key partitioned >>> :visited link hashtable from disk). Once the feature is rolled-out to >>> users, we will let this database accumulate triple-keys for at least 90 >>> days, so that when we run the Phase 2 experiment (only rendering triple-key >>> partitioned :visited links), we have an initial database to load into >>> memory and users will not begin with a blank slate (and have appropriate >>> recovery data in the event of corruption). >>> >>> The goal of the entire “Partitioning :visited link history” project >>> (broader than the scope of just Phase 1 experiments) is to eliminate user >>> browsing history leaks. In the proposed model, anchor elements are 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 is now 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. No code affecting >>> the VisitedLinks hashtable or renderer is included in this first experiment. >>> >> >> Does phase 1 have any web-exposed or user-visible changes? >> >> >>> >>> 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 >>> >>> Pending - Untriaged >>> >>> Chromium Trial Name >>> >>> N/a >>> >>> WebFeature UseCounter name >>> >>> N/a >>> >>> Risks >>> >>> Interoperability and Compatibility >>> >>> Gecko: No official signals yet >>> >>> WebKit: No official signals yet >>> >> >> Not a blocker for the experiment, but might be worthwhile to file >> positions early. >> >> >>> >>> Web developers: 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. >>> >>> 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. >>> >>> >>> WebView application risks >>> >>> No - 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. We will need to complete a >>> separate design for WebView :visited links in the future. >>> >>> Goals for experimentation >>> >>> Our intent is to run a Finch experiment (not a trial based on opt-in at >>> this time). The goal is threefold: (1) observe the deployment of the new >>> VisitedLinkDatabase, (2) ensure that triple-keying does not cause undue >>> disk burden or key explosion, and (3) eventually roll-out the feature to >>> all users for at least 90 days to collect a sufficient amount of >>> triple-keys so that the second phase of the "partitioning :visited links >>> history" experiment does not start with a completely empty hashtable. >>> >>> We will observe History.VisitedLinkTableCount closely, as well as other >>> related History metrics like History.DatabaseFileMB, Profile.HistorySize, >>> and other History UMA to fulfill goal #2. >>> >>> Risks of experimentation >>> >>> As this is a Finch experiment, it is per-client rather than per-site. >>> The biggest potential risk to clients is an increase in the history file >>> size stored within a user's profile. However, based on pre-experimental >>> metrics analysis, we believe that there is a low probability of key >>> explosion. In the event that this occurs, we will flip our kill switch via >>> Finch. >>> >>> Ongoing technical constraints >>> >>> None >>> >>> >>> Debuggability >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, 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 - there is no public facing endpoint or API that can be tested for >>> this experiment phase. >>> >>> Flag name on chrome://flags >>> >>> N/a >>> >>> Finch feature name >>> >>> PopulateVisitedLinkDatabase >>> >>> Requires code in //chrome? >>> >>> Yes >>> >>> Tracking bug >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1448609 >>> >>> Launch bug >>> >>> https://launch.corp.google.com/launch/4259382 >>> >>> Estimated milestones >>> >>> Finch Trial on desktop >>> >>> 118 >>> >>> Finch Trial on Android (not WebView) >>> >>> 118 >>> >> >> How long are you planning to run the experiment? >> I'm guessing till at least 120 (inclusive), to get 90 days in the DB? >> >> >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/5101991698628608 >>> >>> 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 >>> >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXb8DvTh7T6OzRFeiTAOnukLY6R1fJ9%2BfErdeBeBOX2%2B1g%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BmmbXb8DvTh7T6OzRFeiTAOnukLY6R1fJ9%2BfErdeBeBOX2%2B1g%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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXhaUo22f6HGb1zBj65uTUHqH%2BpPhJ31AhNzb12mMnJRg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXhaUo22f6HGb1zBj65uTUHqH%2BpPhJ31AhNzb12mMnJRg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > > Kyra Seevers (she/her) | Software Engineer | [email protected] | > [email protected] > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUxOdc8SxwVUkD5GnRFB1B1kwGH52OA7cL_M7UY8su77A%40mail.gmail.com.
