LGTM to experiment Thanks for working on this! I agree with Anne's concerns about fingerprinting risks with shipping this, as well as +Alex Russell <slightly...@chromium.org>'s concerns <https://infrequently.org/2022/03/cache-and-prizes/> about the risk of this devolving into "playing favorites". But these issues would only be worth solving if we see that the benefits of a single-keyed cache for pervasive resources are significant. So I think running a short-term experiment to measure those benefits (while acknowledging and monitoring the risks) is the right way to go about this.
On Wed, Apr 27, 2022 at 11:30 AM Adam Rice <ri...@chromium.org> wrote: > What is an 'off-by-default experiment'? Is that a dev trial flag? > > > Just an ordinary experiment, behind a flag which is off-by-default. So > most users get the default behaviour (no single-keyed cache), except for > those in the experimental group. > > On Wed, 27 Apr 2022 at 00:50, Joe Medley <jmed...@google.com> wrote: > >> What is an 'off-by-default experiment'? Is that a dev trial flag? >> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com | >> 816-678-7195 <(816)%20678-7195> >> *If an API's not documented it doesn't exist.* >> >> >> On Tue, Apr 26, 2022 at 4:59 AM Daisuke Enomoto <denom...@chromium.org> >> wrote: >> >>> Contact emails >>> >>> ri...@chromium.org, nidhij...@chromium.org, denom...@chromium.org >>> >>> Explainer >>> >>> >>> https://docs.google.com/document/d/1pvaMg7J5beBXD7trzHJH_MDULc_wRHLx40MFYAmjknE/edit >>> >>> Specification >>> >>> N/A (because there are no web-exposed changes) >>> >>> Summary >>> >>> This limited experiment measures how much "pervasive payloads" >>> contribute to the performance impact of the split HTTP cache in each Chrome >>> channel over a three-week period. Pervasive payloads are those third-party >>> payloads included on at least 500 sites and fetched at least 10M times in a >>> month, based on Chrome's analysis (payload list included below). This >>> experiment further measures the impact on Core Web Vitals metrics of >>> restoring pervasive payloads (and only pervasive payloads) to a >>> single-keyed cache regime. The privacy benefits of the split HTTP cache are >>> preserved. >>> >>> Blink component >>> >>> Blink>Network >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork> >>> >>> Motivation >>> >>> Browsers split HTTP caches based on the top-frame visited origin >>> (“double-keyed” or "triple-keyed" caching) to prevent sites from tracking >>> users via a timing attack on a cross-site client cache. >>> >>> Chrome’s analysis estimates that split caching results in a 3% increase >>> in cache misses, i.e. fetches for which a payload exists in the cache of >>> the user's device, but is unavailable to the page because it was fetched by >>> the user while loading a page from a different origin. This results in >>> approximately 4% more total bytes being fetched over the network. >>> >>> Our analysis further revealed that many of the redundant fetches caused >>> by split caching were for common payloads associated with displaying user >>> content (libraries, fonts, widgets, ads) or common payloads that assist in >>> operating online businesses (analytics). The delayed arrival of these >>> common payloads resulted in visible "jank" for users, impacting performance >>> metrics like LCP <https://web.dev/lcp>, FCP <https://web.dev/fcp> and >>> CLS <https://web.dev/cls/>. This jank has been associated with negative >>> effects to online business' engagement and conversion rates. Furthermore, >>> delayed loads of analytics and ads payloads can result in missed ads >>> impressions and dropped analytics hits. >>> >>> Initial public proposal >>> >>> This experiment sends a list to Chrome of 100 <URL, hash> pairs whose >>> payloads are considered pervasive (the "pervasive payloads list"). During >>> the three-week experiment period, if Chrome fetches a payload that matches >>> both the URL and its hash on the pervasive payloads list, it is inserted >>> into a local single-keyed cache. This payload is then available for use by >>> Chrome when loading pages on other sites that include the matching URL. All >>> other fetches for URLs not on the pervasive payloads list are cached >>> according to the existing split HTTP cache. >>> >>> The hash covers the payload body and most response headers, except for >>> those which change on every response. >>> >>> To ensure we do not degrade the privacy profile of any users during this >>> experiment, only users with third-party cookies currently enabled will be >>> eligible for the experiment. We will compare the experience of users in >>> experiment and control arms according to total bytes loaded and page >>> performance metrics like the Core Web Vitals <https://web.dev/vitals>. >>> >>> The pervasive payloads list was produced by crawling the web and >>> aggregating the most commonly referenced third-party resource URLs included >>> in HTML content. We then used pseudonymous URL-keyed metrics from Chrome to >>> estimate the traffic to sites and the number of impressions of third-party >>> resources. Individually identifiable browsing or search histories were not >>> used in the creation of the pervasive payload list (for more information >>> about Chrome's data collection policies and privacy policies, see >>> google.com/chrome/privacy). The resulting list was further filtered for >>> any URLs that might contain PII (e.g. URLs with extensive or opaque query >>> parameters). The list was also manually reviewed to ensure it included only >>> payloads reasonably expected to be pervasive; the manual review did not >>> result in any payloads being removed. >>> >>> The privacy properties of the split HTTP cache are considered essential >>> to users and this proposal intends to maintain those properties, >>> specifically by maintaining split HTTP caching for all payloads not on the >>> pervasive payloads list. >>> >>> API semantics are unchanged. User-facing functionality is unchanged >>> (though we expect performance to be slightly improved). >>> >>> The list of the top 100 Pervasive URLs for use in this experiment is >>> pending internal reviews and will be shared on this thread upon approval. >>> Future directions >>> >>> This experiment is the first step in a path exploring improved handling >>> of pervasive payloads in the browser cache. We outline the intended future >>> functionality here to clarify the intentions behind the current experiment. >>> The overview below is not complete or final and subsequent parts of the >>> design and implementation will be presented and discussed in further >>> Intents to Experiment and Prototype. >>> >>> At a high level, a future improvement to the handling of pervasive >>> payloads may involve: >>> >>> >>> - >>> >>> Assembling a list of pervasive payloads that meets the following >>> criteria: >>> - >>> >>> Maintains the privacy of user browsing histories in its creation >>> - >>> >>> Fairly represents pervasive payloads as they have been chosen by >>> developers on the web, not payloads selected or favored by any >>> particular >>> library or browser vendor. >>> - >>> >>> This experiment will initially use a static list of predefined >>> URLs assembled as described in the 'Initial public proposal' >>> section above >>> - >>> >>> A future implementation will likely dynamically update the >>> payloads list on, for example, a weekly cadence. >>> - >>> >>> Implementing shared caching for pervasive payloads that meets the >>> following criteria: >>> - >>> >>> Materially improves load times and responsiveness for web users >>> (under study in this experiment) >>> - >>> >>> Does not create a new tracking vector based on cache timing >>> attacks >>> - >>> >>> Does not require users to fetch payloads before the browser knows >>> they will need it (i.e. we don't plan to bundle payloads with browser >>> installs or updates) >>> - >>> >>> Does not increase local storage required by browser installs or >>> caches >>> >>> >>> To privately and fairly assemble the list of pervasive payloads, we are >>> exploring the use of Private Heavy Hitters >>> <https://www.tensorflow.org/federated/tutorials/private_heavy_hitters>. >>> To implement a privacy-preserving shared cache after the deprecation of >>> third-party cookies, we are exploring adding a measure of randomness to the >>> observed presence or absence of a pervasive payload in the shared cache. >>> >>> However, this work is only worthwhile if it results in materially >>> improved load times for real users. This Intent to Experiment covers only >>> whether or not we should attempt to measure the performance gains that >>> might be realized if pervasive payloads were placed in a shared cache, >>> as one data point among others that will contribute to discussions about >>> future steps for the proposal. >>> >>> TAG review >>> >>> None yet. >>> >>> TAG review status >>> >>> N/A >>> >>> Risks >>> Interoperability and Compatibility >>> >>> Chrome's compliance with the relevant standards is unchanged. Caching >>> behavior differs between browsers so interoperability will not be affected. >>> >>> The list of popular payloads is specifically chosen to minimize >>> compatibility risks. >>> >>> >>> Gecko: No signal >>> >>> WebKit: No signal >>> >>> Web developers: No signals >>> >>> Other signals: >>> >>> WebView application risks >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? No >>> >>> >>> Debuggability >>> >>> There is no developer-exposed API for this feature, so most DevTools >>> support is not relevant. It would be useful to indicate whether a resource >>> was served from the single-keyed cache in the network tab, however this >>> will not be implemented in the initial experiment. >>> >>> Security and privacy >>> >>> Single-keyed caching introduces global state shared between different >>> browsing contexts. A shared cache can introduce information leaks based on >>> cache probing (https://xsleaks.dev/docs/attacks/cache-probing/), >>> including XS-Search (https://xsleaks.dev/docs/attacks/xs-search/) in >>> applications which conditionally load a single-keyed-cache eligible >>> resource based on authenticated user state. The state of the cache, queried >>> across different contexts, could also be used as a fingerprint, permitting >>> user tracking; however, in this case, we believe this does not provide >>> tracking capabilities beyond those of third-party cookies. >>> >>> To protect users during this experiment, we limit the experiment >>> population to those users with third-party cookies enabled. Recognizing >>> that third-party cookies will eventually be switched off for most users >>> <https://privacysandbox.com/>, we are developing protections such as >>> slightly randomizing cache hit/miss checks, disallowing eviction, or >>> guaranteeing attempts to read from the cache reliably populate that cache >>> entry. These protections will be proposed and incorporated before any >>> future optimizations are launched. >>> >>> For the purposes of the current experiment, we will be using the same >>> implementation of single-keyed caching that Chrome used before the HTTP >>> cache was partitioned in M77 ( >>> https://chromestatus.com/feature/5730772021411840). >>> >>> To summarize, the security and privacy restrictions on this experiment >>> are as follows: >>> >>> >>> 1. >>> >>> We will exclude users that have third-party cookies disabled. >>> 2. >>> >>> Only a small percentage of users will be included in the experiment, >>> reducing the likelihood and impact of any attacks abusing the >>> single-keyed >>> cache. >>> 3. >>> >>> We will strictly limit the duration of the experiment on each >>> channel to 3 weeks. >>> 4. >>> >>> We will only serve pervasive resources from the single-keyed cache. >>> 5. >>> >>> We can turn off the experiment immediately (independent of browser >>> updates) if any other threats appear. >>> >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>> ? >>> >>> This behavior is specific to Chrome and not part of any standard, so it >>> will not be tested in web platform tests. >>> >>> Flag name >>> >>> CacheTransparency >>> >>> Requires code in //chrome? >>> >>> No, but the list of popular payloads and the mechanism for distributing >>> it to the browser will be Chrome-specific. >>> >>> Tracking bug >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1309002 >>> >>> Launch bug >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1309353 >>> >>> Estimated milestones >>> >>> M103 for off-by-default experiment >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/5768521127559168 >>> >>> >>> -- >>> 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/CAA5e6990s-e4aYUnYK5%2BqzQpAyFzJa42y%2B%3D_MAnL19z%3DqemnWg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e6990s-e4aYUnYK5%2BqzQpAyFzJa42y%2B%3D_MAnL19z%3DqemnWg%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/CAC_ixdxOWMezzpzGQayKanKuGUe1tfEpBqwLNuq%3DOpuJRwV%2BMQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdxOWMezzpzGQayKanKuGUe1tfEpBqwLNuq%3DOpuJRwV%2BMQ%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/CAL5BFfVjrBb1u%3DsDwJ4cDrkT09QuBKF4wxqO5puu9zXwbrg%2BWw%40mail.gmail.com.
