From Bitnami MediaWiki
Jump to navigation Jump to search


Google's Cookies Having Independent Partitioned State (CHIPS) proposal enables sites to rely on supply chain partners for embedded service on their site that do not rely on aggregating data across multiple other sources.

With CHIPs, Google would allow an organization's supply chain partner to access a customer-specific version of its third-party cookie store, called a cookie "partition."

Google lists the following third-party supply chain partners they had in mind when designing CHIPS:

  • Third-party Map embeds
    • Allowing 3P cookies to store user's favorite location
  • Third-party customer service chat embeds
    • Allowing 3P cookies to store user's pre-authorized customer ID during account signup
  • Third-party Content Delivery Networks (CDNs)
    • Allowing 3P cookies for CDN to remember which network path was fastest
    • Allowing 3P cookies to serve access-controlled content
  • Front-end frameworks that rely on remote hosting and RPCs to remote services
    • Allowing 3P cookies to store state information
  • Other types of third-party SaaS embeds[1]
    • Allowing 3P cookies to store state information

Google suggests that an opt-in should be required for organizations that must rely on supply chain partners to provide services that rival their larger competitors.[2]

This is in line with another Google proposal (HTTP State Tokens) referenced by CHIPS, that states people should have line item control over the supply chain partners that support the websites they frequent. "Users must always have the ability to opt-out of sending this token to any entity, just as they do with cookies today."[3]

Google further suggests they should limit the number of supply chain partners any given site can work with to some maximum number (e.g., 180 partners).[4]


The largest impact of CHIPs is likely the impaired user experience on smaller businesses. Imagine a new customer was searching for a nearby restaurant. For smaller sites, the user would be presented a popup to allow the site's map partner's embed to display the local map. If the user wanted to chat to make a reservation, the user would be prompted with yet another popup to allow the site to rely on a chat partner's embed.

In contrast, a larger site (say a national chain restaurant) that hired its own chat service to take orders and relied on its own engineers to provide map functionality on its website would provide the same information without any annoying popups.

It is unfortunate in the example above, that the user experience was impaired while exchanging only non-sensitive information (location of the business, availability for a given slot).

Open Questions

  • Which risks to people will these changes reduce or eliminate?
  • Do people prefer to be prompted for sharing of non-sensitive information associated with pseudonymous data, such as illustrated in the restaurant example above?