What is that? I'm trying to understand what this is because I need or may need to explain it in writing to the external world in a few weeks. I've never heard of a CacheTransparancy flag. Joe Medley | Technical Writer, Chrome DevRel | [email protected] | 816-678-7195 *If an API's not documented it doesn't exist.*
On Thu, Apr 28, 2022 at 1:26 AM Adam Rice <[email protected]> wrote: > 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 <(816)%20678-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/CAJUhtG_ppUwox1R%3DeEFvQ426iM08UWrKNVVpffzytJLh0Zw0FA%40mail.gmail.com.
