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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Sep 25 15:54:16 PDT 2018


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

--- Comment #3 from marc.burrows at bbc.co.uk ---
Hi John,

Thanks for the quick response. 

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

Yes we've tried this out, but after quite a long time of browsing we can't recreate the issue that users are seeing. We believe this issue is only happening to around 5% of Safari 12 users (although that is still potentially of thousands of people!). See below for the details.

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

Correct - this will happen in the top frame.

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

The issue here is that on the two machines we have seen the issue (which unfortunately resolved themselves using the two known fixes), we didn't see any of the cookies on bbc.com being purged at all. If they go to any page on bbc.com, then they appeared signed in. However, on bbc.co.uk they do not, as the the main cookie which we use to see if they are signed in - ckns_id - is blank. This is despite bbc.co.uk being the domain that users will interact with the most. This is the part which doesn't seem to make sense to us!

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

As per above, if the cookies on bbc.com were being partitioned, then it would make a bit more sense to us, but for cookies on bbc.co.uk to be partitioned seems strange.

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

The cookies are seen on the server requests, but are blank. We have implemented some logging to see when people come to us with a blank ckns_id as we extract its value in several places throughout our code. This is how we can see how many people are affected by the issue.

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

So this redirect to account.bbc.com can happen in an iFrame, but it doesn't always do so. The redirect is simply checking if a cookie exists or not on account.bbc.com, and never sets anything. During this particular flow, cookies are only ever set on bbc.co.uk or session.bbc.co.uk, as this is the domain that the user is interacting with. Maybe I've misunderstood, but requesting storage access for the domain that the user is already on (in this case bbc.co.uk) doesn't seem like it should be necessary?

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

When setting only bbc.com as classified by ITP on a brand new web session (history has been cleared):
- I can sign in and have no issues at all.
- However, when I land and then click anywhere on the account.bbc.com/signin page (to sign in), the debugger does say "About to block cookies in third-party contexts for: bbc.co.uk." and then "Done updating cookie blocking". But this doesn't seem to prevent any cookies that we expect to be set from being set properly (on either .com or .co.uk).  
- I also removed some of the cookies on .co.uk, refreshed the page so the browser thinks I'm signed out, and force a token refresh by clicking "sign in", and it will eventually bring me back to where I was, and show me as signed in without having to enter my credentials at any point - which is correct.

When setting only bbc.co.uk as classified by ITP on a brand new web session:
- Exactly the same behaviour occurs as when blocking bbc.com apart from the other way round with the debugger saying "About to block cookies in third-party contexts for: bbc.com" when interacting with a bbc.co.uk page post sign in. Prior to sign in I browsed numerous pages and this never happened.
- However, I still remain signed in at all times, and the cookies on either domain are never purged or modified to be session cookies and blank.

When not setting any domains as classified by ITP, we are yet to see either bbc.com or bbc.co.uk ever appear in the debugger as "about to be blocked".

Thank you for your help so far!

-- 
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/db6791a7/attachment.html>


More information about the webkit-unassigned mailing list