Bug 233330 - ITP treating TLD+1 and TLD+2 matched domains as cross-site trackers.
Summary: ITP treating TLD+1 and TLD+2 matched domains as cross-site trackers.
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: Safari 15
Hardware: Unspecified Unspecified
: P2 Critical
Assignee: John Wilander
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-11-18 12:54 PST by Lakshman
Modified: 2021-12-06 16:57 PST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lakshman 2021-11-18 12:54:54 PST
We are looking for additional guidance as to rules around ITP tracking, as we have TLD+2 domains that are being identified as cross-site trackers.

 Our single-page application has content with embedded sites as iframes. The iframe URL matches the host domain up to TLD+2. The iframe is utilizing cookies for authentication. However, the ITP is treating the iframe as a third-party tracker. As a result, the iframes are not allowed to authenticate, which prohibits the end-user from seeing the content. 

We are certain that this is a cross-site tracking issue as when "Intelligent Tracking Debug Mode is Enabled, our sites are flagged"

we have seen issues in the below scenarios where iframe URLs always match the host domain up to TLD+2.

URLs like <extra_string>.<string1>.<string2>.com trying to write a cookie to <string1>.<string2>.com breaks

URLs which has repeated strings like <extra_string>.<string>.<string>.com trying to write a cookie to <string>.<string>.com.
If we consider news.example.com as a first-party, the URLs matching even up to TLD+2 like sub.news.example.com are treated as the third party causing the iframes to break. Below are some examples that we are seeing where it fails for some and works for some:

First party - news.example.com

Treated as a third party - news.news.example.com (has repeated string in the URL) - Always fails
Treated as a third party - sub.news.example.com (has an extra string) - Works sometimes/fails sometimes
Comment 1 John Wilander 2021-11-19 07:31:05 PST
Hi! Thanks for filing. ITP does not block cookies for same-site, cross-origin content. However, it does make use of the Public Suffix List to find out what the sites or registrable domains are.

It’ll be easier to investigate if you share an example of the top frame’s host name (full domain with subdomains) and the iframe’s host name.
Comment 2 Lakshman 2021-11-19 07:53:12 PST
Hi John, Thanks for the response. Below are the examples of the URLs:

patientportal.patientportal.example.com accessing patientportal.example.com failed

patientportal.differentpath.example.com accessing differentpath.example.com failed sometimes and worked sometimes.
Comment 3 John Wilander 2021-11-19 08:17:50 PST
(In reply to Lakshman from comment #2)
> Hi John, Thanks for the response. Below are the examples of the URLs:
> 
> patientportal.patientportal.example.com accessing patientportal.example.com
> failed
> 
> patientportal.differentpath.example.com accessing differentpath.example.com
> failed sometimes and worked sometimes.

Have you tested with those exact URLs, i.e. with *.example.com, or are you using example.com as a placeholder for the real domain that goes there? I'm asking because of the Public Suffix List (https://publicsuffix.org/list/public_suffix_list.dat) and the possibility that what you have in place of example.com is on that list.

Also, can you share these details on the cookies that are being blocked:
1. How are you accessing the cookies – in HTTP requests or through document.cookie?
2. Are all cookies or just some cookies being blocked at any one time?
3. How are the cookies configured? I'm thinking of attributes such as secure, domain, path, and SameSite.
4. Are there any redirects involved when you load the resources where cookies are blocked? I'm especially interested in any redirects to different registrable domains.

Thanks!
Comment 4 Radar WebKit Bug Importer 2021-11-25 12:55:23 PST
<rdar://problem/85754160>
Comment 5 Lakshman 2021-12-01 06:57:40 PST
Have you tested with those exact URLs, i.e. with *.example.com?
example.com is a placeholder. We mainly create .org sites.

1. How are you accessing the cookies – in HTTP requests or through document.cookie?
We retrieve cookies in server sites requests.

2. Are all cookies or just some cookies being blocked at any one time?
We were unable observe this on our tld+2 failures (the sites have since been updated to working domains), but for the case where the domains do not match, no cookies are applied. As our authentication should be the first thing the iframed site does, I would expect that the tld+2 failures would behave the same.

3. How are the cookies configured? I'm thinking of attributes such as secure, domain, path, and SameSite.
Our cookies include
Domain: .<tld+1>
Path: /
Secure: Yes
HTTP Only: Yes
Same Site: None

4. Are there any redirects involved when you load the resources where cookies are blocked? I'm especially interested in any redirects to different registrable domains.
Our authorization checks for a cookie with a matching tld+1 domain (mentioned above). If that cookie is not present, it will redirect to an IDP with a different domain. However, we should not expect to hit this workflow for successful iframe authentication.

This would not be so odd if it was failing universally, for all of our .org urls. The fact that we can modify a +2 or +3 url component and have it work seems like there are other rules around the cookie blocking that we have been unable to identify.
Comment 6 John Wilander 2021-12-06 16:57:39 PST
I'm adding basic tests for these kind of duplicate sub domains in https://bugs.webkit.org/show_bug.cgi?id=233902. The logic in WebCore::RegistrableDomain seems to do the right thing. Would it be possible for you to provide a reproducible test case with domains you control? Thanks!