Tech: Unearthing a Potential Safari 17 Anomaly: Service Worker and ITP Conflict

Discovery of a potential, undocumented issue in Safari 17: Intelligent Tracking Prevention (ITP) rules being applied to service worker traffic, leading to blocked resources and a significant drop in Google Analytics traffic for a large retail client in the Netherlands.

Posted by on

>TL;DR: Discovery of a potential, undocumented issue in Safari 17: Intelligent Tracking Prevention (ITP) rules being applied to service worker traffic, leading to blocked resources and a significant drop in Google Analytics traffic for a large retail client in the Netherlands. Solution involved selective routing of specific URLs to bypass the service worker. Post-change observations indicate improved analytics from other browsers, prompting ongoing investigation.


In the dynamic realm of web development, unforeseen challenges often lead to new discoveries. This was the case when Kedos Consulting encountered a potential bug in Safari 17 that seemed to apply Intelligent Tracking Prevention (ITP) rules to all traffic originating from service workers, an issue not currently documented in existing resources.


Identifying the Challenge

The issue came to light following a significant decrease in Google Analytics traffic from users on Safari 17. Interestingly, the traffic appeared normal during initial page loads but dropped on subsequent visits. This pattern indicated a scenario where the service worker was not yet activated on first visits but was operational on later ones, leading to the traffic drop.

Technical Analysis

The issue first manifested as a browser console error, reporting that it couldn't load the GTM script, as it had been blocked. The origin of the response was from the service worker, so the next step was to view the service worker's web developer console.

In the service worker, the error was reported as Failed to load resource: Resource blocked by content blocker. This was in a completely standard Safari installation - there were no additional plugins or blockers installed

The anomaly suggested that Safari 17 might be applying ITP rules to traffic routed through service workers. This was particularly evident as blocks were observed for Google Tag Manager, Google Analytics, and HotJar, but oddly, not for other trackers like Bing.

However, as far as we can tell, Safari should only be applying ITP when running in private browsing mode, or when it has been manually enabled in the preferences. Neither of these applied in this case, which was interesting.

Here's the initial Workbox service worker configuration:

// Initial Workbox configuration
workbox.routing.registerRoute(
  new RegExp('.*\\.(?:js|css)'),
  new workbox.strategies.CacheFirst({
    cacheName: 'assets'
  })
);
workbox.routing.setDefaultHandler(new workbox.strategies.NetworkOnly),

This is attempting to Cache all JS and CSS files, and then routing everything else back over to the network. The important thing to note here is that all traffic is being routed to the service worker, because of the default handler. This, along with the JS and CSS caching is the main cause of the issue.


Implementing a Solution

The team at Kedos Consulting strategised a workaround to this issue. The solution involved modifying the service worker's routing logic to exclude URLs known to trigger ITP, such as googletagmanager.com, allowing these requests to be processed directly by the browser. We also removed the default routing, to ensure that the service worker only intercepted the specific requests we needed.

// Revised Workbox configuration
workbox.routing.registerRoute(
  ({ url }) =>; !url.hostname.includes('googletagmanager.com') && /\.(?:js|css)$/.test(url.pathname),
  new workbox.strategies.NetworkFirst()
);

This was further expanded to include a 'bypass list' of domain names, which will always bypass the service worker. The risk here is that there's a potential for a continual game of cat-and-mouse with the ITP rules, as if they start blocking other domains we'll need to add them to this list each time. The other option available is to use a 'cache list' approach, where we only cache specific domains or URIs, which would be more resilient to changes.

Unexpected Observations: Post-implementation, reports from analytics teams revealed an improvement in data collection not only from Safari but also from other browsers. This puzzling outcome suggests there might be more layers to this issue than initially thought, warranting further investigation.

Conclusion

This situation underscores the complexity of modern web environments, where browser-specific behaviours can have wide-ranging impacts. The findings suggest a potential undocumented behaviour in Safari 17, posing both a challenge and an opportunity for web developers. Kedos Consulting continues to investigate this matter, aiming to unravel the full extent of its implications, both for our client, and for the wider web community as a whole.


About Kedos Consulting: Specialising in e-commerce architectural design and cloud system implementation, Kedos Consulting is committed to addressing and resolving complex technical challenges in the digital landscape. The team's recent work with a prominent retail client in the Netherlands reflects their dedication to innovation and adaptability in the face of evolving web technologies.