[HN Gopher] Public Suffix List Problems (2019)
       ___________________________________________________________________
        
       Public Suffix List Problems (2019)
        
       Author : aleyan
       Score  : 37 points
       Date   : 2021-07-16 04:06 UTC (1 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | dang wrote:
       | 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
        
       | theamk wrote:
       | Needs [2019] in the title
        
         | bruce343434 wrote:
         | Why? Is it outdated?
        
           | dang wrote:
           | 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 wrote:
       | Just use WebSockets, they ignore the same origin policy anyway!
        
       | IX-103 wrote:
       | 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
        
       | colinclerk wrote:
       | 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.
        
         | methyl wrote:
         | 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 wrote:
           | 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.
        
       ___________________________________________________________________
       (page generated 2021-07-17 23:02 UTC)