4 ms·

Public Suffix List Problems (2019)

40 points by aleyan 5y ago

theamk 5y ago
Needs [2019] in the title
- bruce343434 5y ago
  Why? Is it outdated?
  - dang 5y ago
    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.
twic 5y ago
Just use WebSockets, they ignore the same origin policy anyway!
colinclerk 5y ago
I'm a cofounder of https://clerk.dev 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.
- methyl 5y ago
  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.
  - IX-103 5y ago
    Yes, that's a known problem. The only proposed solution I've seen so far is Fenced Frames (https://github.com/shivanigithub/fenced-frame 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.
    - thayne 5y ago
      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.
IX-103 5y ago
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 https://github.com/privacycg/first-party-sets
dang 5y ago
Recent and related: Public Suffix List - https://news.ycombinator.com/item?id=27835197 https://news.ycombinator.com/item?id=27835197 - July 2021 (43 comments) Other threads listed at https://news.ycombinator.com/item?id=27853498 https://news.ycombinator.com/item?id=27853498
thayne 5y ago
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.

40 points by aleyan 5y ago

theamk 5y ago

Needs [2019] in the title

bruce343434 5y ago
Why? Is it outdated?
- dang 5y ago
  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.

twic 5y ago

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

colinclerk 5y ago

I'm a cofounder of https://clerk.dev 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.

methyl 5y ago
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.
- IX-103 5y ago
  Yes, that's a known problem. The only proposed solution I've seen so far is Fenced Frames (https://github.com/shivanigithub/fenced-frame 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.
  - thayne 5y ago
    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.

IX-103 5y ago

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

dang 5y ago

Recent and related: Public Suffix List - https://news.ycombinator.com/item?id=27835197 https://news.ycombinator.com/item?id=27835197 - July 2021 (43 comments) Other threads listed at https://news.ycombinator.com/item?id=27853498 https://news.ycombinator.com/item?id=27853498

thayne 5y ago

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.