Public Suffix List Problems (2019) | Hacker News Reader

Public Suffix List Problems (2019)

github.com

40 pointsaleyan11 comments

I'm a cofounder of https://clerk.dev and we've found we need to keep a close eye on this ever-evolving world of browser security models.

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."

Consider these authentication use cases:

- Sharing sessions across mail.google.com and drive.google.com

- Sharing sessions across google.com and youtube.com

- An okta.com generating a session on google.com

- Persisting a youtube.com session even when youtube.com is in an iframe on example.com

All of these scenarios are reasonable, but it's a huge challenge to support all of them in a privacy- and security-conscious way.

That being said, I generally agree with the advice of "adopt the Same Origin Policy instead" after authentication is solved.

Authentication is a huge problem for us, as we integrate with other platforms via an iframe. When people disable 3rd party cookies, it's impossible to authenticate users between two unrelated domains. And there is no alternative I'm aware of.

Yes, that's a known problem. The only proposed solution I've seen so far is Fenced Frames (https://github.com/shivanigithub/fenced-frame).

I don't know if that would even work in your use case, as it's still very limited.

From what I can tell, the fenced frames wouldn't work for certain kinds of integrations, where the iframe needs to both communicate with the host page via an integration api and be authenticated for its own domain.

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.

However, there is also state that you do 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.

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.

If anyone know of a good solution to this, I'd love to hear about it.

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: https://github.com/privacycg/first-party-sets

Recent and related:

Public Suffix List - https://news.ycombinator.com/item?id=27835197 - July 2021 (43 comments)

Other threads listed at https://news.ycombinator.com/item?id=27853498

Needs [2019] in the title

Why? Is it outdated?

It's the convention on HN to add the year to a title when the article isn't from this year. It doesn't imply that the content is false. If someone posted Euclid we'd probably put "300 BC" on it.

Just use WebSockets, they ignore the same origin policy anyway!

Reply on news.ycombinator.com