Question about Safari ITP 2.1 (Intelligent Tracking Prevention) and Google Analytics

[Rick Buffkin]

Hi guys. I have a quick question for the group here. I saw a post on my Linkedin feed talking about Safari ITP 2.1. It appears that this version of Safari (it's still in beta) is going to cap Client Side cookies that use document.cookie API to 7 days of storage. I'm wondering how this is going to affect our websites tracking data (Google Analytics, Personalizers, etc...). Have you guys heard anything about this at all? I just checked our GA account and it looks like 49% of the traffic to our sites use Safari and 77% of them use the latest version of Safari. I'm wondering how this change will affect GA data since it uses cookies and sets a 2 year expiration date on the GA cookie. Do you think it could mess up the re-marketing cookie? Am I looking at / reading this wrong or do you think it will affect GA? I would love to hear you guys thoughts.

You can read his solution here: https://www.simoahava.com/analytics/use-localstorage-client-id-persistence-google-analytics/

You can read more about Safari ITP 2.1 here: https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/

Quick Clip:
Client-Side Cookies Capped to 7 Days of Storage
Cookies can either be set in HTTP responses or through the document.cookie API, the latter sometimes referred to as client-side cookies. With ITP 2.1, all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry.

The reasons for this change cover privacy, security, and performance:

• Cross-site trackers have started using first-party sites’ own cookie jars for the purpose of persistent tracking. The first-party storage space is especially troublesome for privacy since all tracker scripts in the first-party context can read and write each other’s data. Say social.example writes a user tracking ID as a news.example first-party cookie. Now analytics.example, adnetwork.example, and video.example can leverage or cross pollinate that user tracking ID through their scripts on news.example.
• Cookies available in document.cookie can be stolen by speculative execution attacks on memory. Therefore, they should not carry sensitive information such as credentials.
• Cookies available in document.cookie can be stolen by cross-site scripting attacks. Again, therefore, they should not carry sensitive information such as credentials.
• The proliferation of cookies slows down page and resource loads since cookies are added to every applicable HTTP request. Additionally, many cookies have high entropy values which means they cannot be compressed efficiently. We come across sites with kilobytes of cookies sent in every resource request.
• There is a size limit on outgoing cookie headers for performance reasons, and websites risk hitting this limit when cross-site trackers add first-party cookies. We’ve investigated reports of news site subscribers getting spuriously logged out, and found that trackers were adding so many cookies that the news site’s legitimate login cookie got pushed out.

Implementation Details

• Only cookies created through document.cookie are affected by this change.
• The change covers cookies created in first-party contexts as well as in third-party iframes.
• Session cookies are not affected, they remain session cookies.
• Persistent cookies that have an expiry shorter than seven days keep their shorter expiry.

 

[craigh]

A couple things related to this:

1. Safari was one of the first to start blocking off-site cookies, which means that when you use chartbeat.com (example only) to track your customers, it wouldn't be able to track recurring visitors because chartbeat.com was not considered a trusted site and when you leave the site it would destroy any cookies or sessions they created. The loophole was that any domain that you had previously visited would be considered a safe site. This is why Google Analytics has an advantage, because 99.9% of people visit some form of google.com and therefore Safari would trust that domain on your computer.
   
   
2. Without reading all the latest articles/solutions, my understanding is that you can renew this 7 day lease anytime you want. This means anytime someone visits Google.com, they could theoretically refresh all the cookies and set them again with the same values, but renewing the 7 day time period. Again, this gives an advantage to domains that you would naturally visit.
   
   
3. This is a constantly moving target that does not work the same in all browsers. They are going out of their way to make tracking you in unethical ways more difficult, but this inevitably causes issues for those that are doing harmless tracking like Google Analytics. Where you will likely see the impact of this is those CRM tools that connect your website traffic to your CRM and other tracking solutions that are unlikely to adapt as quickly as Google, etc. We have a tracking code here that I built in 2017 that is completely non-functional now, because we were using javascript to set cookies on a random product domain, which the visitor would never see. This tracking still works in Chrome and some versions of Firefox, but in IE and Safari it generates a new cookie on every page or site visit because of the earlier version of this "fix" they're implementing.

To me, this is just the start of the end for many things like this.
Other countries (see: GDPR) are trying to make tracking far more obvious, less invasive and much easier to disable.
Browsers will all have the option to disable tracking entirely, Brave browser will continue to grow its market share and ultimately the idea of these analytics is going to have to adapt entirely.

 

[Rick Buffkin]

Thanks for your reply @craigh. You always give valuable insights. I appreciate your help. I'm going to do some more digging on this when I get some more free time.