[cowsup]

To explain CHIPS very simply: In the Internet of yore, if you loaded example.com and it had facebook.com embedded, then facebook.com would be able to access all of the facebook.com cookies. This is fine on paper, but Facebook encouraged well-meaning website owners to add a "Share" button to encourage organic sharing of their website. When users loaded a page with this button, that embed would get access to all of the facebook.com cookies, thus being able to know who you are, and the site you were visiting from. They'd record this and use it for advertisements.

With CHIPS, you can login to Facebook.com and your cookies are stored in the "cookie jar" labelled "facebook.com." Then, when you go to example.com, the "cookie jar" that the Facebook embed can use is "example.com->facebook.com." This means that Facebook cannot use cookies to track you across every website.

Unlike outright blocking cookies, however, CHIPS still allow well-behaved embeds to function. This allows customer service chatrooms to retain history, videos to remember where you last stopped, and so forth, even on subsequent refreshes, since they can read and write to their own "example.com->[embedded site domain]" cookie jar.

This compromise perfectly breaks cross-site tracking, while allowing useful third-party embeds to still operate.

[namdnay]

> while allowing useful third-party embeds to still operate

the problem is that it breaks third-party embeds that want to provide SSO login, see my other comment. if google had released their "pop-in" suggestion it could have worked

[Vinnl]

Which is what that other example, FedCM, is intended to solve, no?

[namdnay]

yes but that requires working on existing integrations, whereas pop-ins would have "just worked"