[Webkit-unassigned] [Bug 198181] Cookies with SameSite=None or SameSite=invalid treated as Strict

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=198181

--- Comment #46 from John Wilander <wilander at apple.com> ---
(In reply to Andra Ruebsteck from comment #45)
> (In reply to John Wilander from comment #44)
> > (In reply to ChristianV from comment #43)
> > > Does it mean that SPA Applications calling third-party APIs (with proper
> > > CORS set-up) that rely on cookies to properly work are broken ?
> > > Something like the drawing to give you an idea.
> > > 
> > > 
> > >   abc.com                                                   api.net
> > >                                                            +---------------+
> > > +----------+                                               |               |
> > > |          |  (Ajax Requesto to API)                       |               |
> > > |          | +------------------------------------------>  |               |
> > > |          |  origin: abc.com                              |               |
> > > |          |                                               |               |
> > > |          |  (API Response with Cookie)                   |               |
> > > |          | <-------------------------------------------+ |               |
> > > |          | Access|Control|Allow|Credentials: true        |               |
> > > |          | Access-Control-Allow-Origin: https://abc.com  |               |
> > > |          | Cookie: myCookie ; domain=api.net             |               |
> > > +----------+                                               +---------------+
> > 
> > Hi! The scenario you are describing has never been supported under Safari’s
> > default cookie policy. Between 2003 and 2017, api.net would have to be
> > visited as first party website and set cookies as such before it could use
> > cookies as third party.
> > 
> > Between 2017 and March 2020, if api.net was used under multiple different
> > websites, it would be blocked from third-party cookies even if it had been
> > visited as first party website.
> > 
> > As of March 2020, all third party cookies are blocked unconditionally and
> > the third party needs to call the Storage Access API to ask for the user’s
> > permission to use cookies.
> 
> We have a very similar case as ChrisitanV:
> 
>   abc.com                                                     api.net
> +----------+                                                
> +---------------+
> |          |  Redirect to login page                         |              
> |
> |          | +---------------------------------------------> |              
> |
> |          |                                                 |              
> |
> |          |  Redirect back with Cookie                      |              
> |
> |          | <---------------------------------------------+ |              
> |
> |          |   Location: https://abc.com                     |              
> |
> |          |   Cookie: myCookie ; domain=api.net             |              
> |
> |          |                                                 |              
> |
> |          |  (Ajax Requesto to API to check login status)   |              
> |
> |          | +---------------------------------------------> |              
> |
> |          |  origin: abc.com                                |              
> |
> |          |  Cookie: myCookie                               |              
> |
> +----------+                                                
> +---------------+
> 
> Obviously the cookie on the Ajax request is not actually sent to the server
> under the Intelligent Tracking Prevention.
> 
> How can the Storage Access API be used in this case? As I understand it can
> only be used by content in iFrames
> (https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API)

There needs to be an iframe from api.net under abc.com calling the Storage Access API upon a user gesture in the iframe and the user must have previously interacted with api.net as first party (doesn’t seem like an issue for you since api.net in your case is somewhere where the user logs in) and api.net must have existing cookies.

The Storage Access API is meant for *authenticated embeds*, i.e. embedded cross-site content that needs to authenticate an already logged in user.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201009/65bd2df4/attachment-0001.htm>