If it's a feature flag, please put milestones in the the appropriate dev trial milestone fields.
Thanks Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com | 816-678-7195 *If an API's not documented it doesn't exist.* On Sun, May 1, 2022 at 5:56 PM Daisuke Enomoto <denom...@chromium.org> wrote: > Hi Joe, > > CacheTransparancy is the feature name we use for the feature flag. As Adam > mentioned, the feature is off by default. Yes, we use Finch to determine > the control/experiment group on each channel (50% on canary & dev, 10% on > beta, 1% on stable). > > On Thu, Apr 28, 2022 at 11:46 PM Joe Medley <jmed...@google.com> wrote: > >> 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 | jmed...@google.com | >> 816-678-7195 <(816)%20678-7195> >> *If an API's not documented it doesn't exist.* >> >> >> On Thu, Apr 28, 2022 at 1:26 AM Adam Rice <ri...@chromium.org> wrote: >> >>> Finch flag? >>> >>> >>> CacheTransparency (but the code is not landed yet). >>> >>> On Thu, 28 Apr 2022 at 03:07, Joe Medley <jmed...@google.com> wrote: >>> >>>> Finch 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 Wed, Apr 27, 2022 at 2: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/CAJUhtG_EOobCVU3VD-Un%2BJCWjgv85SFiX5HbFA3w35kpxFaWyA%40mail.gmail.com.
