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/CANyVgfDQw6wQSGJRCVxY-bkyLZoGrOQBJLP6u%2BqxP6HTNEL%2B5Q%40mail.gmail.com.
