{"id":77471,"date":"2025-02-09T08:01:32","date_gmt":"2025-02-09T08:01:32","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/itp-debug-mode-in-safari\/"},"modified":"2025-02-09T08:01:32","modified_gmt":"2025-02-09T08:01:32","slug":"itp-debug-mode-in-safari","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=77471","title":{"rendered":"ITP Debug Mode in Safari"},"content":{"rendered":"


\n<\/p>\n

\n

Intelligent Tracking Prevention<\/strong> is the name of the tracking prevention mechanism<\/a> implemented in WebKit and enabled in Safari and all major browsers running on the iOS platform<\/a>. I\u2019ve written about it on this blog<\/a>, and the CookieStatus.com<\/a> resource is something you should bookmark for further reading.<\/p>\n

The purpose of ITP is to prevent tracking tools\u2019 access to data stored and processed in the browser. This involves things like blocking all third-party cookies<\/strong> and restricting the lifetime of first-party cookies<\/strong>.<\/p>\n

\n

<\/p>\n

\"ITP<\/p>\n

<\/a><\/p>\n<\/div>\n

In this article, I want to show you how to use the ITP Debug Mode<\/strong>. It\u2019s a console logger<\/em> that outputs all the actions taken by Intelligent Tracking Prevention on the user\u2019s device or browser.<\/p>\n

A key thing to remember about ITP is that it\u2019s algorithmic<\/strong> and on-device<\/strong>. This means that the domains \u201cflagged\u201d by ITP as having tracking capabilities will change from one device to the next. This is why the ITP Debug Mode is so valuable – it\u2019s the only way to have insight into what ITP is actually doing on the current device.<\/p>\n

Safari did release the privacy report<\/a> feature a while back. However, it\u2019s designed to scare the user and not educate them. It uses misleading language which can lead to a critical misunderstanding<\/a> of how ITP actually works. I recommend treating the feature as nothing else but Safari self-promotion.<\/p>\n


\n X<\/span><\/p>\n

\n
\n The Simmer Newsletter<\/strong>\n <\/p>\n

\n Subscribe to the Simmer newsletter<\/a> to get the latest news and content from Simo Ahava into your email inbox!\n <\/p>\n

<\/span><\/p>\n

How to enable ITP Debug Mode in Safari<\/h2>\n

Unfortunately, ITP Debug Mode only works in the desktop<\/strong> version of Safari. Even if you tether your iOS device and use the web inspector tool to review what the iOS browser is doing, the debug logging doesn\u2019t reach this interface.<\/p>\n

To enable ITP Debug Mode in desktop Safari, you first need to reveal the Develop<\/strong> menu in the toolbar. To do this, click Safari<\/strong> -> Preferences<\/strong>, and open the Advanced<\/strong> tab.<\/p>\n

\n

<\/p>\n

\"Safari<\/p>\n

<\/a><\/p>\n<\/div>\n

Here, check the Show Develop menu in menu bar<\/strong>.<\/p>\n

\n

This is a good feature to keep enabled at all times – there\u2019s a lot of valuable insight to be gained through the developer tools of a browser.<\/p>\n<\/blockquote>\n

Next, in the new Develop menu, choose Enable Intelligent Tracking Prevention Debug Mode<\/strong>.<\/p>\n

\n

<\/p>\n

\"enable<\/p>\n

<\/a><\/p>\n<\/div>\n

Finally, from the same Develop menu, click Show JavaScript Console<\/strong> to open the console in the browser viewport.<\/p>\n

\n

<\/p>\n

\"JavaScript<\/p>\n

<\/a><\/p>\n<\/div>\n

If the option to show the console isn\u2019t available, you need to browse to a website first.<\/p>\n

Once the console is open, by browsing to a handful of websites you should start seeing ITP-related logging in the console.<\/p>\n

What is logged<\/h2>\n

The inventory of items logged into the console is pretty vast, and it\u2019s also quite poorly documented. Nevertheless, here are some of the debug messages you can expect to find.<\/p>\n\n\n\n\n\n\n\n\n\n
Debug message<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
Applying cross-site tracking restrictions to:<\/strong> [list_of_domains]<\/code><\/td>\nITP has flagged the listed domains as having cross-site tracking capabilities and has applied its restrictions to them.<\/td>\n<\/tr>\n
About to remove data records for:<\/strong> [list_of_domains]<\/code><\/td>\nIt has been more than 7 days since a meaningful interaction in first-party context with the listed domains, so Safari deletes either all stored data on these domains or all but cookies (if cookies were set with valid Set-Cookie<\/code> headers).<\/td>\n<\/tr>\n
Messages pertaining to the Storage Access API<\/a>.<\/td>\nThere are many debug messages about the Storage Access API, such as when access is granted, when access couldn\u2019t be granted, and when access was denied.<\/td>\n<\/tr>\n
Scheduled domain<\/code> to have its cookies set to SameSite=Strict.<\/strong><\/td>\nITP has detected that a domain is participating in bounce tracking<\/a> and has set its cookies to SameSite=Strict<\/code><\/a> as a consequence.<\/td>\n<\/tr>\n
Capped the expiry of third-party CNAME cloaked cookie named cookie_name<\/code>.<\/strong><\/td>\nIf CNAME cloaking<\/a> is detected, then cookies set with Set-Cookie<\/code> headers are set to expire 7 days.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

Domains flagged by ITP are reset by deleting the browser history<\/strong>. This nulls the list of domains flagged by ITP.<\/p>\n<\/blockquote>\n

Applying cross-site tracking restrictions to\u2026<\/h3>\n

This debug message means that ITP has flagged the domains in the list as having cross-site tracking capabilities. It doesn\u2019t mean they do<\/strong> cross-site tracking, but it means they have the capability<\/strong> to do it.<\/p>\n

To be listed among these domains typically requires that the domain be requested from enough unrelated sites using HTTP requests. For example, loading the same pixel from google-analytics.com<\/code> on three unrelated sites (e.g. sitea.com<\/code>, siteb.com<\/code>, and sitec.com<\/code>) will have ITP flag google-analytics.com<\/code> as a (potential) tracking domain.<\/p>\n

\n

<\/p>\n

\"Cross-site<\/p>\n

<\/a><\/p>\n<\/div>\n

The main impact of this is on first-party storage<\/strong>, as traffic from a flagged domain can result in first-party cookies being restricted to a lifetime of just 24 hours<\/a>. There is some impact on the referrer string<\/a> as well.<\/p>\n

Notably, Safari doesn\u2019t use ITP to block third-party cookies anymore. Instead, all third-party cookies<\/strong> are blocked without exception on Safari, and the site needs to use the Storage Access API<\/a> to gain access.<\/p>\n

About to remove data records for\u2026<\/h3>\n

Safari removes all script-writable storage (localStorage<\/code>, indexedDB<\/code> etc.) from a site if the site hasn\u2019t been interacted with in first-party context<\/strong> for the last 7 days.<\/p>\n

This means that the user has to actually visit the site and perform a meaningful interaction (e.g. click, scroll) to have the timer reset.<\/p>\n

JavaScript cookies can have their expiration reset with the document.cookie<\/code> API, but the maximum expiration is always enforced at 7 days by Safari.<\/p>\n

\n
\n

<\/p>\n

\"About<\/p>\n

<\/a><\/p>\n<\/div>\n<\/blockquote>\n

Safari also removes all website data<\/strong> (including cookies set with HTTP headers) if the domain has been classified by ITP AND if the domain hasn\u2019t been interacted with in first-party context in the last 30 days.<\/p>\n

\n

Thanks to Antoine Bourlon<\/a> for the clarification above.<\/p>\n<\/blockquote>\n

Storage Access API<\/h3>\n

Interactions with the Storage Access API<\/strong> have their own debug logging.<\/p>\n

\n

<\/p>\n

\"Storage<\/p>\n

<\/a><\/p>\n<\/div>\n

For example, when prompting for Storage Access, a message like this is shown if the embedded frame requests access to the parent page\u2019s storage:<\/p>\n

About to ask the user whether they want to grant storage access to sub_frame_domain<\/code> under top_frame_domain<\/code> or not.<\/strong><\/p>\n

Similarly, errors are output into the console as well.<\/p>\n

\n

<\/p>\n

\"Storage<\/p>\n

<\/a><\/p>\n<\/div>\n

Bounce tracking protection with a SameSite=Strict jail<\/h3>\n

This feature is special in that it\u2019s not currently implemented<\/em>, even though the protection mechanism exists.<\/p>\n

Based on this<\/a> article, the restriction has been created to cater to specific, listed domains that participate in such a scheme. Currently, the list is empty.<\/p>\n

The idea is that if bounce trackers<\/em> are detected, then domains to which the request is redirected are stripped of their capability to leverage cross-site cookies.<\/p>\n

It remains to be seen whether this gets more attention in the future. It\u2019s likely, considering how prevalent bounce tracking is<\/a>.<\/p>\n

CNAME cloaking mitigation<\/h3>\n

CNAME cloaking<\/strong> refers to a practice where a tracking domain is masked<\/em> behind a first-party domain owned by the site that wants to collect data for the tracker.<\/p>\n

For example, instead of a site sending data directly to https:\/\/www.tracker.com<\/code>, they proxy it through https:\/\/track.site.com<\/code>. This subdomain would actually be a CNAME record to www.tracker.com<\/code>.<\/p>\n

This has been a fairly popular way of overcoming ITP\u2019s restrictions on first-party cookies. However, with the recent versions of Safari and iOS\/iPadOS, WebKit has begun the task to invalidate this practice.<\/p>\n

\n

<\/p>\n

\"CNAME<\/p>\n

<\/a><\/p>\n<\/div>\n

\n

There\u2019s a bug in WebKit where the cookie name isn\u2019t exposed. A fix is forthcoming<\/a>.<\/p>\n<\/blockquote>\n

ITP Debug m\u00b4Mode will tell you if the current domain is trying to set cookies using a CNAME record to a cross-site origin, and whether it has taken appropriate action<\/a>.<\/p>\n

Summary<\/h2>\n

Intelligent Tracking Prevention is a complex machine, so getting familiar with the accompanying debug output is very useful if you want to know more about the inner workings of the mechanism.<\/p>\n

ITP is also constantly evolving, and the log output will be constantly updated to match the latest capabilities of WebKit\u2019s tracking preventions.<\/p>\n

Unfortunately, it\u2019s not currently possible to enable ITP Debug Mode for iOS Safari<\/strong> via USB tether, even if all other capabilities of the web inspector are at your disposal<\/a>. Hopefully, the mobile browser will have debugging capabilities at some point in the future, but based on discussions with WebKit engineers it doesn\u2019t seem likely in the short term.<\/p>\n

Let me know in the comments if you have questions about ITP Debug Mode or about ITP in general!<\/p>\n<\/p><\/div>\n