2 ms·

This exists already. You can have cookies at higher level of the same domain. So foo.example.com and bar.example.com can share cookies at example.com. You can a

by koolba 1y ago

This exists already. You can have cookies at higher level of the same domain. So foo.example.com and bar.example.com can share cookies at example.com. You can also use CORS to interact with a truly third party site. None of these require third party cookies.

nwalters512 1y ago
A use case this doesn't address is embedding across two completely different domains, which is pretty common in the education space with LMS platforms like Canvas (https://www.instructure.com/canvas https://www.instructure.com/canvas) embedding other tools for things like quizzes, textbooks, or grading. I ended up in a Chrome trial that disabled third-party cookies which broke a lot of these embeds because they can no longer set identity cookies that they rely on from within their iframe.
svieira 1y ago
As nwalters also points out, this isn't the same at all. System A and System A' both from Source Α are not the same as System A (Source Α) and System B (Source Β). Which you know, because you say "you can also use CORS to interact with a truly third party site". But now, I invite you to go the rest of the way - what if the third party site isn't Project Gutenburg but `goodreads.com/my-reading-lists`? That is, what if the information that you want to pull into System A from System B should only be available to you and not to anyone on the net?
- cuu508 1y ago
  Use OAuth2 to get system B's access token, then use authenticated server-to-server API requests to pull needed information from system B.
  - namdnay 1y ago
    This multiplies the cost of the integration by at least an order of magnitude
  - svieira 1y ago
    BINGO! The issue here of course is that now instead of _two_ components (Front End A and Embed B) you now have four (the back ends must communicate and if A didn't need a back end ... well, now it does). Now, if you meant "Use OAuth2 in the browser", that's just the original case (you can't authorize if you can't authenticate and it's the ambient authentication that's being stripped when you eliminate third party cookies).

by koolba 1y ago

nwalters512 1y ago

A use case this doesn't address is embedding across two completely different domains, which is pretty common in the education space with LMS platforms like Canvas (https://www.instructure.com/canvas https://www.instructure.com/canvas) embedding other tools for things like quizzes, textbooks, or grading. I ended up in a Chrome trial that disabled third-party cookies which broke a lot of these embeds because they can no longer set identity cookies that they rely on from within their iframe.

svieira 1y ago

As nwalters also points out, this isn't the same at all. System A and System A' both from Source Α are not the same as System A (Source Α) and System B (Source Β). Which you know, because you say "you can also use CORS to interact with a truly third party site". But now, I invite you to go the rest of the way - what if the third party site isn't Project Gutenburg but `goodreads.com/my-reading-lists`? That is, what if the information that you want to pull into System A from System B should only be available to you and not to anyone on the net?

cuu508 1y ago
Use OAuth2 to get system B's access token, then use authenticated server-to-server API requests to pull needed information from system B.
- namdnay 1y ago
  This multiplies the cost of the integration by at least an order of magnitude
- svieira 1y ago
  BINGO! The issue here of course is that now instead of _two_ components (Front End A and Embed B) you now have four (the back ends must communicate and if A didn't need a back end ... well, now it does). Now, if you meant "Use OAuth2 in the browser", that's just the original case (you can't authorize if you can't authenticate and it's the ambient authentication that's being stripped when you eliminate third party cookies).