[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 #9 from John Wilander <wilander at apple.com> ---
(In reply to Sam Potts from comment #8)
> I understand the need to prevent unwanted tracking but it also doesn't
> provide a way for _legitimate_ access to third party cookies for
> applications like ours (see first comment). 

The challenge is how to distinguish “legitimate” from “non-legitimate”? First, many cross-site trackers consider their business legitimate. Second, many federated login services and SSO services are *also* tracking people’s activities across websites. Finally, how do be make sure cross-site trackers can’t disguise themselves as legitimate services? They’re willing to do almost anything including bug exploitation and reprogramming the behavior of first-party webpages on the fly.

> I have seen the prompt with copy along the lines of "x.com would like to
> access y.com cookies". It would be nice if there was a way to trigger access
> via this prompt without the need for an initial user gesture so at least
> they could elect out of it at the prompt.

First, many websites such as news sites load in the order of a hundred different third-party’s resources. We have to avoid them all prompting the user. Second, the prompt should be purposeful. Doing it at a distinct user action such as a gesture maximizes the chance of the user understanding why they’re being prompted and what the prompt means. Finally, automatic prompts without user activity is an anti patterns that is already hurting the web with constant prompts for e.g. permission to send notifications.

> It's the requirement for an
> initial user gesture  that makes it difficult. We'd have to iframe something
> from the third party over the whole page like a modal or dialog. Currently
> there's no easy around it other than "avoid Safari" for now.

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.

> How does the Storage Access API work with XHR requests if there's no
> <iframe> to interact with? I'm not referring to XHR within the iframe but an
> XHR on the parent page that makes requests to a third party.

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.

-- 
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/20200126/cf9dd562/attachment.htm>