Bug 173844 – Intelligent Tracking Prevention removes first party cookie on iOS11 beta v2, not on macOS beta v2

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit Misc.

[Kirk Elliott]

ITP = Intelligent Tracking Prevention

@johnwilander asked me to mention him here https://twitter.com/johnwilander/status/879404760473808896

I'm presenting a perceived bug and a follow up question in iOS11 beta v2, and an contrasting observation about ITP behavior in macOS HighSierra beta v2:

WHERE client.com is a first-party loaded domain which loads an iframe with src=tools.com that reads tools.com cookie 
AND the tools.com cookie value is a unique uid (XXX e.g. 001)
AND after tools.com has been visited first-party, setting the cookie

In iOS11 it appears that when ITP "kicks in", or shortly thereafter, that the first party tools.com cookie is removed until the next time it is visited and set. The "bug" is that there is a point in time where the uid is expected but missing. So tools.com has a period where its first-party uid cookie is missing, then afterwards the value is different than its original version.

After setting tools.com cookie again (after ITP is invoked), what I imagine to be "normal" ITP behavior starts. That is, after revisiting tools.com and setting a cookie, client.com sets a new cookie for tools.com different from the previous tools.com value and also different from the new tools.com value. The "question" is: Is this "normal" ITP behavior?

Additionally running the same test in macOS I am having trouble getting ITP to "kick in", even with many client.com-similar domains loading the tools.com cookie.

[Radar WebKit Bug Importer]

<rdar://problem/33010320>

[John Wilander]

Thanks for the report, Kirk!

It's a little hard for me to follow all the steps and what you expect to happen. This is how I interpret your scenario:

1. At some point tools.com has been visited as a first-party and set a cookie. Let's call that cookie firstPartyToolsCookie.

2. At some point ITP has decided that tools.com has the ability to track the user.

3. The user visits client.com which has an iframe from tools.com.

Am I correct so far? If so, let's look at what happens with ITP enabled.


Scenario A – the user *has* interacted with tools.com the last 24 hours

4. The tools.com iframe will see firstPartyToolsCookie.

5. No cookies are purged.


Scenario B – the user *has* interacted with tools.com the last 30 days but not the last 24 hours

4. The cookies for the tools.com iframe are partitioned. This means that it will not see firstPartyToolsCookie but instead be able to set and see thirdPartyUnderClientToolsCookie.

5. No cookies are purged.


Scenario C – the user *has not* interacted with tools.com the last 30 days

4. The cookies for the tools.com iframe are partitioned. This means that it will not see firstPartyToolsCookie but instead be able to set and see thirdPartyUnderClientToolsCookie.

5. At some point, both firstPartyToolsCookie and thirdPartyUnderClientToolsCookie will be purged. The reason this point is not known is that we don't want to scan website data records all the time because of performance.


Given the above, can you answer these three things for me, please:

First, are you sure tools.com has been classified as having the ability to track the user on both your iOS and macOS devices?

Second, have you interacted with tools.com on any of your two devices, i.e. clicked, tapped, filled out a form on tools.com? Was it the last 24 hours or the last 30 days?

Third, what is the issue you are seeing using the examples firstPartyToolsCookie and thirdPartyUnderClientToolsCookie?

[Kirk Elliott]

Thanks for your patience, it is a little complicated to explain but you have done a great job here. Your assumptions for 1,2,3 are correct. I have also received some additional information from Jonathan Davis which has given me a better understanding of how "interacting" with a page affects ITP than what I got from the blog post.

I believe all my questions are answered wrt iOS ITP behavior, and I have a good grasp of what "normal" ITP behavior is. You provide an excellent breakdown here as well. 

My main question now is how to reproduce on macOS, as on iOS changing the date appears to do the trick but on macOS the date switching doesn't appear to be as reliable. I cannot reproduce on macOS HS beta v2 but I think I could before in v1. 

The bugs I would mention include:
1a. iOS 11 beta 2 does not really clear cookies when I choose Clear History and Website Data. In iOS10 the blue button text would turn grey after this operation, not so in iOS11 beta v2. 

1b. In my testing the cookies do not appear in Safari > Advanced > Website Data (says 0 bytes), but if I tap clear cookies and visit firstPartyDomain I can still see the thirdPartyCookie value in the iframe (in my test the random-ish int is visible when available). I expect it to not be available but it's the same value from before clearing cookies. This is very easy to reproduce. I've been resetting cookies by wiping my test device for every test, takes about 3 min. per restore. 

1a - button doesnt turn grey
1b - cookies are still somehow present (maybe its just cache invalidation)


2. I also see a bug in macOS, not new to HS, where automatically setting the date doesn't work (it never changes the date back after I have changed it ahead). Maybe it is some weird proxy/network/firewall/etc hosts issue, but I think I have seen this on multiple networks.

2 - https://twitter.com/dmvjs/status/878256107524939776

That being said I have not been able to reproduce the issue on macOS since beta v2. Wiping macOS is a bit more impractical so for now I am simply trusting that it will behave the same as on iOS.

[John Wilander]

Thanks for these additional explanations, Kirk!

