I echo @nicjansma 's concerns here about the limit of 10. It's very common to have value-add software tied into a site, and CDN customers often employ value-add services from the CDN. Typically if those features need to remember state, they do it with a cookie (usually first party, not third party), and each product involved would have its own cookie. Sometimes the workflow of the products require more than one cookie each.

I understand the basis of the 10 count was from look at some sort of data about number of cookies observed in the wild. What exactly was the data based on? It's worth noting that for CDN value-add services, origins might not actually receive the related cookies. If we were counting from origin logs of some kind the data might be deceiving.

Recap of the points made in yesterday:

• Chrome explained that the 10 cookies per-domain-per-partition limit is to reduce the memory impact of CHIPS. The number comes from analysis done using HTTP Archive (crawlable web) which showed this satisfies most use cases.
• Safari suggested that CHIPS be limited to only 2-3 cookies per-domain-per-partition.
• Edge replied that with a much lower cookie jar limit, sites may need some mechanism to tell when they have reached theirs (no such mechanism exists today).
• Mozilla mentioned that using the crawlable web for analysis will probably undercount the number of cookies site use today. They also suggested setting the size limit per-domain-per-partition using the number of bytes used by the cookies rather than the number of cookies. Currently the max byte size of a single cookie is 4KB.
• The Washington Post mentioned that changing cookie limits to be based on memory instead of number of cookies will be a difficult transition for developers.
• Safari replied that limiting the size of cookies has led to issues in the past, e.g. bugs introduced by browsers truncating cookies.
• The Washington Post and Safari suggested we could introduce an API to signal to sites when they hit cookie limits, it could be via HTTP or on the page.

Thanks all for your contributions!

@elreydetodo thanks for your comment and concerns.

The original data was collected using a query on the HTTP Archive dataset, which crawls the public web. We are aware this dataset has limitations and may not be reflective of cookie usage across the non-searchable web.

To account for this, I have added a metric to Chrome to track the maximum number of SameSite=None cookies a single domain has on clients' machines. We will see if the distribution matches our earlier findings, and if not, what action can be taken to come up with a more reasonable limit.

We discussed this at TPAC (slides, minutes (will probably move out of Google Docs eventually)).

Chrome (@krgovind) recommended increasing the number of allowed cookies to 40 while decreasing the maximum size per cookie to 512B - 1KB, based on collected metrics. This would mean up to 20-40KB of memory for cookies per embedded origin, as before, with the benefit of allowing more cookies to be stored with smaller values overall. This was generally well received by attendants, with some saying that for their use cases they'd rather need more than larger cookies.

WebKit (@johnwilander) stated that they're not comfortable with the memory impact and would prefer a much smaller size. John, to follow up here, do you mind giving us an estimate of what an acceptable impact on memory could be for you? Looking at the 2-3 cookie recommendation in #48 (comment) is it ~ 12KB? What would you think of a byte-only cap that does not count the number of cookies but rather rejects after a certain size in bytes is reached and allows for flexible allocation (up to 4KB per cookie)?

Just out of curiosity, since I don't know exactly how the cookie limit is being enforced, is there an option for something like 40 cookies or 40KB, whichever comes first. This would allow some vendors who have just a couple of cookies but one is some large state bag to work as well as those that have a lot of cookies. Would this be tricky to implement and/or difficult to communicate the limits for? I suppose it means you could have inconsistent failures but any size limit on cookies means that sometimes a set-cookie could succeed and other times it would fail. So ... is this an option?

I think the main tricky thing might be figuring out how to compute the total size of a cookie, but there's probably something reasonable we could use such as len(name) + len(value) + 10 or some such.

Hey all, and thanks for your contributions!

After spending some time thinking about your feedback, we wanted to suggest we change the CHIPS proposal's per-partition-per-domain cookie limit to be based on the memory used (i.e. the number of bytes used in the name and value) instead of the number of cookies. While we understand this is a different paradigm for cookie jar limits, we think it is a good way to meet the different cookies use cases on the web while minimizing the memory impact of CHIPS.

Based on @johannhof 's comment, we think a limit of ~10-12KB per domain per partition is reasonable to us but we are open to other suggestions.

Our thinking is that any cookie would cause the domain to go over its per-partition limit would be rejected. This is based on the precedent that cookies which are over the individual 4KB limit are rejected at creation.

Let us know if using memory footprint instead of cookie number sounds reasonable to you all, and if the limit we proposed makes sense. Thanks!

@bvandersloot-mozilla - FYI, we are proposing to change the CHIPS per-site, per-partition limit to be a cumulative limit of 10-12KB total, instead of a static limit on the number of cookies, and size-per-cookie. Any concerns from the Firefox team with that direction?

@bvandersloot-mozilla - FYI, we are proposing to change the CHIPS per-site, per-partition limit to be a cumulative limit of 10-12KB total, instead of a static limit on the number of cookies, and size-per-cookie. Any concerns from the Firefox team with that direction?

Nope, this sounds like the right solution.