Bug 189045 - Recent change in ITP2 behaviour blocks 3rd party cookies
Summary: Recent change in ITP2 behaviour blocks 3rd party cookies
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: Safari Technology Preview
Hardware: Macintosh macOS 10.13
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-08-28 04:21 PDT by bugreporter0001
Modified: 2018-10-01 12:25 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bugreporter0001 2018-08-28 04:21:19 PDT
Since Release 62 of the Safari technology preview we have seen a change in ITP behaviour which causes 3rd party cookies to be purged rather than partitioned.

Visit Domain 1 with 3rd party cookies - 3rd party cookies there
Visit Domain 2 with 3rd party cookies - 3rd party cookies there
Visit Domain 3 with 3rd party cookies - 3rd party cookies purged from all 3 domains. 
Even after visiting the 3rd party domain in the 1st party context cookies continue to be purged (not expected behaviour from https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/)

On release 61 we can get cookies into a partitioned state as per the blog.

We cannot get 3rd party cookies into a partitioned state, only into a purged state (on Release 63)
Comment 1 Radar WebKit Bug Importer 2018-08-28 07:16:29 PDT
<rdar://problem/43796519>
Comment 2 John Wilander 2018-08-28 10:20:14 PDT
Partitioned cookies were removed here (motivations explained in the bug): https://bugs.webkit.org/show_bug.cgi?id=188109

With this change, being blocked in third-party contexts doesn't necessarily mean cookies and website data is purged though. If the domain has received user interaction the last 30 days of use, as first party or through successful use of the Storage Access API, its cookies are not purged.

Are you saying your domain's cookies are being purged even though your domain has received fresh user interaction?
Comment 3 John Wilander 2018-08-28 10:22:49 PDT
Clarification: Are you saying your domain's *first-party* cookies are being purged even though your domain has received fresh user interaction?
Comment 4 Christopher Walker 2018-08-29 03:04:06 PDT
Hello, I've been working on a concrete example to help explain what we mean here:

To help us illustrate this we've pulled together a few example URL's mentioned below:

* https://itp-example-tracker.site/ - Simple "tracker site" that sets a cookie named itpTestTracker to a random value if not set.
* https://itp-example1.site/ - Simple "consumer site" that loads an iframe of the above tracker site.

Reproduction steps:

* Enable ITP Debugging in Safari
* Use the following command to tail for debug output  log stream -info | grep ResourceLoadStatisticsDebug
* Launch Safari Technology Preview (with all cookies/history cleared)
* Visit https://itp-example-tracker.site/ and allow it to set the itpTestTracker cookie to a random value
* Visit https://itp-example1.site/, https://itp-example2.site/, https://itp-example3.site/ repeatedly until you trigger ITP, you can see until this point the cookies are present.
* Eventually you will be given the following log output: About to block cookies in third-party contexts for: itp-example-tracker.site.
* From here all cookies are purged and blocked for the tracker site when loaded in context of the consumer site
* Even if we interact with the tracker site again (by loading it and submitting a form) we are still unable to set new cookies _and view existing ones_ in context of the consumer.


This is having the effect that our consumer sites can no longer under any circumstances set or access cookies on the
Comment 5 Christopher Walker 2018-08-29 03:18:58 PDT
This is having the effect that our consumer sites can no longer under any circumstances set or access cookies on the tracker site.

Previous reply got truncated.
Comment 6 John Wilander 2018-08-29 10:32:58 PDT
Thank you. Let's drill into the details because I still think we misunderstand each other.

First, with the changes in https://bugs.webkit.org/show_bug.cgi?id=188109 there is no longer a connection between "blocked in third-party contexts" and "purged." Instead, these are the possible states for a domain that has been classified by ITP:

State 1) The domain *has not* received recent user interaction as first party or through successful use of the Storage Access API => cookies and website data is purged and new cookies are blocked in third party contexts.

State 2) The domain *has* received recent user interaction as first party or through successful use of the Storage Access API => cookies are blocked in third party contexts but no existing cookies and website data is purged.

Now, let's look at some of your bullet points.

