Intent to ship: Cache sharing for extremely-pervasive resources

[Patrick Meenan]

Contact emails

pme...@chromium.org

Specification

N/A

Design docs

https://docs.google.com/document/d/1xaoF9iSOojrlPrHZaKIJMK4iRZKA3AD6pQvbSy4ueUQ/edit?usp=sharing

Summary

For a small number (hundreds) of hand-curated static third-party script, stylesheet and compression-dictionary resources that are used on a large portion of the web, Chrome will use a single-keyed HTTP cache to store those resources.

This helps users and site owners with faster performance for those resources that are very widely used while maintaining the privacy protections of the partitioned disk cache. This feature targets the resources that most users are likely to see multiple times across multiple sites in any given browsing session. They are usually not in the critical path of the page loading and may not impact the common performance metrics but they are still important for the healthy operation of the web.

The list of candidate resources is manually curated from the HTTP Archive dataset and updated on an ongoing basis. This includes site-independent things like common analytics scripts, social media embeds, video player embeds, captcha providers and ads libraries.

It allows for code that uses versioned URLs as long as the versioning is not a manual process by embedders and that the same version is sent to everybody at a given point in time with the same contents. This does not include things like common Javascript libraries where they are commonly self-hosted or where the URL references a specific version of the library and it is up to site owners to manually select a version.

i.e. 

Yes: https://maps.googleapis.com/maps-api-v3/api/js/62/5d/common.js

No: https://cdnjs.cloudflare.com/ajax/libs/jquery/3.5.1/jquery.min.js

Blink component

Blink>Network

Web Feature ID

No information provided

Risks

Interoperability and Compatibility

This change is internal to Chrome and should be completely transparent to the web platform with no interoperability risks.

Gecko: N/A

WebKit: N/A

Web developers: No signals

Other signals:

Ergonomics

N/A

Activation

N/A

Security

Cache partitioning added a level of privacy protection that is being disabled for a small number of resources where it is deemed safe to do so. The linked document and issue provide the details on the protections that are in place to minimize the privacy exposure.

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

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

N/A

Tracking bug

https://issues.chromium.org/u/1/issues/404196743

Measurement

The success of this feature will be measured directly with the owners of a small number of targeted scripts with a web-exposed experiment.

Estimated milestones

Shipping on desktop	144
DevTrial on desktop	138
Shipping on Android	144
DevTrial on Android	138
Shipping on WebView	144

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5202380930678784

This intent message was generated by Chrome Platform Status.

[Ben Kelly]

Will the list of manually curated scripts be published somewhere?  I did not immediately see something like this skimming the doc or chrome status entry.

Thanks.

Ben

From: Patrick Meenan <pme...@chromium.org>
Date: Friday, October 17, 2025 at 3:12 PM
To: blink-dev <blin...@chromium.org>
Subject: [blink-dev] Intent to ship: Cache sharing for extremely-pervasive resources

This Message Is From an External Sender

 

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w6%2BOj%2BOOHa1PHp-9auhEBJRGyyLZGWYaJeC3w-E9Y07-g%40mail.gmail.com.

[Patrick Meenan]

Yes. The list will be committed directly to the Chromium repository. The list of candidate resources (before the manual vetting) is in a sheet here.

[Ben Kelly]

Thank you.  Do you expect the list of resources to change over time?  Will http archive data be analyzed for every milestone release?

[Patrick Meenan]

I expect it will change over time but the changes should be pretty minor (as new resources increase or decrease popularity). Generally we'd want to include resources that have been common for a while and are likely to continue to be common.  I'd expect small changes every milestone (or two).  There's also the pervasi...@chromium.org mailing list that you can ping to give us a heads-up (or a CL to Chromium) if there's something specific you want to draw attention to.

[Alex Russell]

This is interesting, given all of the problems involved in governance and the way it cuts against platform progress. Will the full set be downloaded before any pre-population is used? What controls will be in place to make sure that this does not exacerbate cross-site tracking via timing? Will these caches be pushed in a versioned way? Who will make the call about how much can be in the set? And are these delivered via component-updater?

Best,

Alex

On Friday, October 17, 2025 at 1:44:19 PM UTC-7 Patrick Meenan wrote:

I expect it will change over time but the changes should be pretty minor (as new resources increase or decrease popularity). Generally we'd want to include resources that have been common for a while and are likely to continue to be common.  I'd expect small changes every milestone (or two).  There's also the pervasive-cache@chromium.org mailing list that you can ping to give us a heads-up (or a CL to Chromium) if there's something specific you want to draw attention to.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Patrick Meenan]

Nothing is being pre-populated (other than the list of URL patterns). When a "pervasive" resource is encountered naturally by a given user, it will be stored in a single-keyed cache instead of a site/frame/url-keyed cache (reducing storage duplication for that specific resource for that specific user).

The linked doc has all of the mitigations in place, but the big one for explicit tracking is that it can only be used when full cookie access is also allowed, otherwise it falls through to the fully-partitioned cache.

On Fri, Oct 17, 2025 at 4:58 PM Alex Russell <sligh...@chromium.org> wrote:

This is interesting, given all of the problems involved in governance and the way it cuts against platform progress. Will the full set be downloaded before any pre-population is used? What controls will be in place to make sure that this does not exacerbate cross-site tracking via timing? Will these caches be pushed in a versioned way? Who will make the call about how much can be in the set? And are these delivered via component-updater?

Best,

Alex

On Friday, October 17, 2025 at 1:44:19 PM UTC-7 Patrick Meenan wrote:

I expect it will change over time but the changes should be pretty minor (as new resources increase or decrease popularity). Generally we'd want to include resources that have been common for a while and are likely to continue to be common.  I'd expect small changes every milestone (or two).  There's also the pervasi...@chromium.org mailing list that you can ping to give us a heads-up (or a CL to Chromium) if there's something specific you want to draw attention to.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Patrick Meenan]

