22 October 2020
ITP and iOS14 - Apple Just Made 10 Louder
Apple moves to shake up end user privacy across the iOS ecosystem
In the 1984 cult film Spinal Tap there is a classic scene where Christopher Guest’s character Nigel Tufnel is bragging about how loud his amps will go.
“If you look here, these all go to 11” he states proudly.
“But why not just make 10 louder?”, asks the interviewing character Marty Di Bergi played by Rob Reiner.
It’s the kind of thing that is obvious if you take a step back and look at the broader picture, and you would be forgiven for failing to see it at first.
This brings us to the next round of ITP changes. A few weeks ago, we learned that Apple’s ITP team decided to just make 10 louder. Instead of opting to tighten the privacy ratchet on Safari itself, it appears they took a step back to think about the broader industry and end user privacy across the entire Apple iOS ecosystem.
In a recent article, we discussed the cname cloaking changes that some ad tech vendors were using to circumvent earlier Safari ITP changes. This, in turn, blocked some third party trackers and associated cookies or at least shortened their lifespan significantly.
However, just after we published that article we became aware of another important update on Twitter via WebKit and Safari ITP Apple engineer John Wilander. Here, he confirms that the latest round of ITP changes are browser agnostic, meaning they would apply at the iOS level itself, not just to Safari users.
Why is this particular change so significant?
Unlike previous ITP updates which were focused on the Safari web browser itself, this new approach will now impact all the major browsers installed on Apple’s iOS14+ OS.
This means that Google Chrome, Microsoft Edge, Apple Safari, Mozilla Firefox, Opera and more derivatives will be impacted.
The change also signals a precedent for future ITP changes. Unlike previous ITP changes that only impacted the Safari Web Browser and its end users, the ITP net has now been cast further and wider to capture and permanently alter the behaviour of ad tech based trackers at an Apple iOS level.
What is the impact?
On June 5th, 2017 Apple, via Safari, launched the first iteration of ITP. If you’ve been a digital marketer for a couple of years now, you probably watched on as your ability to track certain Safari user activity, particularly around attribution, became somewhat hamstrung by ITPs gradually stricter enforcement of privacy policies.
Although it was a problem to lose some visibility into Safari users, it wasn’t a huge restriction. In the Australian market, 14% of Desktop users and 48% of Mobile users use Safari and, even though Safari tablet market share is much higher at 67% only 6.4% of all devices fall into the tablet device category.
Unsurprisingly, the most impacted products were the largest online advertising platforms and their third party tracking tools such as:
- Google Ads conversion tracking
- DoubleClick floodlight tags
- Facebook’s pixel
- Many other smaller ad tech vendors
The ITP roadmap so far
To make sense of why these updates are being made, you need to understand how we got here. Below is a high level overview of the changes and impacts and, for simplicity, we have focussed on how Google responded.
The initial iterations attempt to curtail the use of third party trackers by shortening the lifespan of associated cookies or completely preventing them being set in the third party context.
Some vendors respond to these new guidelines with their own interpretation around how to handle Safari ITP’s stricter privacy settings.
For example, Google’s response was to:
- Allow Google Analytics users with linked Google Ads accounts to set a first party cookie for conversion tracking purposes. The first party cookie (named: _gac_UA-XXXXXX-Y) was set by Google Analytics and contained Ad Click information known as gclid (a form of click id).
Utilise link decoration (a form of cross domain tracking). This is useful when your primary domain is not the same as your conversion domain. For example imagine an end user journey to a conversion page like this:
www.example.com -> secure.paymentvendor.com/thank-you
By decorating links (adding a URL or anchor # parameter to links between these domains with cookie information such as that found in the _gac_UA-XXXXXX-Y cookie), you can measure user activity across multiple domains, but still remain within a first party context.
Safari detects first party cookies from known ad tech vendors such as Google’s new _gac_UA-XXXXXX-Y cookie and reduces the expiry date from the default 30 day setting, down to 7 days.
Knowing that some conversions are unlikely to be attributed or given credit to various Ad placements, Google offers modelled conversions which provide a predictive or estimated view of conversions in their reporting UIs.
This specifically targets cookies set in the first party context, that it determines as being third party cookies (or those belonging to ad networks/vendors but masking themselves as being in the first party context). It also earmarks the use of link decoration, which applies to Facebook and Google’s ITP workarounds.
Released to plug further detected holes where link decoration is being used to circumvent changes in 2.2. ITP 2.3 caps the lifetime of all script-writeable website data after a navigation with link decoration from a classified domain, a domain Safari has identified as being a data collector.
An important change is also made to document.referrer behaviour, which the ITP team identifies as a workaround employed by some ad tech vendors. If the referrer string contained a clickID or similar string, the receiving domain script would see the clickID in the referrer and set a first party cookie with this value. These clickID strings are now scrubbed from the referrer (document.referrer value) along with any page/path so that only the referrer string eTLD+1 (top level domain) value would be returned.
referrer = http://trackerDomain.com/page/path?clickid=1234
Receiving domain = www.example.com sets a cookie with the value of 1234 after seeing the value in document.referrer.
After ITP 2.3, the referrer string is reported as: http://trackerDomain.com/ when document.referrer is referenced, scrubbing the clickid parameter information shown above.
The three big changes are:
- Full third-party cookie blocking is now enabled by default, meaning all third party cookies are completely blocked.
- 7 day cap on all Script-Writeable Storage mechanisms including cookies but also other LocalStorage mechanisms. All data is scrubbed after inactivity with a domain/website after 7 days.
- Cross-site document.referrer is downgraded to origin (all paths are removed), similar to the change in ITP 2.3 where click IDs are scrubbed from referrers. ITP 3.0 takes it one step further and only reports on the origin (eTLD+1) value for all referrers, even when there is no clickID detected.
A user on website: www.shopping.example/clothing/spinal-tap-tshirts arrives at www.example.com
- Prior to ITP 3.0 the referrer would be reported as: www.shopping.example/clothing/spinal-tap-tshirts
- After ITP 3.0 the referrer is trimmed down to: www.shopping.example/
It is clear that this latest change to implement ITP at the WebKit, and therefore iOS14 level, is upping the ante further on the user privacy side. Although these latest changes may seem like a slight overreach, browsers such as Mozilla Firefox, via Enhanced Tracking Protection, and even Google’s Chromium team have announced they will phase out third party cookies. So, in effect, this latest update is just speeding a process along, where the wheels have been in motion for some time.
Is there a silver lining?
If there is any good news to take away from this change, it’s that you no longer have to explain the quirks and nuances of Safari browser behaviour when reviewing your Analytics data with key stakeholders in your business. Instead, you can state that it is a wider industry trend and changes to protect end user privacy are likely to continue. You can also suggest they start to work on a mitigation plan now to prepare for the next few of years.
What are the next steps?
As the ITP team at Apple and other browser vendors move to curtail the collection of data on behalf of their respective end users, it may be time to start reflecting on your own data collection methods and who you ultimately share your data with in more detail.
Depending on your business and where you operate you may already be subject to stringent privacy protection laws such as:
Not only that, but people are becoming increasingly wary of how their data is being used and collected through news headlines such as Facebook’s Cambridge Analytica controversy. As a result we believe the next big industry shift for data analytics will be to move to a more secure data collection model, which offers more control and transparency.
Enter server to server (S2S) communication
We see S2S tools becoming more and more relevant as they offer your business the ability to communicate and document how end user data is being handled and processed more clearly, which in return helps you form your own data policies with more precision and confidence. Ultimately, this should also provide your end users with more confidence regarding how you manage their data.
The cookie-scape will change
Another benefit of S2S communication is the ability to set and use HTTPOnly cookies. These cookies prevent any client based scripts from being able to manipulate or access cookie data which means, they are more secure and resilient to manipulation. This cookie-type usage is encouraged as part of Safari ITPs recommendations.
As a result of using HTTPOnly first party cookies, you can set and enforce stricter content security policies (CSPs) settings on your web-properties, further protecting your own website against malicious attacks (such as cross site scripting XSS). Additionally, you can also protect your end users from cookie/session hijacking attempts and opportunists.
Oh and we forgot to mention with all this comes the added bonus of potential performance benefits via faster page load and rendering times. Have we piqued your interest yet?
Whilst we think the industry is in for a shake up, we actually see these changes as positive for end user privacy in the long run. Let’s also keep in mind that before the latest ITP changes rolled out, a small cohort of more savvy end users were already likely to be blocking third party cookies, installing browser plugins to opt out of specific trackers and or using firewall tools such as Pi-hole to block requests at the network level.
History has shown that change can be a great thing. The end user experience on the web was fairly poor in the late 1990s. Web pages often featured distracting animations, audio (midi files auto-playing in the background) and adopted bloated HTML markup such as table markup for layouts. Pages were slow to load and page layouts were frequently broken when viewed in different browsers, due to lack of W3C standards being adopted.
A shift occurred when authors such as Steve Krugg and Jeffrey Zeldman wrote, “Don’t Make Me Think” and Designing with Web-Standards (respectively). Web pages became a lot more user friendly, easy to navigate, faster to load and there was a more consistent experience across platforms and browsers. As a result, the end user experience on the web improved significantly because the industry adapted and did what was better for the end user.
The latest privacy and client-side tracking shake up is a similar pivot for the Analytics industry. Ultimately end users will have more faith and control over how their data is shared and who it is shared with, while also sustaining a faster and more secure experience on the web.
That, is something we will all benefit from.
- CookieStatus documents ITP changes across browser groups
- Google responds to Apple’s Intelligent Tracking Prevention with AdWords tracking update
- WTF is Apple’s ITP 2.2 update?
- Apple ITP Introduces Full Third-Party Cookie Blocking in Safari and iOS