Questions regarding ITP 2.3 and CNAME subdomains

Question

Created Jul ’20

Replies 3

Boosts 0

Views 2.4k

Participants 3

Greetings,

I have questions regarding ITP 2.3 and CNAME subdomains.

Our portal offers interoperability between multiple health care platforms through an iframe. In the current situation, all of the parties that integrate with our platform host their applications via a DNS CNAME record that is owned by our shared customer (let's say: customer.com). This means our applications also use CNAMEs. As we all share the same parent domain, I'd expect Safari to not use ITP as they should be handled like first-party cookies.

ITP is blocking specific subdomains though. This is a simplified version of our current situation:

portal.customer.com CNAME portal.supplierA.com
app1.customer.com CNAME app.supplierA.com ✅
app2.customer.com CNAME app.supplierB.com ❌

In the above situation, application1.customer.com can be loaded in an iframe just fine (one of our own applications). However, when loading application2.customer.com in the iframe, ITP is triggered. It fails to set a session cookie even though it's a subdomain of customer.com. After disabling "Prevent cross-site tracking" it loads fine. It also works fine in Firefox with third-party blocking fully enabled (might be relevant as ITP is inspired by and derived from Mozilla’s anti tracking policy).

I tried to get more information on why the cookie gets blocked, but unfortunately the ITP debug mode doesn't show any logs on why the cookie is blocked.

So I'd love to know if ITP is expected to kick in for the above scenario. And if so, why? And are there any good documents on exactly when Safari handles a cookie as a third-party cookie?

As well, are there any suggestions on what to do when the ITP debug mode doesn't give any informative logs? I don't receive logs in the console nor in the kernel (log stream -info | grep ITPDebug).

Thanks in advance,
Joris

P.S. I understand that implementing the Storage Access API is the offered solution. But we currently choose this approach as we think the Storage Access API is quite disruptive UX-wise as there is no "always allow" option (yet?) and our users go to a lot of different hosts.

Boost

Answer 1

Systems Engineer OP

Apple

Jul ’20

So I'd love to know if ITP is expected to kick in for the above scenario. And if so, why? And are there any good documents on exactly when Safari handles a cookie as a third-party cookie?

It looks like you have read the recent WebKit Blog post regarding Full Third-Party Cookie Blocking and More, but specific to your situation take a look at the link in this post to RFC 6265 - 8.8.2. Top-level Navigations where it discusses SameSite scenarios to see if matches what you are seeing on your end.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 2

JScharp OP

Jul ’20

Hi Matt,

Thanks a lot for your quick reply!

The SameSite attribute is also provided by the supplier. This is their Set-Cookie statement:

Code Block set-cookie: PHPSESSID=<REMOVED>; path=/; secure; HttpOnly; SameSite=None

This seems quite alright, and looks like our working application (we even seem to be "double-secure"...):

Code Block Set-Cookie: SESSION=a88dfea2-46b7-440a-b185-8653473c575d; Path=/frontend/; Secure; HttpOnly; SameSite=None; Secure

So far I only see they use strange casing in the Set-Cookie header, but I assume that'd not cause this problem?

0

Answer 3

JScharp OP

Jul ’20

The secure flag is case-insensitive (https://tools.ietf.org/html/rfc6265#section-5.2.5), so this shouldn't be a problem.

Looking at Matt's answer, I assume the architecture of the subdomains, as shown in the initial question, should work. Is it possible to confirm this?

And if so, I struggle to find the next logical step to troubleshoot. Does anyone have suggestion on the latter?

Thanks in advance.

0