10 cookies per cookie jar limit

[nicjansma]

Hi everyone!

In the CHIPS explainer, it mentions that

User agents must limit third-party domains to just one or some small number of cookies per-partition

https://github.com/privacycg/CHIPS#limit-the-number-of-cookies-a-third-party-can-use-in-a-single-partition

The Memory Impact section also mentions research on choosing 10 as that cookie limit per partition (where partitions are based on top-level third-party domains):

https://github.com/privacycg/CHIPS#memory-impact

This is in comparison to today's behavior of imposing a cookie limit per-page for all first- and third-party domains (e.g. of 180+).

We're trying to understand whether a per-partition limit (of 10 or less) may have an impact in some cases, i.e. potentially causing existing scenarios to break.

One scenario we think this could impact is for services like CDNs that offer TLDs that host their customer's content. For example, there are domains like *.akamaihd.net that many of our Akamai CDN customers may use. Each customer has their own subdomain of akamaihd.net, such as customer1.akamaihd.net.

(Some Akamai CDN customers CNAME their own domains pointing to customer1.akamaihd.net, but others just use their given customer1.akamaihd.net directly)

Those Akamai CDN customers using *.akamaihd.net may be providing third-party resources for yet other websites (Akamai customers or not). So today there are websites with multiple *.akamaihd.net resources from different vendors all on the same page.

Will this be an issue if there are only 10 cookies limited to each partitioned jar? We're honestly not sure. We have a lot of customers, some of which deliver 3rd-party content, and they could each have their own several cookies they set. If multiple of our customers's contents are embedded on another website, it's feasible that they could start to trip over the 10 cookie-per-partition limit.

We think there may be some cases where 10 is not enough in practice, because even combinations of our own security products may set 5+ cookies. A 15 cookie limit seems less likely to cause a problem than 10, but we're not sure what a reasonable number would be.

(Note we're also in the process of getting akamaihd.net on the Public Suffix List which we understand would ensure subdomains to akamaihd.net get their own partitions. That may take a while to be completed though. In the meantime, we figured we'd open this issue as there may be others with similar concerns).

[elreydetodo]

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.

[DCtheTall]

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!

[DCtheTall]

@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.

[johannhof]

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)?

[LGraber]

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?

[annevk]

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.

[DCtheTall]

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!

[krgovind]

@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]

@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.

[annevk]

@krgovind presumably the individual cookie limit would still be enforced? Or would partitioned cookies be allowed to be longer than non-partitioned cookies?

(I need a little longer to answer the more general question.)

[krgovind]

@krgovind presumably the individual cookie limit would still be enforced? Or would partitioned cookies be allowed to be longer than non-partitioned cookies?

(I need a little longer to answer the more general question.)

@annevk Good question! Yes, we think it makes sense to enforce the currently specified 4096 bytes as an individual cookie limit.

[DCtheTall]

In addition to continuing to enforce the 4096-byte individual cookie limit, it might make sense to also restrict domains to 180 cookies per partition in addition to the 10-12 KB limit. This would prevent sites from setting 1000 10-byte cookies, which could lead to performance issues since cookies have some memory overhead beyond the name and value of the cookie.

[bvandersloot-mozilla]

I personally agree with both- partitioned cookies should have strict constraints over cookie limits, not relaxing in any way.

[nicjansma]

Thank you everyone for reviewing this and discussing solutions. A 10-12 KB limit seems reasonable to me, and would help with some of the scenarios we were concerned about in the opening comment.