[Webkit-unassigned] [Bug 189952] Intelligent Tracking Prevention preventing BBC.co.uk sign in

Tue Sep 25 14:23:07 PDT 2018

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

--- Comment #2 from John Wilander <wilander at apple.com> ---
(In reply to marc.burrows from comment #0)
> Created attachment 350755 [details]
> Blank cookies
> 
> Hi,

Hi Marc, and thanks for your report! I have a couple of questions.

First, have you tested the flow and repro steps in Safari Technology Preview with ITP Debug Mode? That should tell you whether any of your domains are getting classified by ITP as having cross-site tracking abilities.

Documentation for ITP Debug Mode can be found here: https://webkit.org/blog/8387/itp-debug-mode-in-safari-technology-preview-62/

> This bug is following up on this discussion with John Willander on Twitter:
> https://twitter.com/Marc_Burrows/status/1043049662603841538
> 
> **Overview**
> Since the release of Safari 12 we have had lots of feedback from users that
> can no longer access the parts of the BBC website that require sign in. This
> is affecting by no means all users of Safari 12, and we are unable to
> recreate it in house.

Does this mean the steps below are not reproducing the issue on your machines/devices, only on your users'? If so, please leverage the ability to manually classify domains through ITP Debug Mode and see if the issue reproduces then.

> **Manifestation**
> We have seen a few machines with the issue, and it manifests itself in the
> following manner:
> - User has all the correct cookies set on bbc.co.uk
> - Three cookies, which are set whilst on session.bbc.co.uk for bbc.co.uk,
> but are blank and are now “session” cookies. I believe this is what is meant
> by the cookies having been “partitioned”. See screenshot.
> - Cookies on account.bbc.com and session.bbc.com seem to be set correctly
> 
> **Known Fixes**
> - Clear entire history

This resets ITP, i.e. no domains are classified as having cross-site tracking abilities anymore. From this point, ITP starts to learn again and will soon re-classify based on the user's browsing.

> - Go to account.bbc.com/account, quit Safari, open Safari, (maybe click sign
> in, can’t be sure) user appears signed in on bbc.co.uk
> 
> **FLOWS**
> 
> *Sign In*
> Our flow to get the majority of the users in the UK signed in is as follows:
> - User starts on https://www.bbc.co.uk
> - Clicks "Sign In"
> - User GETs to https://session.bbc.co.uk/session - no relevant cookies being
> set
> - User 302 redirects to https://account.bbc.com/authorise - no cookies being
> set
> - User 302 redirects to https://account.bbc.com/authoriseLogin - no relevant
> cookies being set
> - User 302 redirects to https://account.bbc.com/signin - no relevant cookies
> being set
> - User enters email & password, and clicks submit
> - User POSTs to https://account.bbc.com/signin - ckns_session, ckns_jwt
> being set on .account.bbc.com
> - User 302 redirects to https://account.bbc.com/authorise - no cookies being
> set
> - User 302 redirects to https://session.bbc.co.uk/session/callback -
> ckns_rtkn being set on .session.bbc.co.uk, and ckns_idtkn (SECURE),
> ckns_atkn (SECURE), ckns_stateless (NOT SECURE), ckns_id (NOT SECURE),
> ckpf_sylphid (NOT SECURE) being set on .bbc.co.uk
> - User 302 redirects back on https://www.bbc.co.uk and is signed in
> 
> *Normal Token Refresh when everything works*
> - User starts on https://www.bbc.co.uk and needs a token refresh
> - In iFrame - User goes to https://session.bbc.co.uk/session - no cookies
> being set
> - iFrame redirected to https://account.bbc.com - This checks if a cookie is
> set, but no cookies are being set
> - iFrame redirected back to https://session.bbc.co.uk/session -
> ckns_stateless, ckns_idtkn, ckns_atkn, ckns_id being set on .bbc.co.uk
> 
> *Stateful Token Refresh (Which is what we believe people are seeing because
> their cookies are blank)*
> - User starts on https://www.bbc.co.uk and clicks sign in
> - User GETs to https://session.bbc.co.uk/session - no relevant cookies being
> set
> - User 302 redirects to https://account.bbc.com/authorise - no cookies being
> set
> - User 302 redirects to https://session.bbc.co.uk/session/callback - no
> cookies being set
> - User 302 redirects to https://session.bbc.com/session/affinity - no
> cookies being set
> - User 302 redirects to https://session.bbc.co.uk/session/callback -
> ckns_rtkn being set on .session.bbc.co.uk, and ckns_idtkn (SECURE),
> ckns_atkn (SECURE), ckns_stateless (NOT SECURE), ckns_id (NOT SECURE),
> ckpf_sylphid (NOT SECURE) being set on .bbc.co.uk
> - User 302 redirects back on https://www.bbc.co.uk but does *NOT* appear
> signed in as ckns_stateless, ckpf_sylphid and most importantly ckns_id are
> blank and are session cookies.

For all of the steps and redirects you describe, it's always useful for us to know whether you are referring to the top frame or a sub frame. I think what you're saying with "User 302 redirects to" is that it's a navigational redirect in the top frame, i.e. the URL bar changes, but I don't know.

> **Questions**
> - Are we correct in that the three cookies on bbc.co.uk are being
> partitioned?

We can't tell without repro steps. But if a) the user has interacted with a webpage from bbc.com the last 30 days of Safari use and b) bbc.com has been classified as having cross-site tracking abilities, then bbc.com cookies will be partitioned (double-keyed) when bbc.com is third-party under some non-bbc.com webpage. And partitioned cookies automatically become session cookies.

> - What we don’t understand is why the three cookies on bbc.co.uk are blank
> (so are therefore set as tracking cookies?), because users are always
> interacting with pages on bbc.co.uk (within the UK). Is this due ITP?

I see your screenshot from the Web Inspector. However, what does your server see? Are these cookies seen on requests?

>     - Users are unlikely to regularly interact with pages on bbc.com, unless
> they wish to update something with their account.

If bbc.com is classified as having cross-site tracking abilities and the user doesn't interact with a webpage from bbc.com for 30 days of Safari use, all bbc.com website data, including cookies, is deleted.

> - Unless we are misunderstood, we don’t believe that the storage access API
> will resolve our issues, because this has nothing to do with embedding
> content from a different domain on our pages.

I do see you refer to an iframe from bbc.com under bbc.co.uk—"iFrame redirected to https://account.bbc.com"—which constitutes the exact scenario for when the Storage Access API can be called.

> - Let us know if you need more info on anything.

Please see if you can reproduce with ITP Debug Mode and manual setting of either bbc.com or bbc.co.uk as classified by ITP.

-- 
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/20180925/ce21794b/attachment-0001.html>