Assuming we have the privacy and security concerns under control (which we're pretty confident is the case for the extremely small subset of resources we are talking about), the main discussion point is the balancing of incentives and "playing favorites".

As you noted, the performance impact is relatively small but it's not non-zero when you get to the scale of some of the resources we are talking about (like https://www.google-analytics.com/analytics.js which is on 10M of the pages in the 50M page HTTP Archive dataset). This isn't really a framework discussion because those kinds of resources aren't a good fit for the restrictions that are in place for the privacy and security protections but there is a discussion about providing network benefits to specific third-parties that cross the pervasive threshold and meet the rest of the conditions (for at least part of the library).

The question is if the marginal performance benefit that can only be realized at that level of scale (where a given user would be likely to have the current version of that specific library in cache) would be a meaningful competitive factor for a newcomer (vs features, ease of use, pricing, mindshare, etc).

That also gets balanced against the user benefit of not having to keep re-downloading the exact same thing and from having to keep dozens of copies of it in cache, cached with different cache keys (taking cache space away from other resources).

There's also a more nuanced benefit that allows for federation of a feature across domains vs centralizing the experience. For example, Shopify and Wix's platform libraries show up in the candidate list as they are used by hundreds of thousands of sites in the CrUX dataset. Having a shared cache for those libraries would put them into a more competitive position against centralized platforms (Amazon, Etsy, Blogger, etc) while still allowing sites to own the overall experience.

I guess that's the long way of saying "it's complicated but we feel pretty strongly that the theoretical risk in this case is more than offset by the platform benefits".

[Patrick Meenan]

Sorry, I missed a step in making the candidate resource list public. I have moved it to my chromium account and made it public here.

Not everything in that list meets all of the criteria - it's just the first step in the manual curation (same URL served the same content across > 20k sites in the HTTP Archive dataset).

The manual steps frome there for meeting the criteria are basically:

- Cull the list for scripts, stylesheets and compression dictionaries.

- Remove any URLs that use query parameters.

- Exclude any responses that set cookies.

- Identify URLs that are not manually versioned by site embedders (i.e. the embedded resource can not get stale). This is either in-place updating resources or automatically versioned resources.

- Only include URLs that can reliably target a single resource by pattern (i.e. ..../<hash>-common.js but not ..../<hash>.js)

- Get confirmation from the resource owner that the given URL Pattern is and will continue to be appropriate for the single-keyed cache

[Patrick Meenan]

FYI, I updated Chromestatus with Mozilla's position on the feature (strongly negative). It's not a platform-exposed feature but they do have concerns that they wanted to note in a position issue.

[Daniel Bratell]

Thanks for pointing out Mozilla's response. I think they have some fair points.

If we look at the list, it is clear from domain names, that some sites, or entities, will benefit more from others from faster first-loads. I mean, something like 30% of the list are from Google entities, from very harmless (IMHO) hosted fonts to analytics, ads and video hosting (YouTube). Some other big sites like Shopify and Wix/parastorage combine to another 15%.

Having your key resources on that list may not matter very much, or it may. The existence of the list is scary and I lack the data to understand what the pros are both in scale and area. Is the disk space issue a real problem or just something that is a potential concern lacking investigation, for instance?

I understand that the published list is not a final, set-in-stone, item, so I will not comment on individual items, but what thought have there been on maintaining such a list long term? It seems to me that it might become an area of contention that would be nice to avoid.

In the initial intent, the claim was that this is important for the healthy operation of the web. But is it really?

/Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w73DpKeFRJ9jPEQ_jVZh0y01kZvx2iZzRg_Z8ZL%2B_f93Q%40mail.gmail.com.

[Patrick Meenan]

The level of importance for the healthy operation of the web is opinion and debatable but for everything that is determined to be pervasive and safe to include, it will marginally increase the reliability and/or performance of that item loading. Likely fractions of a percent improvement in things like conversion measurement, successful checkouts or recaptcha challenges succeeding. Unlikely to be noticed in individual samples but meaningful for the web at scale. My personal opinion is that these marginal improvements are important for the overall health of the web but others may disagree (or determine that the benefits are not worth the complexity).

As far as disk space goes, the overall cache size is a concern on lower-end devices but it's not clear how much this will improve any individual user's cache. There is probably a lot that could be done in that space to age-out stale versioned resources and prioritize render-blocking resources but it's another marginal cost that we can recover.

As far as maintaining the list long-term, there has been a fair bit of thought put into the process. The list itself has an expiration to make sure we don't get stuck with stale copies if, for some reason, it stops being maintained (yeah, I'm still sore about reader). There is tooling to automate the building of the candidate list and there are plans to improve the automation around filtering the list for patterns to make it much easier to update. It will also be in the git repo so it's not restricted to the core maintainers to keep it updated (i.e. if a provider has a pattern that is in the candidate list but hasn't been added yet, they can submit a CL). The list of patterns is expected to be pretty stable once the initial build-out has been completed though since the patterns are expected to be long-lived and popularity at that scale doesn't change quickly (the privacy protections require the stability to prevent history sniffing).

[Mike Taylor]

On 10/18/25 8:34 a.m., Patrick Meenan wrote:

Sorry, I missed a step in making the candidate resource list public. I have moved it to my chromium account and made it public here.

Not everything in that list meets all of the criteria - it's just the first step in the manual curation (same URL served the same content across > 20k sites in the HTTP Archive dataset).

The manual steps frome there for meeting the criteria are basically:

- Cull the list for scripts, stylesheets and compression dictionaries.

- Remove any URLs that use query parameters.

- Exclude any responses that set cookies.

- Identify URLs that are not manually versioned by site embedders (i.e. the embedded resource can not get stale). This is either in-place updating resources or automatically versioned resources.

- Only include URLs that can reliably target a single resource by pattern (i.e. ..../<hash>-common.js but not ..../<hash>.js)

- Get confirmation from the resource owner that the given URL Pattern is and will continue to be appropriate for the single-keyed cache

A few questions on list curation:

Can you clarify how big the list will be? The privacy review at https://chromestatus.com/feature/5202380930678784?gate=5174931459145728 mentions ~500, while the design doc mentions 1000. I see the candidate resource list starts at ~5000, then presumably manual curation begins to get to one of those numbers.

What is the expected list curation/update cadence? Is it actually manual?

Is there any recourse process for owners of resources that don't want to be included? Do we have documentation on what it mean to be appropriate for the single-keyed cache?

thanks,
Mike

