Apple\u2019s annual Worldwide Developer Conference in late June this year included a couple of big announcements around Apple\u2019s approach to privacy in their software.<\/p>\n
The new Privacy Report<\/strong> in Safari 14 (on all platforms) uses DuckDuckGo\u2019s tracker radar list<\/a> to detail which of the most prominent tracking-capable domains have been flagged by Intelligent Tracking Prevention (ITP)<\/a> in the user\u2019s browser.<\/p>\n Apple also announced that the <\/p>\n <\/a><\/p>\n<\/div>\n The release date for iOS 14, iPadOS 14, and Safari 14 was announced at the Apple Event<\/strong> on September 15, 2020, and all developers working on the Apple stack groaned in unison when they learned that the new operating systems would be pushed out the following day, September 16.<\/p>\n Queue a mad scramble to test the app builds against the latest versions of the build tools (released just 24 hours before the operating systems were updated), and the latest set of App Store guidelines (updated a week before).<\/p>\n Maybe a bit longer lead time next time, please Apple?<\/p>\n In this article I\u2019ll go over these changes, exploring their impact especially on analytics and digital marketing.<\/p>\n Also, I recommend you bookmark CookieStatus.com<\/a> – a community-led initiative to maintain an up-to-date information resource on the current status of browser (and app) tracking protection mechanisms.<\/p>\n <\/p>\n <\/a><\/p>\n CookieStatus.com<\/span><\/p>\n<\/div>\n \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 Let\u2019s tackle the easy one first.<\/p>\n For the first time, WebKit\u2019s tracking prevention measures are exposed to the user (beyond enabling the Intelligent Tracking Prevention debug mode<\/a>).<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n You can look at the Privacy Report for any site by clicking the small shield icon next to the address bar. If you want to see more details, click the <\/p>\n <\/a><\/p>\n<\/div>\n The first thing to note is the terminology.<\/p>\n domain.com<\/strong> was prevented<\/strong> from profiling<\/strong> you across N websites.<\/p>\n<\/blockquote>\n What does that mean? It means that the Safari browser has detected HTTP requests to the listed domains, and that the listed domains are found in DuckDuckGo\u2019s Tracker Radar lists.<\/p>\n To put it in another way – if the website is making requests to domains in DDG\u2019s Tracker Radar list, then those domains will be listed in the Privacy Report.<\/p>\n The funky thing is that these domains might<\/em> not actually have been flagged by Intelligent Tracking Prevention yet.<\/p>\n WebKit\u2019s ITP is algorithmic<\/strong> and on-device<\/strong>. The decision of whether or not a domain should be \u201cflagged\u201d as having tracking capabilities is done based on the user\u2019s browsing behavior<\/em> and not against a domain blocklist.<\/p>\n So the Privacy Report is a bit misleading.<\/p>\n The Privacy Report means, quite simply, that WebKit\u2019s global tracking protections<\/strong>, such as truncating all cross-site referrers<\/a> and blocking all cookie access in third-party context<\/a> have been applied to all<\/strong> the cross-site HTTP requests sent from the site, including but not limited to those shown in the Privacy Report<\/strong>.<\/p>\n The purpose of this approach is without a doubt to just show how the biggest trackers on the web have been prevented from cross-site tracking, but the measures are not<\/em> limited to just these domains. Nor are WebKit\u2019s ITP measures<\/strong> applied to these domains automatically (I repeat: WebKit does not use blocklists – it classifies domains algorithmically).<\/p>\n If this is difficult to follow, I don\u2019t blame you. I\u2019m worried this Privacy Report only serves to confuddle and obfuscate rather than to illuminate and educate. Case in point: When the release was foreshadowed in WWDC, it led to a tidal wave of misinformation spreading on the web. This prompted me to write an article on the topic<\/a> in an effort to stem the tide.<\/p>\n Let\u2019s recap this feature as clearly as possible:<\/p>\n I recommend you visit the Safari page on CookieStatus.com<\/a> for a more detailed walkthrough of what WebKit does by default, and what is behind Intelligent Tracking Prevention\u2019s flags.<\/p>\n The more interesting, and perhaps more convoluted, update was that Apple is updating the And what\u2019s the update? Well, nothing more and nothing less than that all<\/strong> WebKit\u2019s Intelligent Tracking Preventions are on by default<\/strong> in all<\/strong> browsers running At the time of writing this, all browsers apart from Brave<\/strong> have updated to the latest OS requirements, and Brave should follow up with a new build very shortly.<\/p>\n The main change can be found in Settings<\/strong> for each browser app. This is what Firefox looks like:<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n Across all iOS and iPadOS browsers, the new setting \u201cAllow Cross-Website Tracking\u201d is toggled off<\/strong>. This means that all these browsers are now implementing the full scale of WebKit\u2019s Intelligent Tracking Prevention mechanisms<\/a>.<\/p>\n These include, among others:<\/p>\n Full third-party cookie blocking<\/strong>. All cookie access in third-party context is blocked. There are no exceptions. Storage access can only be granted through the Storage Access API<\/a>.<\/p>\n<\/li>\n All cross-site referrers<\/strong> are downgraded to just the origin<\/em> by default ( All cookies written with JavaScript<\/strong> will have their expiration capped at a maximum of 7 days from the time the cookie is (re)written.<\/p>\n<\/li>\n Algorithmic classification<\/strong> of domains the browser communicates with. The classifier detects if the sites the user visits communicate with cross-site origins to a point where the classifier deems these domains to have cross-site tracking capabilities. At this point, additional restrictions that apply to classified<\/strong> domains kick in:<\/p>\n 4.1. All storage on these domains is purged after 30 days of the user not directly interacting<\/strong> (i.e. in first-party context) with the classified domain.<\/p>\n 4.2. If the classified domain sends traffic to other sites, appending parameters into the URLs (such as a Google ad click), then any JavaScript cookies written on the sites the links lead to will have their expiration capped at 24 hours<\/strong>.<\/p>\n 4.3. If the classified domain sends traffic to other sites, and the classified domain has URL parameters (or fragments) in the URL, the Note!<\/strong> At the time of writing, there seems to be a bug with the implementation across iOS browsers, and not all these mechanisms are in effect even if the \u201cAllow Cross-Website Tracking\u201d toggle is left to its default position of OFF.<\/p>\n<\/blockquote>\n This is \u2026 pretty big. The development of these web browsers is now intrinsically linked to the evolution of WebKit\u2019s tracking prevention mechanisms. For example, when the upcoming CNAME cloaking mitigation<\/a> sees daylight, it will be applied to all<\/strong> iOS \/ iPadOS browsers, and not just Safari as before.<\/p>\n As third-party cookies are now flushed out of the mobile operating systems, it means that any cross-site tracking scheme that relies exclusively on these is dead in the water. Google\u2019s DoubleClick network, for example, will no longer be able to build a cross-site profile of web users based on the sites they visit, as they will no longer be able to associate a cookie identifier to these hits.<\/p>\n It\u2019s unlikely that ad tech vendors have the gall to use the Storage Access API to ask permission of the user to track them across sites.<\/p>\n Vendors are, naturally, busy at figuring out workarounds. Those that own an identity platform (e.g. Facebook), have for long been moving cross-site tracking away from third-party context, and others will likely follow suit.<\/p>\n Reliance on fingerprinting will likely increase, even though these measures are addressed by<\/a> WebKit as well.<\/p>\n The cat-and-mouse game continues.<\/p>\n Services that run in first-party context are not without impact either.<\/p>\n WebKit restricts the lifetime of JavaScript cookies to a maximum of 7 days, with the limit set to 24 hours in some instances.<\/p>\n This can have an impact on the ratio of \u201cnew\u201d and \u201creturning\u201d users in analytics tools, and the likelihood of the same individual being included in different experiment groups increases, for example.<\/p>\n There is a known mitigation for this, which does not go against WebKit\u2019s policies: sites can recycle cookies so that they are set in HTTP headers instead.<\/p>\n <\/p>\n <\/a><\/p>\n From https:\/\/webkit.org\/blog\/8613\/intelligent-tracking-prevention-2-1\/<\/span><\/p>\n<\/div>\n WebKit\u2019s approach to referrers is similar to In other words, when the website makes a cross-site<\/strong> request (e.g. If the website makes a cross-origin<\/strong> (but same-site) request, the referrer string will be untouched.<\/p>\n Additionally, if the website is classified by ITP as having cross-site tracking capabilities and<\/em> it has query parameters (or fragments) in its URL, then any site it sends traffic to will have the Truncating the referrer like this has obvious impacts for analytics, for example, as understanding what sites and pages send you traffic has been a staple of web analytics for a long time.<\/p>\n Apple also updated its App Store review guidelines<\/a> a week before iOS 14 and iPad 14 were released. I recommend checking out Cory Underwood\u2019s overview<\/a> of the topic – the changes can be quite impactful for apps that also collect data from users.<\/p>\n Apps will basically have to:<\/p>\n Disclose in detail what type of data collection goes on.<\/p>\n<\/li>\n Provide an opt-in mechanism to the collection of user and usage data.<\/p>\n<\/li>\n Not put up consent walls (allow the user to access content only if they give consent to tracking).<\/p>\n<\/li>\n Implement an opt-out mechanism as well, where if the user withdraws consent, their data should be purged.<\/p>\n<\/li>\n<\/ul>\n There are echoes of GDPR and CCPA here, with the exception that Apple is a private company and not a legislative body. They have far more coverage than the aforementioned legal frameworks, and as these guidelines have a direct financial impact on organizations (loss of revenue if apps are removed from the store), they will likely inspire far more and faster action than any laws or regulations.<\/p>\n iOS 14, iPadOS 14, and Safari 14, are major releases at least when it comes to privacy protections in software running on Apple\u2019s operating systems.<\/p>\n Browsers running on iOS and iPadOS now must<\/strong> implement WebKit\u2019s ITP mechanisms, which, given iPhone and iPad market share, can have a resounding impact on organizations relying on data collection and sharing.<\/p>\n What\u2019s imperative now is that each organization starts benchmarking and modeling the impact of third-party cookie blocking and first-party cookie restrictions on their own data. Please try to avoid contributing to the FUD with knee-jerk reactions such as \u201cDATA IS DEAD\u201d or conjuring doomsday predictions based on circular reasoning.<\/p>\n The only thing that panic serves is the rapid spread of misinformation. And the only thing that misinformation feeds is diverting attention away from what WebKit is doing with these tracking prevention policies: eradicating cross-site tracking vectors from software and services running on the Apple stack.<\/p>\n Please let me know in the comments if something was unclear. Note that the releases are still quite fresh, and testing them due to bugs might lead to inconsistent results.<\/p>\n Be sure to monitor CookieStatus.com<\/a> as well. If you have information that\u2019s missing from the service, please submit an issue<\/a> about it.<\/p>\n<\/p><\/div>\n\n","protected":false},"excerpt":{"rendered":" Apple\u2019s annual Worldwide Developer Conference in late June this year included a couple of big announcements around Apple\u2019s approach to privacy in their software. The new Privacy Report in Safari 14 (on all platforms) uses DuckDuckGo\u2019s tracker radar list to detail which of the most prominent tracking-capable domains have been flagged by Intelligent Tracking Prevention […]<\/p>\n","protected":false},"author":1,"featured_media":80455,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12033],"tags":[24700,3554,14775,13376,10082,1706],"dealstore":[],"offerexpiration":[],"class_list":["post-80454","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-analytics","tag-intelligent","tag-ios","tag-ipados","tag-prevention","tag-safari","tag-tracking"],"yoast_head":"\nWKWebView<\/code> class, which all iOS and iPadOS (the operating systems for iPhones and iPads, respectively) must use, will include WebKit\u2019s ITP mechanisms on by default<\/strong>. The list of major browsers running on these operating systems includes Brave, Chrome, Edge, Firefox, and Safari.<\/p>\n![\"Intelligent](\"https:\/\/www.simoahava.com\/images\/2020\/09\/intelligent-tracking-prevention-updates.jpg#ZgotmplZ\"){kind=tracking}
<\/p>\n![\"CookieStatus.com\"\/](\"https:\/\/www.simoahava.com\/images\/2020\/09\/cookiestatus-com.jpg#ZgotmplZ\")
<\/p>\n
\n X<\/span><\/p>\n
\n The Simmer Newsletter<\/strong>\n <\/p>\nThe Privacy Report<\/h2>\n
![\"Privacy](\"https:\/\/www.simoahava.com\/images\/2020\/09\/privacy-report.jpg#ZgotmplZ\")
<\/p>\n(i)<\/code> button.<\/p>\n![\"Open](\"https:\/\/www.simoahava.com\/images\/2020\/09\/open-privacy-report.jpg#ZgotmplZ\")
<\/p>\n\n
\n
facebook.com<\/code> and doubleclick.net<\/code>) have been prevented from accessing the user\u2019s browser storage, among other things.<\/li>\nTracking prevention in all iOS and iPad browsers<\/h2>\n
WKWebView<\/code> class. Per the App Store guidelines<\/a>, all web browsers running on iOS must implement this class, though officially there\u2019s a transition period from the deprecated UIWebView<\/code> to WKWebView<\/code> which lasts until December 2020<\/a>.<\/p>\nWKWebView<\/code> in iOS 14 and iPad 14.<\/p>\n![\"Cross-site](\"https:\/\/www.simoahava.com\/images\/2020\/09\/cross-site-tracking-firefox.jpg#ZgotmplZ\"){kind=tracking}
<\/p>\n\n
https:\/\/www.domain.com<\/code>).<\/p>\n<\/li>\ndocument.referrer<\/code> string on the target site will be truncated to just eTLD+1 (so https:\/\/www.simoahava.com\/some-page<\/code> becomes https:\/\/simoahava.com\/<\/code>).<\/p>\n<\/li>\n<\/ol>\n\n
Impact #1: Cross-site targeting and profiling<\/h3>\n
Impact #2: First-party analytics, optimization, personalization<\/h3>\n
![\"From](\"https:\/\/www.simoahava.com\/images\/2020\/09\/itp-2-1.jpg#ZgotmplZ\")
<\/p>\nImpact #3: Referrer truncation<\/h3>\n
strict-origin-when-cross-origin<\/code><\/a>, except this is not a \u201cdefault\u201d referrer policy (it\u2019s always on), and it\u2019s more like strict-origin-when-cross-site<\/code>.<\/p>\nhttps:\/\/www.simoahava.com\/some-page\/<\/code> to https:\/\/www.google-analytics.com\/collect<\/code>), the referrer visible to google-analytics.com<\/code> will be just the origin: https:\/\/www.simoahava.com\/<\/code>.<\/p>\ndocument.referrer<\/code> string truncated to only eTLD+1 (so https:\/\/www.simoahava.com\/some-page\/?key=value<\/code> will show up as https:\/\/simoahava.com<\/code> if the domain has been classified by ITP).<\/p>\nNew App Store Review guidelines<\/h2>\n
\n
Summary<\/h2>\n