4 ms·

> Some recent good examples of the designed-for-purpose approach include: > FedCM. Third-party cookies have been used to support single sign-on. FedCM is a set

> Some recent good examples of the designed-for-purpose approach include: > FedCM. Third-party cookies have been used to support single sign-on. FedCM is a set of technologies built to support identity federation, without replicating all functionality of third-party cookies. >CHIPS. The goal of CHIPS is to allow state, without supporting correlation or tracking between web sites which don't know they are collaborating, for example, when embedding third-party services like customer service webchat. I've not heard of these two approaches. Can anyone vouch for their efficacy?

namdnay 2y ago
CHIPS is a nice solution, the problem is how it interacts with SSO IDP login pages. 99% of IDPs in an enterprise setting are configured to refuse being framed (for "security" reasons). What does this mean? That any embedded component that needs to log the user in needs to trigger a popup window - but wait, a popup window isn't in the same cookie partition as the iframe! Some clever people at Google did come up with a solution for this, "pop-ins": https://github.com/explainers-by-googlers/partitioned-popins https://github.com/explainers-by-googlers/partitioned-popins , which would have allowed cookie partitioning without breaking every enterprise integration out there
- mschuster91 2y ago
  "99% of IDPs in an enterprise setting are configured to refuse being framed (for "security" reasons)" No need for the quotation around "security". Clickjacks and other forms of attacks involving iframing authentication providers are a real threat.
  - namdnay 2y ago
    yes, fair enough
cowsup 2y ago
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 2y ago
  > 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 2y ago
    Which is what that other example, FedCM, is intended to solve, no?
    - namdnay 2y ago
      yes but that requires working on existing integrations, whereas pop-ins would have "just worked"

namdnay 2y ago

CHIPS is a nice solution, the problem is how it interacts with SSO IDP login pages. 99% of IDPs in an enterprise setting are configured to refuse being framed (for "security" reasons). What does this mean? That any embedded component that needs to log the user in needs to trigger a popup window - but wait, a popup window isn't in the same cookie partition as the iframe! Some clever people at Google did come up with a solution for this, "pop-ins": https://github.com/explainers-by-googlers/partitioned-popins https://github.com/explainers-by-googlers/partitioned-popins , which would have allowed cookie partitioning without breaking every enterprise integration out there

mschuster91 2y ago
"99% of IDPs in an enterprise setting are configured to refuse being framed (for "security" reasons)" No need for the quotation around "security". Clickjacks and other forms of attacks involving iframing authentication providers are a real threat.
- namdnay 2y ago
  yes, fair enough

cowsup 2y ago

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 2y ago
> 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 2y ago
  Which is what that other example, FedCM, is intended to solve, no?
  - namdnay 2y ago
    yes but that requires working on existing integrations, whereas pop-ins would have "just worked"