[Webkit-unassigned] [Bug 196592] Cookies not sent with third party requests via XHR or iFrame

[bugzilla-daemon at webkit.org]

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

--- Comment #12 from John Wilander <wilander at apple.com> ---
(In reply to Dmitriy T from comment #11)
> (In reply to Sam Potts from comment #10)
> > So there's no way to enable cookies being sent to third parties for XHR
> > requests since the Storage Access API only effects iframes? Safari seem to
> > block them.
> 
> I have the same question, as I'm seeing the same behavior that is crippling
> our app and we have to turn away Safari users too. Oauth is not an option
> for us right now, and previous workarounds no longer work in Safari 13.1
> with full blocking of third party cookies. Not getting any luck with Storage
> Access API either :/

(In reply to Sam Potts from comment #10)
> (In reply to John Wilander from comment #9)
> > The challenge is how to distinguish “legitimate” from “non-legitimate”?
> 
> It's a very good point and as you know, hard to determine. 
> 
> > You of course have the two other options too. Either Oauth with auth tokens
> > in the incoming URL or the temporary compatibility fix for popups as
> > described in our ITP 2.0 and 2.1 blogposts.
> 
> I guess we'll have to look into those options. 
> 
> > Our implementation is frame specific, i.e. only resources in the iframe that
> > got granted access will have cookies. If you have compelling reasons for why
> > that can’t work for you, please file an issue as mentioned above.
> 
> So there's no way to enable cookies being sent to third parties for XHR
> requests since the Storage Access API only effects iframes? Safari seem to
> block them.

Only third-party iframes can be granted storage access. We are working on standardizing the Storage Access API and actively welcome developer feedback.

If you have time, please consider reading the explainer https://github.com/privacycg/storage-access/blob/master/README.md and then filing an issue at https://github.com/privacycg/storage-access/issues explaining your use case and why you think the current behavior or scoping of the Storage Access API cannot work for you. The reason why I recommend reading the explainer first is that many questions are already answered in there and it'll be easier for you to frame your question or issue if you know the background. Thanks!

-- 
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/20200409/a94e85ec/attachment-0001.htm>