[Webkit-unassigned] [Bug 233330] New: ITP treating TLD+1 and TLD+2 matched domains as cross-site trackers.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Nov 18 12:54:54 PST 2021


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

            Bug ID: 233330
           Summary: ITP treating TLD+1 and TLD+2 matched domains as
                    cross-site trackers.
           Product: WebKit
           Version: Safari 14
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Critical
          Priority: P2
         Component: WebKit Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: lakshman.nittala at cerner.com

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

-- 
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/20211118/7f845305/attachment.htm>


More information about the webkit-unassigned mailing list