On Thu, Sep 14, 2023 at 11:02 AM Kyra Seevers <kyraseev...@chromium.org> wrote:
> Intent to Experiment: Partitioning :visited links history Phase 1 (Begin > storing triple partition keys for :visited links) > > Contact emails > > kyraseev...@chromium.org > > 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 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%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXhaUo22f6HGb1zBj65uTUHqH%2BpPhJ31AhNzb12mMnJRg%40mail.gmail.com.
