johannhof
commented
2 years ago Recapping key points from our discussion at yesterday's PrivacyCG call:
- Reps from Chrome, Firefox, Safari and Edge were all generally supportive of CHIPS, of course with some details still to be figured out.
- Firefox, Safari and Edge are also interested in exploring partitioning based on requestStorageAccess, however that is not blocking progress on CHIPS.
- Some of the more detailed concerns that were discussed:
- How should partitioning the top-level work? (https://github.com/WICG/CHIPS/issues/38)
- First-Party Sets should not be integrated tightly into CHIPS, to allow adoption for browsers that don't support FPS or when FPS is disabled. (This might be solved by specifying integration with CHIPS in FPS instead of vice-versa).
- In Slack there was also a conversation around the right venue for standardization. Given the positive signals from PrivacyCG I'm inclined to think that it might be a good place for incubation, but generally the primary venue for standardization is the HTTP WG, pending some decision on https://github.com/httpwg/http-extensions/issues/2084
Another detail that wasn't discussed because we were out of time was giving servers more context on requests, which is now part 6 of https://github.com/privacycg/meetings/issues/19
Overall I think we made great progress!
bvandersloot-mozilla
Cookies Having Independent Partitioned State (CHIPS) is a proposal for a new cookie attribute, Partitioned. This attribute will indicate to user agents that these cross-site cookies should only be available in the same top-level context (top-level site or that site's First-Party Set if it has one) that the cookie was first set in.
In order to improve user privacy on the web, browsers are planning or have already begun to phase out third-party cookies (Chrome, Safari, Firefox). In order to continue to support cross-site cookie use cases which are restricted to a user's activity within a single top-level site, browsers have implemented and attempted to ship partitioned cookies, i.e. cookies which are only sent when a user agent is on the same top-level site as when the cookies were sent. For example, Firefox implemented partitioning cross-site cookies by top-level site by default in their Total Cookie Protection, which is enabled in ETP Strict mode. Safari previously tried implementing cookie partitioning, but eventually rolled it back. One of the stated reasons for the rollback was developer confusion with the partitioned semantics. They have since proposed leveraging the Storage Access API to allow developers to opt in to receiving partitioned state.
CHIPS differs from previous cookie partitioning design mainly because CHIPS requires third-party sites to set their cookies with the
Partitionedattribute. We believe a third-party developer opt-in (instead of partitioning by default) will provide site owners the opportunity to migrate their system to the new cookie behavior before completely phasing out cross-site cookies that are set without thePartitionedattribute. In addition, it affords developers a choice between partitioned and unpartitioned cookies on user agents that continue to support unpartitioned cross-site cookies - whether by default, or for domains that may be allowlisted by user/device owner configuration. Unlike the Storage Access API, this proposal would also allow cross-site requests to receive cookies without requiring them to load a JavaScript execution context.The developer opt-in also gives browser vendors an opportunity to incentivize developers to adopt best practices for cookies. For example, CHIPS requires cookies set with the Partitioned attribute must also be set with the __Host- prefix, requiring the cookies be host-bound and only sent over secure channels.
CHIPS also proposes to use the top-level site’s First-Party Set (FPS) owner as the partition key. This allows third-party service providers to use the same session identifier across sites within the same FPS, and allows them to serve common workflows such as single sign-on, and consent management across the sites, as long as they are within the same FPS.
Finally, our proposal also suggests user agents to not apply the 180 per-domain cookie limit to partitioned cookies, since this leaks information about users' state across different top-level sites. Instead, we recommend user agents apply a per-partition limit on the number of cookies that third-party domains can store. To prevent partitioned cookies from having a large memory footprint, we recommend that this limit be small, on the order of ~5-10 cookies.
Compatibility Considerations
Older clients will ignore the Partitioned attribute, and treat the cookie as unpartitioned in cross-site contexts. In order to allow developers to disambiguate requests coming from a partitioned context, we are also proposing modifying/adding a Fetch Metadata request header (w3c/webappsec-fetch-metadata/issues/80) to indicate when a request is coming from a partition context.