Bug 196592 – Cookies not sent with third party requests via XHR or iFrame

• Status: NEW
• Component: Frames

[Sam Potts]

Since Safari 12 we're seeing some strange issues with XHR requests which is effecting our SSO solution. Here's the flow we're using:

- User visits `my.example1.com` and logs in. 
- User is then SSO'd to `example2.com`.
- `example2.com` will render a keep alive script that makes a client side request to `my.example1.com/path/to/page` either via XHR or a hidden `<iframe>` (with the required `sandbox` attribute properties) on every page load or periodically to keep the session alive and check that the user is authenticated; either by the resultant JSON in the XHR or a postMessage in the `<iframe>` method
- If user logs out of `my.example1.com`, they are logged out of `example2.com`

This was working great using XHR until Safari 12; then suddenly the auth cookies were no longer sent with this request so the user appeared to be unauthenticated. We then implemented a hidden `<iframe>` solution where it would hit a URL that would send a postMessage to the parent indicating if the user was authenticated. This seemed to work fine until a recent update of Safari in macOS 10.14.4 and now the `<iframe>` is rendered to the DOM but does not appear to load or make the request at all and thus no message is received by the parent. Chrome and Firefox still seem ok with the XHR method. 

Ideally we'd like to use the XHR solution for all browsers to keep things simple. 

We're at a loss and all we're getting is customer complaints as they are booted out of `example2.com` instantly after being redirected. At the moment we're just steering users away from Safari as a result. I really doubt this is an uncommon pattern.

[Radar WebKit Bug Importer]

<rdar://problem/49624423>

[Alex Christensen]

Could you give a link to a live site that reproduces this issue?  If you'd rather not post one here, feel free to email me one directly.

[Sam Potts]

Sorry, I should have included something in my original email. I'll try and get a POC available for this.

[John Wilander]

This is likely due to tracking prevention in Safari. If a third-party resource needs cookie access, you should call the Storage Access API. That API has been shipping in Safari for almost two years and is nowadays also available in Firefox with an Edge implementation pending. Brave has expressed interested in supporting the API once Edge has landed it in Chromium.

[John Wilander]

You can read blogposts on all the tracking prevention updates under the Privacy category on the WebKit blog: https://webkit.org/blog/category/privacy/

[Sam Potts]

The problem with using the Storage Access API is it requires a user gesture and we have an invisible frame/xhr request checking the users authentication status. It also has no mention of XHR or fetch requests. Until a more well thought out solution comes along we'll just have to continue to recommend that users avoid Safari for our application which is a shame.

[John Wilander]

(In reply to Sam Potts from comment #6)
> The problem with using the Storage Access API is it requires a user gesture
> and we have an invisible frame/xhr request checking the users authentication
> status. It also has no mention of XHR or fetch requests. Until a more well
> thought out solution comes along we'll just have to continue to recommend
> that users avoid Safari for our application which is a shame.

It’s intentional that it requires a user gesture. Otherwise all trackers and third-parties would just invisibly call it and we’d be back a square zero. We might as well not have the API at that point, right? I assume you mean some other restriction. Please share how you think this could keep the user in control, limit prompting to a the few third-parties that the user may be logged in to, while still preventing invisible cross-site tracking.

XHR/Fetch within the iframe get cookies if the third-party is granted access. If you’d prefer some other behavior, please explain your use case(s) in the discussion on standardization of the Storage Access API. It’s hopefully moving to the new W3C Privacy Community Group soon.

You should expect third-party cookies to be obsoleted fully across all mainstream browsers in less than two years. Chrome announced about two weeks ago they will disable them within two years.

[Sam Potts]

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). 

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. 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. 

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.

[John Wilander]

(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.

[Sam Potts]

(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.

[Dmitriy T]

(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 :/

[John Wilander]

(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!