Description
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
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).