[Patrick Meenan]

The candidate list goes down to 20k occurrences in order to catch resources that were updated mid-crawl and may have multiple entries with different hashes that add up to 100k+ occurrences. In the candidate list, without any filtering, the 100k cutoff is around 600, I'd estimate that well less than 25% of the candidates make it through the filtering for stable pattern, correct resource type and reliable pattern. First release will likely be 100-200 and I don't expect it will ever grow above 500.

As far as cadence goes, I expect there will be a lot of activity for the next few releases as individual patterns are coordinated with the origin owners but then it will settle down to a much more bursty pattern of updates every few Chrome releases (likely linked with an origin changing their application and adding more/different resources). And yes, it is manual.

As far as the process goes, resource owners need to actively assert that their resource is appropriate for the single-keyed cache and that they would like it included (usually in response to active outreach from us but we have the external-facing list for owner-initiated contact as well).  The design doc has the documentation for what it means to be appropriate (and the doc will be moved to a readme page in the repository next to the actual list so it's not a hard-to-find Google doc):

5. Require resource owner opt-in
For each URL to be included, reach out to the team/company responsible for the resource to validate the URL pattern and get assurances that the pattern will always serve the same content to all sites and not be abused for tracking (by using unique URLs within the pattern mask as a bit-mask for fingerprinting). They will also need to validate that the URLs covered by the pattern will not rely on being able to set cookies over HTTP using a Set-Cookie HTTP response header because they will not be re-applied across cache boundaries (the set-cookie is not cached with the resource).

[Mike Taylor]

On 10/22/25 5:48 p.m., Patrick Meenan wrote:

The candidate list goes down to 20k occurrences in order to catch resources that were updated mid-crawl and may have multiple entries with different hashes that add up to 100k+ occurrences. In the candidate list, without any filtering, the 100k cutoff is around 600, I'd estimate that well less than 25% of the candidates make it through the filtering for stable pattern, correct resource type and reliable pattern. First release will likely be 100-200 and I don't expect it will ever grow above 500.

Thanks - I see the living document has been updated to mention 500 as a ceiling.

As far as cadence goes, I expect there will be a lot of activity for the next few releases as individual patterns are coordinated with the origin owners but then it will settle down to a much more bursty pattern of updates every few Chrome releases (likely linked with an origin changing their application and adding more/different resources). And yes, it is manual.

As far as the process goes, resource owners need to actively assert that their resource is appropriate for the single-keyed cache and that they would like it included (usually in response to active outreach from us but we have the external-facing list for owner-initiated contact as well).  The design doc has the documentation for what it means to be appropriate (and the doc will be moved to a readme page in the repository next to the actual list so it's not a hard-to-find Google doc):

Will there be any kind of public record of this assertion? What happens if a site starts using query params or sending cookies? Does the person in charge of manual list curation discover that in the next release? Does that require a new release (I don't know if this lives in component updater, or in the binary itself)?

[Patrick Meenan]

I don't believe the security/privacy protections actually rely on the assertions (and it's unlikely those would be public). It's more for awareness and to make sure they don't accidentally break something with their app if they were relying on the responses being partitioned by site.

As far as query params go, the browser code already only filters for requests with no query params so any that do rely on query params won't get included anyway.

The same goes for cookies. Since the feature is only enabled when third-party cookies are enabled, adding cookies to these responses or putting unique content in them won't actually pierce any new boundaries but it goes against the intent of only using it for public/static resources and they'd lose the benefit of the shared cache when it gets updated. Same goes for the fingerprinting risks if the pattern was abused.

[Rick Byers]

If this is enabled only when 3PCs are enabled, then what are the tradeoffs of going through all this complexity and governance vs. just broadly coupling HTTP cache keying behavior to 3PC status in some way? What can a tracker credibly do with a single-keyed HTTP cache that they cannot do with 3PCs? Are there also concerns about accidental cross-site resource sharing which could be mitigated more simply by other means, eg. by scoping to just to ETag-based caching?

I remember the controversy and some real evidence of harm to users and businesses in 2020 when we partitioned the HTTP cache, but I was convinced that we had to accept that harm in order to credibly achieve 3PCD. At the time I was personally a fan of a proposal like this (even for users without 3PCs) in order to mitigate the harm. But now it seems to me that if we're going to start talking about poking holes in that decision, perhaps we should be doing a larger review of the options in that space with the knowledge that most Chrome users are likely to continue to have 3PCs enabled. WDYT?

Thanks,

   Rick

--

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+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w6UFSnxxzhGKBnY1BJKiZZeH7BUm7PmcjQm_%2BLjGyrtYg%40mail.gmail.com.

[Erik Anderson]

My understanding was that there was believed to be a meaningful security benefit with partitioning the cache. That’s because it would limit a party from being able to inferr that you’ve visited some other site by measuring a side effect tied to how quickly a resource loads. That observation could potentially be made even if that specific adversary doesn’t have any of their own content loaded on the other site.

 

Of course, if there is an entity with a resource loaded across both sites with a 3p cookie and they’re willing to share that info/collude, there’s not much benefit. And even when partitioned, if 3p cookies are enabled, there are potentially measurable side effects that differ based on if the resource request had some specific state in a 3p cookie.

 

Does that incremental security benefit of partitioning the cache justify the performance costs when 3p cookies are still enabled? I’m not sure.

 

Even if partitioning was eliminated, a site could protect themselves a bit by specifying Vary: Origin, but that probably doesn’t sufficiently cover iframe scenarios (nor would I expect most sites to hold it right).

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9Nffq00r-xbiu2BO00y%2B_2knAi-zheMs9hrE-dB%2BTZ3w%40mail.gmail.com.

[Patrick Meenan]

There are two general threat vectors for privacy/security with "shared state" (cache, connections, etc).

1 - Explicit user tracking across site boundaries. Either through unique responses or fingerprinting. This is effectively moot since the tracking can be done directly by cookies when 3PCs are allowed. This proposal isn't aimed at this use case where a cooperating resource can already explicitly track you (and is why the feature is linked to the state of 3PC access). Additional bits of entropy aren't a concern since it is assumed you have direct access to sharing ID's.

2 - XS leaks (history sniffing). This is where I can tell that you bank at BofA because you have the JS loaded that is only used when logged-in, I can tell that you have a gmail account because of similar resource exposure and I can tell that you likely live in or visited Groom Lake, Nevada because the map tiles from Google maps for that location are in your cache.

I think keeping the partitioned cache is still important to solve #2 and the proposal is all about how to find the sweet spot where we can share a cache for the resources that a given user is actually likely to benefit from being shared while limiting the exposure on the information that can be gathered about the browser. It is essentially reduced to "this browser likely visited a page that had ads and may have visited a storefront that was hosted on the shopify platform".

I say "may" because even though the resources are picked to limit the usefulness of the information that can be extrapolated, we still add a bunch of protections to make probing for that state destructive and difficult:

- Any attempt to check a cache entry will write the cache entry (so you can't tell if it was there naturally or from someone else probing).

- Any attempt to probe for multiple versions of a resource that match the same pattern will fall back to using the partitioned cache.

I'm happy to explore if you think there are other options to solve for #2 while unlocking more of the shared cache but this is my best attempt at clawing back the real-world benefits of the single-keyed cache while keeping the privacy and security benefits that come with the fully-partitioned cache.

[Matt Menke]

Note that even with Vary: Origin, we still have to load the HTTP request headers from the disk cache to apply the vary header, which leaks timing information, so "Vary: Origin" is not a sufficient security mechanism to prevent that sort of cross-site attack.

[Rick Byers]

Thanks Erik and Patrick, of course that makes sense. Sorry for the naive question. My naive reading of the design doc suggested to me that a lot of the privacy mitigations were about preventing the cross-site tracking risk. Could the design be simplified by removing some of those mitigations? For example, the section about reaching out to the resource owners, to what extent is that really necessary when all we're trying to mitigate is XS leaks? Don't the popularity properties alone mitigate that sufficiently?

What can you share about the magnitude of the performance benefit in practice in your experiments? In particular for LCP, since we know that correlates well with user engagement (and against abandonment) and so presumably user value. 

The concern about not wanting to further advantage more popular sites over less popular ones resonates with me. Part of that argument seems to apply broadly to the idea of any LRU cache (especially one with a reuse bias which I believe ours has?). But perhaps an important distinction here is that the benefits are determined globally vs. on a user-by-user basis? But I think any solution that worked on a user-by-user basis would have the XS leak problem, right? Perhaps it's worth reflecting on our stance on using crowd-sourced data to try to improve the experience for all users while still being fair to sites broadly. In general I think this is something Chromium is much more open to (where it brings significant user benefit) than other engines. For example, our Media Engagement Index system has some similar properties in terms of using aggregate user behaviour to help decide which sites have the power to play audio on page load and which don't. I was personally uncertain at the time if the complexity would prove to be worth the benefit, but now I'm quite convinced it is. Playing audio on load is just something users and developers want in a few cases, but not most cases. I wonder if perhaps cross-site caching is similar?

Rick

[Patrick Meenan]

Reaching out to site owners was mostly for a sanity check that the resource is not expecting to be partitioned for some reason (even though the payloads are known to be identical). If it helps, we can replace the reach-out step with a requirement that the responses be "Cache-Control: public" (and hard-enforce it in the browser by not writing the resource to cache if it isn't). That is an explicit indicator that the resources are cacheable in shared upstream caches.

I removed the 2 items from the design doc that were specifically targeted at direct fingerprinting since that's moot with the 3PC link (as well as the fingerprinting bits from the validation with resource owners).

On the site-preferencing concern, it doesn't actually preference large sites but it does preference currently-popular third-party resources (most of which are provided by large corporations). The benefit is spread across all of the sites that they are embedded in (funnily enough, most large sites won't benefit because they don't tend to use third-parties).

Determining the common resources at a local level exposes the same XS Leak issues as allowing all resources (i.e. your local map tiles will show up in multiple cache partitions because they all reference your current location but they can be used to identify your location since they are not globally common). Instead of using the HTTP Archive to collect the candidates, we could presumably build a centralized list based on aggregated common resources that are seen across cache partitions by each user but that feels like an awful lot of complexity for a very small number of resulting resources.

On the test results, sorry, I thought I had included the experiment results in the I2S but it looks like I may not have.

The test was specifically just with the patterns for the Google ads scripts because we aren't expecting this feature to impact the vitals for the main page/content since most of the pervasive resources are third-party content that is usually async already and not critical-path. It's possible some video or map embeds might trigger LCP in some cases but that's the exception more than the norm. This is more geared to making those supporting things work better while maintaining the user experience. Ads has the kind of instrumentation that we'd need to be able to get visibility into the success (or failure) of that assumption and to be able to measure small changes.

The results were stat-sig positive but relatively small. The ad iframes displayed their content slightly faster and transmitted fewer bytes for each frame (very low single digit percentages).

The guardrail metrics, including vitals) were all neutral which is what we were hoping for (improvement without a cost of increased contention).

If you'd feel more comfortable with gathering more data, I wouldn't be opposed to running the full list at 1% to check the guardrail metrics again before fully launching. We won't necessarily expect to see positive movement to justify a launch since the resources are still async but we can validate that assumption with the full list at least (if that is the only remaining concern).

[Rick Byers]

Thanks Pat. I am personally a big fan of things which increase publisher ad revenue across the web broadly without hurting (or ideally improving) the user experience, and this seems likely to do exactly that. In particular I recall all the debate around stale-while-revalidate and am proud that we pushed through it with urgency and confirmed it indeed increased publisher ad revenue across the web.

Reading the Mozilla feedback carefully the point that resonates most with me is the risk of "gatekeeping" and the potential to mitigate that by establishing objective rules for inclusion. Is it plausible to imagine a version of this where the list construction would be entirely objective? What would the tradeoffs be?

Thanks,

   Rick 

[Patrick Meenan]

The list construction should already be completely objective. I changed the manual origin-owner validation to trust and require "cache-control: public" instead. The rest of the criteria should be well-defined and objective. I'm not sure if they can be fully automated yet (though that might just be my pre-AI thinking).

The main need for humans in the loop right now is to create the patterns so that they each represent a "single" resource that is stable over time with URL changes (version/hash) and distinguishing those stable files from random hash bundles that aren't stable from release to release. That's fairly easy for a human to do (and get right).

[Yoav Weiss (@Shopify)]

I'm extremely supportive of this effort, with multiple hats on.

I'd have loved if this wasn't restricted to users with 3P cookies enabled, but one can imagine abuse where pervasive resource *patterns* are used, but with unique hashes that are not deployed in the wild, and where each such URL is used as a cross-origin bit of entropy.

On Sat, Nov 8, 2025 at 7:04 AM Patrick Meenan <pme...@chromium.org> wrote:

The list construction should already be completely objective. I changed the manual origin-owner validation to trust and require "cache-control: public" instead. The rest of the criteria should be well-defined and objective. I'm not sure if they can be fully automated yet (though that might just be my pre-AI thinking).

The main need for humans in the loop right now is to create the patterns so that they each represent a "single" resource that is stable over time with URL changes (version/hash) and distinguishing those stable files from random hash bundles that aren't stable from release to release. That's fairly easy for a human to do (and get right).

This is something that origins that use compression dictionaries already do by themselves - define the "match" pattern that covers the URL's semantics. Can we somehow use that for automation where it exists?

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w4ceQ4Df%2BzFCYwFM5MSAh4APVXtCHj9Q7o5CP_B%3DKs1kA%40mail.gmail.com.

[Patrick Meenan]

On Sat, Nov 8, 2025 at 1:32 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

I'm extremely supportive of this effort, with multiple hats on.

I'd have loved if this wasn't restricted to users with 3P cookies enabled, but one can imagine abuse where pervasive resource *patterns* are used, but with unique hashes that are not deployed in the wild, and where each such URL is used as a cross-origin bit of entropy.

Yep, there are 2 risks for explicit tracking (that are effectively moot when you can track directly anyway). Differing the content of some of the responses some of the time (maybe for a slightly different URL than the "current" version that still matches the pattern) and using a broad sample of not-current URLs across a bunch of origins as a fingerprint. We can make some of that harder but I couldn't think of any way to completely eliminate the risk.

 

On Sat, Nov 8, 2025 at 7:04 AM Patrick Meenan <pme...@chromium.org> wrote:

The list construction should already be completely objective. I changed the manual origin-owner validation to trust and require "cache-control: public" instead. The rest of the criteria should be well-defined and objective. I'm not sure if they can be fully automated yet (though that might just be my pre-AI thinking).

The main need for humans in the loop right now is to create the patterns so that they each represent a "single" resource that is stable over time with URL changes (version/hash) and distinguishing those stable files from random hash bundles that aren't stable from release to release. That's fairly easy for a human to do (and get right).

This is something that origins that use compression dictionaries already do by themselves - define the "match" pattern that covers the URL's semantics. Can we somehow use that for automation where it exists?

We can use the match patterns for script and style destinations as an input when defining the patterns. If the resource URL matches the match pattern and the match pattern is reasonably long (not /app/*.js) then it's probably a good pattern (and could be validated across months of HTTP Archive logs). There are patterns where dictionaries aren't used as strict delta updates for the same file (i.e. a script with a lot of common code that portions of which might be in other scripts used on other pages) so I wouldn't want to use it blindly but it is a very strong possibility.

[Daniel Bratell]

We had a discussion about this in the API OWNERS meeting and I was asked to make my thoughts public. 

There are a couple of aspects to this:

1. This is trying to mitigate some negative effects of a security/privacy enhancing change (triple keyed cache). The negative effects are, as far as I can determine, in the form of reduced ad revenue ("web ecosystem") because some ad network scripts will have to be reloaded from servers.

2. There is a fundamental idea that a browser should treat every resource on the web equally (modulo security and some other exceptions). This is violating that idea.

3. The list of resources that will be allowed to bypass the third cache key was created through a reasonably impartial method. Still, because the web is what it is, that resulted in certain entities getting a lot of their resources on the list. If I recall correctly, 30% of the list was Google resources in one form or another.

4. Every resource on the list opens up the potential for the security/privacy issues that the triple keyed cache was meant to protect against. Is there a point where the list has undermined enough of the benefits that the whole triple keyed cache should be dropped instead?

All of this, and more, has to be weighed against each other to get to a solution with an "ideal" balance. I currently do not know what that balance is. 

I do not like the look of certain aspects here, but on the other hand I do like the security/privacy improvements and it would be sad if those have to be reverted because some considered them too costly.

This post does not really change anything, but just so that you know what is being voiced. And if someone has more to add, please do add your own information and thoughts. Especially if I have misunderstood or mischaracterized something. That is what these threads are for.

/Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w5R56xfGBsnOknw1Ha0ns%2BQW%2BQhtvPkR0aqHZAmnhiOOg%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

On Wed, Nov 19, 2025 at 6:06 PM Daniel Bratell <brat...@gmail.com> wrote:

We had a discussion about this in the API OWNERS meeting and I was asked to make my thoughts public. 

There are a couple of aspects to this:

1. This is trying to mitigate some negative effects of a security/privacy enhancing change (triple keyed cache). The negative effects are, as far as I can determine, in the form of reduced ad revenue ("web ecosystem") because some ad network scripts will have to be reloaded from servers.

I'd like to emphasize that at least in my view this is not just about ad revenue and not just about the performance cost we lost when moving to partitioned cached.

Squinting a bit into the future, this feature can enable compression dictionaries to be significantly more impactful, and operate on large widgets loaded by many top-level origins (e.g. maps and video players), reducing their costs across the web.

[Joe Mason]

Regarding the concern that tying this to 3P cookies will make it harder to disable 3P cookies completely: have you considered making this a separate UI toggle instead? 

[Patrick Meenan]

On Wed, Nov 19, 2025 at 12:25 PM Joe Mason <joenot...@google.com> wrote:

Regarding the concern that tying this to 3P cookies will make it harder to disable 3P cookies completely: have you considered making this a separate UI toggle instead? 

A separate UI toggle would be more confusing than useful to the user.

The link to cookies is because of the risk of explicit user tracking and fingerprinting (which is reduced with the protections but non-zero with the shared cache). Third-party cookies is a stand-in for "allow me to be tracked across websites". It would probably be more accurate to have a more friendly top-level name like that and cookies would be a feature that is automatically toggled (along with a shared cache) but I don't see there being a useful distinction for users to be able to toggle the different fingerprinting risks individually (AFAIK, there are a few different features linked to cookie tracking for the same reason).

[Patrick Meenan]

On Wed, Nov 19, 2025 at 12:06 PM Daniel Bratell <brat...@gmail.com> wrote:

We had a discussion about this in the API OWNERS meeting and I was asked to make my thoughts public. 

There are a couple of aspects to this:

1. This is trying to mitigate some negative effects of a security/privacy enhancing change (triple keyed cache). The negative effects are, as far as I can determine, in the form of reduced ad revenue ("web ecosystem") because some ad network scripts will have to be reloaded from servers.

Ad revenue was the easiest to measure but it spans things like faster captcha challenges, faster embedded maps, faster embedded videos, faster consent banners, more reliable analytics and a few other cases (for some set of highly-used providers) though the actual impact is small (likely not user-visible but meaningful at-scale).

2. There is a fundamental idea that a browser should treat every resource on the web equally (modulo security and some other exceptions). This is violating that idea.

3. The list of resources that will be allowed to bypass the third cache key was created through a reasonably impartial method. Still, because the web is what it is, that resulted in certain entities getting a lot of their resources on the list. If I recall correctly, 30% of the list was Google resources in one form or another.

4. Every resource on the list opens up the potential for the security/privacy issues that the triple keyed cache was meant to protect against. Is there a point where the list has undermined enough of the benefits that the whole triple keyed cache should be dropped instead?

One of the really big problems with the full single-keyed cache was that ALL resources ended up in it, even if they weren't intended to be shared and  the regular cache is easily probed (i.e. fetch only-if-cached). That exposed things like evil.com being able to probe for resources from mybank.com that are only loaded for logged-in accounts (which really have no business in being shared). There is a pretty solid line between "third-party resources intended to be shared" and "first-party resources that are inadvertently sniffable". The fuzziness in the proposal comes down to where on the scale of "how common is this intended-to-be-shared resource?" a given resource lies to minimize any information that could be inferred.

[Rick Byers]

On Wed, Nov 19, 2025 at 1:02 PM Patrick Meenan <pme...@chromium.org> wrote:

On Wed, Nov 19, 2025 at 12:06 PM Daniel Bratell <brat...@gmail.com> wrote:

We had a discussion about this in the API OWNERS meeting and I was asked to make my thoughts public. 

There are a couple of aspects to this:

1. This is trying to mitigate some negative effects of a security/privacy enhancing change (triple keyed cache). The negative effects are, as far as I can determine, in the form of reduced ad revenue ("web ecosystem") because some ad network scripts will have to be reloaded from servers.

Ad revenue was the easiest to measure but it spans things like faster captcha challenges, faster embedded maps, faster embedded videos, faster consent banners, more reliable analytics and a few other cases (for some set of highly-used providers) though the actual impact is small (likely not user-visible but meaningful at-scale).

When we moved to the triple-keyed  cache I recall an argument that it was going to hurt small sites more than it hurt big sites, the argument being that sites users visit frequently will generally still benefit from the cache, but the long torso and tail of sites users visit only infrequently will no longer have the benefit of shared caching. What do you make of that argument? Is there any chance that it's something you could quantify in some way? Eg. for sites that have consent banners, embedded videos or embedded maps, can we measure a positive impact from this feature and can we stratify that by site popularity to test whether the impact accrues disproportionately to less popular sites as this argument suggests? 

2. There is a fundamental idea that a browser should treat every resource on the web equally (modulo security and some other exceptions). This is violating that idea.

3. The list of resources that will be allowed to bypass the third cache key was created through a reasonably impartial method. Still, because the web is what it is, that resulted in certain entities getting a lot of their resources on the list. If I recall correctly, 30% of the list was Google resources in one form or another.

4. Every resource on the list opens up the potential for the security/privacy issues that the triple keyed cache was meant to protect against. Is there a point where the list has undermined enough of the benefits that the whole triple keyed cache should be dropped instead?

One of the really big problems with the full single-keyed cache was that ALL resources ended up in it, even if they weren't intended to be shared and  the regular cache is easily probed (i.e. fetch only-if-cached). That exposed things like evil.com being able to probe for resources from mybank.com that are only loaded for logged-in accounts (which really have no business in being shared). There is a pretty solid line between "third-party resources intended to be shared" and "first-party resources that are inadvertently sniffable". The fuzziness in the proposal comes down to where on the scale of "how common is this intended-to-be-shared resource?" a given resource lies to minimize any information that could be inferred.

I agree there's an important fundamental distinction here. What if "third-party resources intended to be shared" was an API? If servers had to explicitly opt resources into the shared cache (with guidance saying that loads of such resources shouldn't be conditional on user state), how would that impact the design? Would we still need to compute a list of "pervasive" resources" or could we safely allow any resource marked as such to be shared when 3PCs are enabled?

For a minute I thought maybe "Access-Control-Allow-Origin: *" might even be an OK proxy for such an API, but it looks to me like even google maps tiles set that so XS leaks would still be a problem with that, right?

[Thomas Steiner]

On Wed, Nov 19, 2025, 19:58 Rick Byers <rby...@chromium.org> wrote:

On Wed, Nov 19, 2025 at 1:02 PM Patrick Meenan <pme...@chromium.org> wrote:

On Wed, Nov 19, 2025 at 12:06 PM Daniel Bratell <brat...@gmail.com> wrote:

We had a discussion about this in the API OWNERS meeting and I was asked to make my thoughts public. 

There are a couple of aspects to this:

1. This is trying to mitigate some negative effects of a security/privacy enhancing change (triple keyed cache). The negative effects are, as far as I can determine, in the form of reduced ad revenue ("web ecosystem") because some ad network scripts will have to be reloaded from servers.

Ad revenue was the easiest to measure but it spans things like faster captcha challenges, faster embedded maps, faster embedded videos, faster consent banners, more reliable analytics and a few other cases (for some set of highly-used providers) though the actual impact is small (likely not user-visible but meaningful at-scale).

When we moved to the triple-keyed  cache I recall an argument that it was going to hurt small sites more than it hurt big sites, the argument being that sites users visit frequently will generally still benefit from the cache, but the long torso and tail of sites users visit only infrequently will no longer have the benefit of shared caching. What do you make of that argument? Is there any chance that it's something you could quantify in some way? Eg. for sites that have consent banners, embedded videos or embedded maps, can we measure a positive impact from this feature and can we stratify that by site popularity to test whether the impact accrues disproportionately to less popular sites as this argument suggests? 

2. There is a fundamental idea that a browser should treat every resource on the web equally (modulo security and some other exceptions). This is violating that idea.

3. The list of resources that will be allowed to bypass the third cache key was created through a reasonably impartial method. Still, because the web is what it is, that resulted in certain entities getting a lot of their resources on the list. If I recall correctly, 30% of the list was Google resources in one form or another.

4. Every resource on the list opens up the potential for the security/privacy issues that the triple keyed cache was meant to protect against. Is there a point where the list has undermined enough of the benefits that the whole triple keyed cache should be dropped instead?

One of the really big problems with the full single-keyed cache was that ALL resources ended up in it, even if they weren't intended to be shared and  the regular cache is easily probed (i.e. fetch only-if-cached). That exposed things like evil.com being able to probe for resources from mybank.com that are only loaded for logged-in accounts (which really have no business in being shared). There is a pretty solid line between "third-party resources intended to be shared" and "first-party resources that are inadvertently sniffable". The fuzziness in the proposal comes down to where on the scale of "how common is this intended-to-be-shared resource?" a given resource lies to minimize any information that could be inferred.

I agree there's an important fundamental distinction here. What if "third-party resources intended to be shared" was an API? If servers had to explicitly opt resources into the shared cache (with guidance saying that loads of such resources shouldn't be conditional on user state), how would that impact the design? Would we still need to compute a list of "pervasive" resources" or could we safely allow any resource marked as such to be shared when 3PCs are enabled?

Said API is essentially what we're exploring with https://github.com/explainers-by-googlers/cross-origin-storage, mostly but not exclusively aimed at AI models initially, but Flutter have shown interest as well for their Wasm resources. Patrick is aware of this proposal, and we agreed that the two approaches address distinct use cases. 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9vA5yJszPKk1Chw2NTHj2bw-j%3DpdgzWehMgA7NgNZHYA%40mail.gmail.com.

Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com, toot.cafe/@tomayac)

Google Spain, S.L.U.

Torre Picasso, Pl. Pablo Ruiz Picasso, 1, Tetuán, 28020 Madrid, Spain

CIF: B63272603

Inscrita en el Registro Mercantil de Madrid, sección 8, Hoja M­-435397 Tomo 24227 Folio 25

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.4.8 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck

0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181.

----- END PGP SIGNATURE -----

[Patrick Meenan]

On Wed, Nov 19, 2025 at 1:57 PM Rick Byers <rby...@chromium.org> wrote:

On Wed, Nov 19, 2025 at 1:02 PM Patrick Meenan <pme...@chromium.org> wrote:

On Wed, Nov 19, 2025 at 12:06 PM Daniel Bratell <brat...@gmail.com> wrote:

We had a discussion about this in the API OWNERS meeting and I was asked to make my thoughts public. 

There are a couple of aspects to this:

1. This is trying to mitigate some negative effects of a security/privacy enhancing change (triple keyed cache). The negative effects are, as far as I can determine, in the form of reduced ad revenue ("web ecosystem") because some ad network scripts will have to be reloaded from servers.

Ad revenue was the easiest to measure but it spans things like faster captcha challenges, faster embedded maps, faster embedded videos, faster consent banners, more reliable analytics and a few other cases (for some set of highly-used providers) though the actual impact is small (likely not user-visible but meaningful at-scale).

When we moved to the triple-keyed  cache I recall an argument that it was going to hurt small sites more than it hurt big sites, the argument being that sites users visit frequently will generally still benefit from the cache, but the long torso and tail of sites users visit only infrequently will no longer have the benefit of shared caching. What do you make of that argument? Is there any chance that it's something you could quantify in some way? Eg. for sites that have consent banners, embedded videos or embedded maps, can we measure a positive impact from this feature and can we stratify that by site popularity to test whether the impact accrues disproportionately to less popular sites as this argument suggests? 

Maybe? We could pick a few specific resources that we want to measure, run a test with those specific resources only and then look at the results. Stratifying the results is where things get complicated (maybe UKM?). The simplest case for something like this would be Amazon vs Shopify where the Shopify platform has some pervasive resources and represents a long-tail of individual sites though I'm not sure if the cadence of their updates is faster than a user tends to shop across different sites (limiting the usefulness).

 

2. There is a fundamental idea that a browser should treat every resource on the web equally (modulo security and some other exceptions). This is violating that idea.

3. The list of resources that will be allowed to bypass the third cache key was created through a reasonably impartial method. Still, because the web is what it is, that resulted in certain entities getting a lot of their resources on the list. If I recall correctly, 30% of the list was Google resources in one form or another.

4. Every resource on the list opens up the potential for the security/privacy issues that the triple keyed cache was meant to protect against. Is there a point where the list has undermined enough of the benefits that the whole triple keyed cache should be dropped instead?

One of the really big problems with the full single-keyed cache was that ALL resources ended up in it, even if they weren't intended to be shared and  the regular cache is easily probed (i.e. fetch only-if-cached). That exposed things like evil.com being able to probe for resources from mybank.com that are only loaded for logged-in accounts (which really have no business in being shared). There is a pretty solid line between "third-party resources intended to be shared" and "first-party resources that are inadvertently sniffable". The fuzziness in the proposal comes down to where on the scale of "how common is this intended-to-be-shared resource?" a given resource lies to minimize any information that could be inferred.

I agree there's an important fundamental distinction here. What if "third-party resources intended to be shared" was an API? If servers had to explicitly opt resources into the shared cache (with guidance saying that loads of such resources shouldn't be conditional on user state), how would that impact the design? Would we still need to compute a list of "pervasive" resources" or could we safely allow any resource marked as such to be shared when 3PCs are enabled?

We'd still need some sense of what information about the user could be leaked in an XS attack (like the maps example) and it's not clear that the provider of the resource can (or should) be able to stipulate that. Something like an old version of jquery served from cdnjs might be marked as "shared" but only used on a single site and it could leak that specific site in the history (or probabilistic across a few sites).

Complexity-wise it would be doable but add a bit of overhead since you can't tell at request time in that case if a request should use the shared cache. It would have to cache-miss every request on the shared cache first before checking the triple-keyed cache and then decide which cache to write it to when it gets the response. This could be limited to third-party requests and the cache check could be a quick memory check but it's still more overhead on the bulk of outbound requests.

[Rick Byers]

On Wed, Nov 19, 2025 at 2:37 PM Patrick Meenan <pme...@chromium.org> wrote:

On Wed, Nov 19, 2025 at 1:57 PM Rick Byers <rby...@chromium.org> wrote:

On Wed, Nov 19, 2025 at 1:02 PM Patrick Meenan <pme...@chromium.org> wrote:

On Wed, Nov 19, 2025 at 12:06 PM Daniel Bratell <brat...@gmail.com> wrote:

We had a discussion about this in the API OWNERS meeting and I was asked to make my thoughts public. 

There are a couple of aspects to this:

1. This is trying to mitigate some negative effects of a security/privacy enhancing change (triple keyed cache). The negative effects are, as far as I can determine, in the form of reduced ad revenue ("web ecosystem") because some ad network scripts will have to be reloaded from servers.

Ad revenue was the easiest to measure but it spans things like faster captcha challenges, faster embedded maps, faster embedded videos, faster consent banners, more reliable analytics and a few other cases (for some set of highly-used providers) though the actual impact is small (likely not user-visible but meaningful at-scale).

When we moved to the triple-keyed  cache I recall an argument that it was going to hurt small sites more than it hurt big sites, the argument being that sites users visit frequently will generally still benefit from the cache, but the long torso and tail of sites users visit only infrequently will no longer have the benefit of shared caching. What do you make of that argument? Is there any chance that it's something you could quantify in some way? Eg. for sites that have consent banners, embedded videos or embedded maps, can we measure a positive impact from this feature and can we stratify that by site popularity to test whether the impact accrues disproportionately to less popular sites as this argument suggests? 

Maybe? We could pick a few specific resources that we want to measure, run a test with those specific resources only and then look at the results. Stratifying the results is where things get complicated (maybe UKM?). The simplest case for something like this would be Amazon vs Shopify where the Shopify platform has some pervasive resources and represents a long-tail of individual sites though I'm not sure if the cadence of their updates is faster than a user tends to shop across different sites (limiting the usefulness).

Yes, I was thinking of a UKM analysis (seen some similar things from @Annie Sullivan for example).  I'm not sure if there'd be enough power in a 1% trial to see an effect with any particular resource, of if we'd have to find some way to study them all in aggregate. From the discussion in the blink API owners meeting today, if we did have data showing a concrete benefit for smaller sites over larger ones I think several of us would see that as an argument in favor of shipping this feature.  

2. There is a fundamental idea that a browser should treat every resource on the web equally (modulo security and some other exceptions). This is violating that idea.

3. The list of resources that will be allowed to bypass the third cache key was created through a reasonably impartial method. Still, because the web is what it is, that resulted in certain entities getting a lot of their resources on the list. If I recall correctly, 30% of the list was Google resources in one form or another.

4. Every resource on the list opens up the potential for the security/privacy issues that the triple keyed cache was meant to protect against. Is there a point where the list has undermined enough of the benefits that the whole triple keyed cache should be dropped instead?

One of the really big problems with the full single-keyed cache was that ALL resources ended up in it, even if they weren't intended to be shared and  the regular cache is easily probed (i.e. fetch only-if-cached). That exposed things like evil.com being able to probe for resources from mybank.com that are only loaded for logged-in accounts (which really have no business in being shared). There is a pretty solid line between "third-party resources intended to be shared" and "first-party resources that are inadvertently sniffable". The fuzziness in the proposal comes down to where on the scale of "how common is this intended-to-be-shared resource?" a given resource lies to minimize any information that could be inferred.

I agree there's an important fundamental distinction here. What if "third-party resources intended to be shared" was an API? If servers had to explicitly opt resources into the shared cache (with guidance saying that loads of such resources shouldn't be conditional on user state), how would that impact the design? Would we still need to compute a list of "pervasive" resources" or could we safely allow any resource marked as such to be shared when 3PCs are enabled?

We'd still need some sense of what information about the user could be leaked in an XS attack (like the maps example) and it's not clear that the provider of the resource can (or should) be able to stipulate that. Something like an old version of jquery served from cdnjs might be marked as "shared" but only used on a single site and it could leak that specific site in the history (or probabilistic across a few sites).

Ah, good example, thanks.

Complexity-wise it would be doable but add a bit of overhead since you can't tell at request time in that case if a request should use the shared cache. It would have to cache-miss every request on the shared cache first before checking the triple-keyed cache and then decide which cache to write it to when it gets the response. This could be limited to third-party requests and the cache check could be a quick memory check but it's still more overhead on the bulk of outbound requests.

Oh, interesting point on implementation complexity, thanks.

[Joe Mason]

My thought was that the risk of fingerprinting is MUCH lower with this cache than with 3p cookies in general, so a user that wants to disable 3p cookies for better anonymity might be ok with leaving the pervasive cache on. Tying it to 3p cookies seems to inflate the danger.

I like the idea of making the top-level name something like "allow me to be tracked across websites", but I wouldn't expect the pervasive cache ad described to actually allow that so it would be misleading to tie it to that language. (Also, I'm wary of a setting called "allow me to be tracked", because we can't fully DISALLOW that - information leaks will always be possible, we can only make fingerprinting harder or easier.)

What about a "Difficulty of tracking me across websites" slider, from "trivial" (3p cookies enabled) to "moderate" (features like pervasive cache and other minor fingerprinting risks enabled) to "difficult" (but never "impossible").

This is getting far afield, though. I don't want to derail the discussion, just noodling.