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

[bugzilla-daemon at webkit.org]

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

--- Comment #6 from John Wilander <wilander at apple.com> ---
(In reply to marc.burrows from comment #5)
> (In reply to John Wilander from comment #2)
> 
> Hi again John,
> 
> Soon after my last message I think we worked out what is happening. And it
> seems like it is related to the iFrame as you suggested. I forgot this part
> of our flows!

Good to hear that we're closer to understanding your users' issues.

> *We have this flow:*
> - User arrives on a bbc.co.uk page and is in need of a token refresh
> - The token refresh is done in an iFrame on a bbc.co.uk page, but in order
> to make sure that they are a valid user we do a redirect (in the iFrame) and
> make sure that a cookie exists on account.bbc.com
> - If that cookie doesn't exist, then we sign the user out
> - This redirects the user (in the iFrame) to a sign out end point on
> session.bbc.co.uk and updates the various cookies we use to check if the
> user is signed in, to a date in the past (to expire them)
> - The user is then redirected (in the iFrame) to the same sign out end
> point, but this time on session.bbc.com, the cookies on this domain which do
> the same as the above are then updated to a date in the past as well (to
> expire them).

Since bbc.com might be classified as having tracking abilities at this point, but the user *has* interacted with a webpage from bbc.com the last 30 days of Safari use, bbc.com's cookies in the iframe will be partitioned. If, as part of the sign-out redirect in the iframe, bbc.com sets any cookies, they will be in the partitioned state and only seen under first-party pages from bbc.co.uk.

Now, if you test this in recent versions of Safari Technology Preview, you will see a different behavior. We've done away with partitioned cookies all together, partly because of developers facing issues like what you're describing. Handling multiple cookie jars is hard. So with recent Safari Technology Preview you either have access to your regular cookies or you don't. This might make it hard for you to reproduce in Safari Technology Preview.

> *Questions on this flow:*
> - Does it seem like this flow would be affected by ITP because we are
> updating the cookies from a different domain, from within an iFrame?

Yes, as described above.

> - It looks like most of the cookies on bbc.co.uk and session.bbc.co.uk that
> we expire in this flow are blank and session cookies - hence we assume they
> are partitioned (please confirm). Does this sound like something ITP would
> do?

If bbc.co.uk is first-party in this context, cookies should not be partitioned.

> - If we are trying to expire cookies on bbc.com through an iFrame on a
> bbc.co.uk page, then should ITP:
> a) Partition the cookies on bbc.com
> b) Just not update (expire) the cookies
> c) Purge the cookies

None of the above. If bbc.com is classified, it cannot get to its cookies in an iframe under bbc.co.uk. Not even to delete them.


> - If we were to implement the Storage Access API do we need to request user
> interaction with bbc.com? In the docs here -
> https://webkit.org/blog/8124/introducing-storage-access-api/ - we can see
> that it says:
> "The iframe needs to be processing a user gesture at the time of the API
> call."

First, we're assuming that bbc.com has been classified by ITP.

Now, for bbc.com to get access to its cookies under bbc.co.uk, it has to call the Storage Access API. A successful call to the Storage Access API requires a user gesture in the bbc.com iframe under bbc.co.uk. Something like a login button. In the event handler of that tap or click, you can call the API.

Looking big picture, it might serve you better to do OAuth login from bbc.com to bbc.co.uk.

> But we do a background client side token refresh in the iFrame and it has no
> user interaction. Is there a suggested solution for this in our situation,
> because it seems like the examples require a user interaction (be it with a
> button or something else) and this is done in the background?

Because ITP is designed to prevent passive tracking, there is no way to passively or invisibly get access to cookies if the domain is classified and the resource is third-party. (This was already the case in ITP 1.0, release about a year ago.)

-- 
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/20180928/54378bfe/attachment-0001.html>