Am I correct in that you are not seeing the original bug in beta 2? By original I mean "Intelligent Tracking Prevention removes first party cookie on iOS11 beta v2, not on macOS beta v2".

Are you saying you instead see a bug where website data removal isn't working properly on iOS? If so, is it specific to partitioned cookies? That would mean firstPartyToolsCookie is deleted when you remove website data but thirdPartyUnderClientToolsCookie is not.

One more detail — where are you removing history/website data on iOS? In Settings–>Safari or inside the Safari app itself? (Both are possible.) Thanks!

[Kirk Elliott]

1. I still cannot reproduce ITP on macOS, so for me at least, the title bug still stands. I defer to your interpretation if you want to close this issue or port/change the title. I'm sorry this has gotten fragmented and I am discussing multiple "bugs" here. I'm certain that this is out of protocol for bug reporting.

2. Both firstPartyToolsCookie and thirdPartyUnderClientToolsCookie are visible after "clearing" cookies.

3. Settings > Safari > Clear History and Website Data 

How else can cookies be cleared?

[John Wilander]

(In reply to Kirk Elliott from comment #5)
> 1. I still cannot reproduce ITP on macOS, so for me at least, the title bug
> still stands. I defer to your interpretation if you want to close this issue
> or port/change the title.

I believe what you're saying is that it *does* reproduce on macOS, i.e. the bug that ITP does not purge first-party cookies on macOS High Sierra beta 2 does reproduce for you. True?

> I'm sorry this has gotten fragmented and I am
> discussing multiple "bugs" here. I'm certain that this is out of protocol
> for bug reporting.

No worries.

> 2. Both firstPartyToolsCookie and thirdPartyUnderClientToolsCookie are
> visible after "clearing" cookies.

We have a radar tracking this issue but thanks for reporting it.

> 3. Settings > Safari > Clear History and Website Data 
> 
> How else can cookies be cleared?

On iOS you can clear all history inside Safari. Go to History and tap the clock icon.

[Kirk Elliott]

I believe what you're saying is that it *does* reproduce on macOS, i.e. the bug that ITP does not purge first-party cookies on macOS High Sierra beta 2 does reproduce for you. True?

You are correct, I got my wires crossed. True.

[John Wilander]

(In reply to Kirk Elliott from comment #7)
> I believe what you're saying is that it *does* reproduce on macOS, i.e. the
> bug that ITP does not purge first-party cookies on macOS High Sierra beta 2
> does reproduce for you. True?
> 
> You are correct, I got my wires crossed. True.

I'm having trouble reproducing this.

Do you have a website where this happens for you? Or a controlled test case I can set up? If you just tell me which domains should be have been classified as having the ability to track the user before I run the test I can get it set up just so.

Thanks!

[Kirk Elliott]

I was hoping to get confirmation that using the date picker in macOS should work to skip ahead 24 hours for this test. Is this how you test the ITP kicking in? I've also waited a day and that doesn't seem to work to kick in ITP either.

http://www.cappinkirk.com/links.html

Where the red buttons are the tools (aka third party) and blue buttons are clients.

My iOS tests are conducted by: 

1. visit page, set from red button
2. read from a couple blue "read" buttons to verify same uid
3. set date ahead 24 hours
4. read a few times from blue buttons until cookie is gone
5. verify that red read cookie is gone
6. set from red button again (now scoped to just third-party-as-first-party)
7. read from blue buttons, no value until setting from each blue button

This is terse, but if you've followed along so far hopefully I'm not losing you here.

[John Wilander]

I'm testing on a recent revision of WebKit and doing this:

(0. No interaction with dmvjs.com the last 30 days.)
1. Navigate to http://www.dmvjs.com/readCookie.html to check that there is no cookie to start with. I do not interact with the page.
2. Navigate to http://www.dmvjs.com/writeCookie.html to get a first-party cookie set for dmvjs.com. Again, I do not interact with the page.
3. Navigate to http://www.cappinkirk.com/readCookie.html, http://www.outputtranslation.com/readCookie.html, http://www.jerryscreativeconcrete.com/readCookie.html, http://www.stringtool.com/readCookie.html, and http://www.djtopspeed.com/readCookie.html to make sure dmvjs.com gets classified as having the ability to track the user.
4. Wait a while until ITP decides to scan and purge website data records. During this time I just browse one or two webpages.

After that, dmvjs.com's first-party cookie is purged for me.

Following the same steps, is the cookie not purged for you?

[Kirk Elliott]

It works on macOS. This is different than what I was doing before and I was tripping over the date changing bit when that actually doesn't matter at all.  

Thanks, no bug here.

[John Wilander]

Thank you for working this through with me. And don't hesitate to file a new bug if you see unexpected behavior.

@johnwilander Is there a link for the cookie clearing report that I can follow? Thanks.

[John Wilander]

(In reply to ahmed from comment #13)
> @johnwilander Is there a link for the cookie clearing report that I can
> follow? Thanks.

I'm not sure what you mean with "cookie clearing report." Something we referenced above?

Yeah. I am referring to "we have a radar tracking this issue but thanks for reporting it." from comment #6 https://bugs.webkit.org/show_bug.cgi?id=173844#c6