(In reply to Christopher Walker from comment #4)
> To help us illustrate this we've pulled together a few example URL's
> mentioned below:
> 
> * https://itp-example-tracker.site/ - Simple "tracker site" that sets a
> cookie named itpTestTracker to a random value if not set.
> * https://itp-example1.site/ - Simple "consumer site" that loads an iframe
> of the above tracker site.
> 
> Reproduction steps:
> 
> * Enable ITP Debugging in Safari
> * Use the following command to tail for debug output  log stream -info |
> grep ResourceLoadStatisticsDebug
> * Launch Safari Technology Preview (with all cookies/history cleared)
> * Visit https://itp-example-tracker.site/ and allow it to set the
> itpTestTracker cookie to a random value

A mere visit does not count as user interaction. Do you mean that the user also interacts with the page?

> * Visit https://itp-example1.site/, https://itp-example2.site/,
> https://itp-example3.site/ repeatedly until you trigger ITP, you can see
> until this point the cookies are present.

Yes, cookies are available in third-party contexts as during the pre-ITP era until itp-example-tracker.site is classified.

> * Eventually you will be given the following log output: About to block
> cookies in third-party contexts for: itp-example-tracker.site.

Yes. This sounds correct.

> * From here all cookies are purged and blocked for the tracker site when
> loaded in context of the consumer site

If the user never interacted with itp-example-tracker.site as first party website, this is expected. The domain will be in State 1. And this was already the case with ITP 1.1.

However, if you say that itp-example-tracker.site should be in State 2, its cookies should not be purged. They are blocked in third-party contexts but not purged.

> * Even if we interact with the tracker site again (by loading it and
> submitting a form) we are still unable to set new cookies _and view existing
> ones_ in context of the consumer.

This is also correct. User interaction as first party or successful use of the Storage Access API only ensures that cookies and website data is not purged and that you can keep using the Storage Access API.

> This is having the effect that our consumer sites can no longer under any
> circumstances set or access cookies on the

Not true unless you mean all cookies are purged (State 1). In State 2 your domain can get access to its cookies by using the Storage Access API on "customer sites." That is the model we support.

Given the explanation above, are you seeing a different behavior?
Comment 7 Christopher Walker 2018-08-29 12:08:28 PDT
Hi John I think that helps somewhat, unfortunately as we are split timezone wise (we are located in the UK) I need to discuss this fully with my team to ensure it's what we expect but I will try and pass over a few queries we had from today;

One question is when is the plan for this functionality becoming part of the Safari main build? We've verified our functionality works on Safari 12.0 Beta, however under the Tech Preview our site has some issues we need to plan for it would be good to know a rough time it was being released.
 
Another is it would be ideal if these changes were communicated via a blog post or ideally a specification document.
Comment 8 John Wilander 2018-08-29 12:40:29 PDT
(In reply to Christopher Walker from comment #7)
> Hi John I think that helps somewhat, unfortunately as we are split timezone
> wise (we are located in the UK) I need to discuss this fully with my team to
> ensure it's what we expect but I will try and pass over a few queries we had
> from today;

Sounds good.

> One question is when is the plan for this functionality becoming part of the
> Safari main build? We've verified our functionality works on Safari 12.0
> Beta, however under the Tech Preview our site has some issues we need to
> plan for it would be good to know a rough time it was being released.

We never comment on when or even if something will be released. If you want to get a feel for it based on history, I suggest you looked at when we've blogged about major updates related to ITP.

Safari Technology Preview is exactly what it says, a technology preview. With it, developer get to test out changes before they go into beta of our regular releases.

> Another is it would be ideal if these changes were communicated via a blog
> post or ideally a specification document.

If we release a Safari with these changes, I'm sure we'll blog about them, just like we have previously.

Regarding a specification, we'd love for cross-site tracking to be a solved problem we can put in a spec and move on to other engineering efforts. But we have to constantly monitor what trackers are doing and make adjustments to how ITP works.
Comment 9 Christopher Walker 2018-08-29 14:48:07 PDT
Thanks for cleaning up the release process John, this is very helpful info. And with regards to the lack of spec I understand it's a constantly moving target, it would just be nice if these details could be expressed more formally rather than blog posts (but thanks for the reply).
Comment 10 John Wilander 2018-10-01 12:25:39 PDT
This works as intended. Motivations explained in the bug: https://bugs.webkit.org/show_bug.cgi?id=188109