> > Finch flag?
CacheTransparency (but the code is not landed yet). On Thu, 28 Apr 2022 at 03:07, Joe Medley <[email protected]> wrote: > Finch flag? > Joe Medley | Technical Writer, Chrome DevRel | [email protected] | > 816-678-7195 > *If an API's not documented it doesn't exist.* > > > On Wed, Apr 27, 2022 at 2:30 AM Adam Rice <[email protected]> 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 <[email protected]> wrote: >> >>> What is an 'off-by-default experiment'? Is that a dev trial flag? >>> Joe Medley | Technical Writer, Chrome DevRel | [email protected] | >>> 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 <[email protected]> >>> wrote: >>> >>>> Contact emails >>>> >>>> [email protected], [email protected], [email protected] >>>> >>>> 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 [email protected]. >>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdw8ZCD7Un2HhnP1mwzwjGbD2sqzcR4dZNdCma6%2BnOuBrw%40mail.gmail.com.
