On Tue, Dec 2, 2025 at 1:25 PM Alex Russell <[email protected]> wrote:
> We've been meeting the web where it is for 15 years, and it has only > created an unsustainable ecosystem of JS excesses. Continuous improvement > in V8 and DOM and networking, e.g., have not yeilded a faster-feeling web, > even on devices that get increasingly faster. [ this is something of a tangential response, given that it is mostly independent of the topic of this Intent, but ... ] I feel like this statement is incorrect. At least per my subjective memory, using the web on mobile (let alone desktop) feels significantly faster and more reliable to me than it did a decade or more ago. Speaking from a privileged place (fast high end devices on fast networks), I rarely think to myself that things are too slow or that, if they are, that the source of the slowness is likely to be either the client device or the network (rather than the service). This was far from the case when we were still mostly on 3G networks (at best) with spotty coverage. Of course, (a) both you and Patrick have spent a lot more time staring at the numbers than I have, so perhaps I'm simply wrong, and (b) there's definitely still room for improvement, most obviously in places where users have low end devices and slow and/or unreliable networks. I don't want to downplay that. But I also don't think we should act as if there's been no progress at all. -- Dirk This is what I'm talking about with induced demand: when we lower the cost > of excess (rather than pushing back on it), the free-riders feel no need to > change. Today, that very much includes most of the employers of the API > OWNERS, and it seems disingenuous of us to rubber-stamp those excesses when > we have proven well beyond any reasonable satisfaction that reeling out > more rope doesn't lead to sustainable user experience improvements. > > The more aggression version of what I'm describing might even be to slow > down or degrade performance of these scripts relative to their size, > multiplied by their prevalence. That is, having gathered the data about > what's popular, shouldn't we be raising the cost of this sort of parasitic > drag on user CPU/battery/bandwidth/memory, rather than subsidising it? I'd > be supportive of Edge pulling that lever if we could coordinate on it with > y'all. > > Best, > > Alex > > On Tuesday, December 2, 2025 at 1:11:38 PM UTC-8 Patrick Meenan wrote: > >> The push-back is largely the same (and likely just as ineffective). Most >> of the resources in the candidate list are updated on a fairly regular >> cadence so even with cache sharing they are still going to be downloaded >> quite frequently even for the same users. This also only helps with the >> download portion, not parse and compile which are as bad, if not worse, >> particularly on the low-end devices (and even with dictionaries, you still >> need to parse and compile ALL of the code). There has been ~5 years of >> "push back" with a fully partitioned cache that had effectively zero impact. >> >> Features, functionality, developer ergonomics, etc, usually take a higher >> priority than amount of code (not always, but I've been watching the HTTP >> Archive graphs for WAY too long). >> >> The magnitude of the improvement would likely be highest on slower >> networks (not necessarily low-end devices except for available storage) and >> network performance for devices will vary wildly over a given month which >> would make it a lot more complicated and less useful unless it was sticky >> (and then it makes the privacy side of things more complicated if it leaks >> if this user is always on a fast network or not). >> >> As we've seen with most performance work, even non-visible improvements >> lead to behavior changes. Consuming more pages, interacting more, etc, >> particularly in the aggregate. >> >> At this point I'm trying to meet the web where it is and see where we can >> improve things where the web decided to go. >> >> On Tue, Dec 2, 2025 at 3:52 PM Alex Russell <[email protected]> >> wrote: >> >>> I've been thinking a *lot * about this Intent, and I would feel much >>> better about it if we were targeting the effects towards users that can >>> benefit, rather than subsidising the excesses of JS libraries that have >>> grown without push-back. The YT player, e.g., is egregiously sized, and it >>> make me queasy to think that we're going to create even more induced demand. >>> >>> I'd support a policy, e.g., that made this feature more likely to >>> trigger the lower-spec'd the device and/or network the user is on. >>> >>> Is that something you'd consider supporting, Pat? >>> >>> Best, >>> >>> Alex >>> >>> On Thursday, November 27, 2025 at 9:15:26 AM UTC-8 Yoav Weiss wrote: >>> >>>> LGTM1 >>>> >>>> This is an important optimization that will take a small step at >>>> evening out the playing field for smaller sites (that use 3Ps and >>>> distributed platforms) compared to large, centralized ones with many repeat >>>> visitors. It will become even more important once it's integrated with >>>> Compression Dictionaries, as it would significantly increase cache >>>> reusability even with high-frequency updates. >>>> >>>> While it does taint the security model a bit compared to pure >>>> triple-keyed cache, I think the benefits outweigh that cost. >>>> >>>> >>>> >>>> On Wednesday, November 19, 2025 at 11:45:47 PM UTC+1 Joe Mason wrote: >>>> >>>> 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. >>>> >>>> On Wednesday, November 19, 2025 at 12:49:34 PM UTC-5 Patrick Meenan >>>> wrote: >>>> >>>> On Wed, Nov 19, 2025 at 12:25 PM Joe Mason <[email protected]> >>>> 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). >>>> >>>> >>>> >>>> On Wednesday, November 19, 2025 at 12:07:48 PM UTC-5 Daniel Bratell >>>> 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. >>>> >>>> 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 >>>> On 2025-11-09 16:46, Patrick Meenan wrote: >>>> >>>> >>>> >>>> On Sat, Nov 8, 2025 at 1:32 PM Yoav Weiss (@Shopify) < >>>> [email protected]> 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 <[email protected]> >>>> 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 >>>> <https://docs.google.com/document/d/1xaoF9iSOojrlPrHZaKIJMK4iRZKA3AD6pQvbSy4ueUQ/edit?tab=t.0> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Nov 7, 2025 at 4:47 PM Rick Byers <[email protected]> wrote: >>>> >>>> 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 >>>> <https://web.dev/articles/stale-while-revalidate> and am proud that we >>>> pushed >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/rspPrQHfFkI/m/c5j3xJQRDAAJ?e=48417069> >>>> through it with urgency and confirmed it indeed increased publisher ad >>>> revenue across the web >>>> <https://web.dev/case-studies/ads-case-study-stale-while-revalidate>. >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> On Thu, Oct 30, 2025 at 3:50 PM Patrick Meenan <[email protected]> >>>> wrote: >>>> >>>> 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). >>>> >>>> >>>> On Thu, Oct 30, 2025 at 5:28 PM Rick Byers <[email protected]> wrote: >>>> >>>> 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 >>>> <https://wpostats.com/> 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 >>>> <https://www.chromium.org/developers/design-documents/network-stack/disk-cache/#eviction>?). >>>> 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 <https://developer.chrome.com/blog/autoplay> >>>> 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 >>>> >>>> On Thu, Oct 30, 2025 at 9:09 AM Matt Menke <[email protected]> wrote: >>>> >>>> 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. >>>> >>>> On Wednesday, October 29, 2025 at 5:08:42 PM UTC-4 Erik Anderson wrote: >>>> >>>> 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). >>>> >>>> >>>> >>>> *From:* Rick Byers <[email protected]> >>>> *Sent:* Wednesday, October 29, 2025 11:56 AM >>>> *To:* Patrick Meenan <[email protected]> >>>> *Cc:* Mike Taylor <[email protected]>; blink-dev < >>>> [email protected]> >>>> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to ship: Cache sharing >>>> for extremely-pervasive resources >>>> >>>> >>>> >>>> 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 >>>> >>>> >>>> >>>> On Mon, Oct 27, 2025 at 10:27 AM Patrick Meenan <[email protected]> >>>> wrote: >>>> >>>> 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. >>>> >>>> >>>> >>>> On Mon, Oct 27, 2025 at 9:39 AM Mike Taylor <[email protected]> >>>> wrote: >>>> >>>> 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)? >>>> >>>> >>>> >>>> *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). >>>> >>>> >>>> >>>> On Wed, Oct 22, 2025 at 5:31 PM Mike Taylor <[email protected]> >>>> wrote: >>>> >>>> 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 >>>> <https://docs.google.com/spreadsheets/d/1TgWhdeqKbGm6hLM9WqnnXLn-iiO4Y9HTjDXjVO2aBqI/edit?usp=sharing>. >>>> >>>> >>>> >>>> >>>> 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 >>>> >>>> -- >>>> 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 visit https://groups.google.com/a/ >>>> chromium.org/d/msgid/blink-dev/CAPq58w6UFSnxxzhGKBnY1BJKiZZeH >>>> 7BUm7PmcjQm_%2BLjGyrtYg%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w6UFSnxxzhGKBnY1BJKiZZeH7BUm7PmcjQm_%2BLjGyrtYg%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 visit https://groups.google.com/a/ >>>> chromium.org/d/msgid/blink-dev/CAFUtAY9Nffq00r- >>>> xbiu2BO00y%2B_2knAi-zheMs9hrE-dB%2BTZ3w%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9Nffq00r-xbiu2BO00y%2B_2knAi-zheMs9hrE-dB%2BTZ3w%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 visit https://groups.google.com/a/ >>>> chromium.org/d/msgid/blink-dev/CAPq58w4ceQ4Df% >>>> 2BzFCYwFM5MSAh4APVXtCHj9Q7o5CP_B%3DKs1kA%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w4ceQ4Df%2BzFCYwFM5MSAh4APVXtCHj9Q7o5CP_B%3DKs1kA%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 visit https://groups.google.com/a/ >>>> chromium.org/d/msgid/blink-dev/CAPq58w5R56xfGBsnOknw1Ha0ns% >>>> 2BQW%2BQhtvPkR0aqHZAmnhiOOg%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w5R56xfGBsnOknw1Ha0ns%2BQW%2BQhtvPkR0aqHZAmnhiOOg%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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6ae4e10-e5e8-404a-b43d-90e21e0267b4n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6ae4e10-e5e8-404a-b43d-90e21e0267b4n%40chromium.org?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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALyq14-Y60OT%3DJxsQRKGzeFEXQX6Un0CY%2BZHM-tKaktD2H0p1g%40mail.gmail.com.
