I'm a cofounder of <a href="https://clerk.dev" rel="nofollow">https://clerk.dev</a> and we've found we need to keep a close eye on this ever-evolving world of browser security models.<p>I think what OP has glazed over a little bit, is that authentication is a massive, thorny exception to their advice of "adopt the Same Origin Policy instead."<p>Consider these authentication use cases:<p>- Sharing sessions across mail.google.com and drive.google.com<p>- Sharing sessions across google.com and youtube.com<p>- An okta.com generating a session on google.com<p>- Persisting a youtube.com session even when youtube.com is in an iframe on example.com<p>All of these scenarios are reasonable, but it's a huge challenge to support all of them in a privacy- and security-conscious way.<p>That being said, I generally agree with the advice of "adopt the Same Origin Policy instead" <i>after</i> authentication is solved.
Consider the following, you have a web app on one domain, and marketing materials on one or more other domains. Some of those marketing materials are hosted by a third party, or otherwise have less stringent security controls because the marketing pages don't have customer data. So you want to prevent some cookies, like the app authentication session cookie from being shared between the two sites (one reason for using different domains). As well as restricting the types of request marketing sites can make to the app.<p>However, there is also state that you <i>do</i> want to share between the sites, like whether the user is logged in or not to show different links on marketing pages, or tracking the marketing pages the user has seen to give recommendations once they get to the product, or measure the effectiveness of a/b tests or pages at leading to registrations.<p>If the domains are on seperate eTLDs, this is already a difficult situation, and will get even more difficult, possibly impossible with the disappearnce of third party cookies. If SOP was used for everything, it would make this difficult or impossible even if they were subdomains of the same eTLD+1.<p>If anyone know of a good solution to this, I'd love to hear about it.<p>The really annoying thing is that the server doesn't even need this shared state, but the SOP on localstorage and similar prevents using a local-only solution.
There's at least one proposed solution for this--replacing the public suffix list with first party sets:
<a href="https://github.com/privacycg/first-party-sets" rel="nofollow">https://github.com/privacycg/first-party-sets</a>