Intelligent Tracking Prevention 2.2
The beta releases of iOS 12.3 and Safari on macOS Mojave 10.14.5 include an updated version of Intelligent Tracking Prevention (ITP). For purposes of developer communication, we’ll refer to it as ITP 2.2.
Tracking Via Link Decoration Caps Client-Side Cookies to 1 Day of Storage
As of ITP 2.2, persistent cookies set through document.cookie
are capped to one day of storage when both of the following conditions are met:
- A domain classified with cross-site tracking capabilities was responsible for navigating the user to the current webpage.
- The final URL of the navigation mentioned above has a query string and/or a fragment identifier.
The rest of this blog post explores this in detail.
What Is Cross-Site Tracking Via Link Decoration?
Let us first explain the reason for this change. Intelligent Tracking Prevention was designed to protect user privacy by preventing cross-site tracking. Since ITP 1.0 was launched, we have seen increased usage of URL query strings for cross-site tracking purposes.
In the illustration above, the social network website social.example is adding a “click ID” as a query parameter to every outgoing link. Each of these click IDs are connected to the real user ID “Jane Doe” in social.example’s database.
Once Jane lands on the destination page, the social network uses JavaScript to read the click ID in the URL query string and store it in a first-party cookie. How does the social network gain scripting powers on the destination website? The destination website can import scripts from social networks or ad networks to integrate a feature, and these scripts can be augmented to read, store, and report back incoming click IDs.
From this point, every time Jane happens to visit news.example, blog.example, or shop.example, social.example’s script reads the click ID first-party cookie, sends it to its server, and identifies her. Now social.example can enrich its profile of Jane by tracking her activities on these websites and they can serve her individually targeted ads on these websites, all because she once navigated there through a link on social.example.
This shows how click IDs can effectively work like user IDs for cross-site tracking.
Further Consequences of Cross-Site Tracking Through Link Decoration
There are two additional consequences of link decoration that are concerning for user privacy and for web compatibility.
User IDs are Transferred When Users Share Links
When tracking information is added to links, it can be used to connect people and devices when the links are shared. Jane Doe in the example above may want to share the news.example link with a coworker. Through link decoration, her social.example user ID is now copied into her coworker’s web browser and can be used to connect her with her coworker on social.example’s platform.
Some Websites Fail to Load When They Receive Unknown Query Parameters
Many websites simply fail to load when they receive query parameters that their servers don’t recognize. In one case we came across, a link to a comedy website was shared on a popular social network and the website rendered blank because of the social network’s link decoration. The following comments ensued:
- Commenter 1: “The link is broken.”
- Poster: “Sorry about that. Here’s the link again …”
- Commenter 1: “That link is broken too.”
- Commenter 2: “Yeah, the social network messes with the links. You have to use a link shortener.”
Exactly When Should I Expect Cookies to Expire?
Here’s an example of when ITP 2.2 will cap cookie persistence to one day:
- The website social.example has been classified by ITP as having cross-site tracking capabilities. How this classification works is explained in detail in the original ITP blog post and the ITP 2.0 blog post.
- The user clicks a link on social.example.
- The click results in a cross-site navigation that lands on shop.example and the landing URL has a query string and/or a fragment identifier.
- The shop.example webpage sets a persistent cookie through document.cookie. This cookie will now have a maximum expiry of one day.
What About Ad Click Attribution?
You might recall from our original ITP blog post that we mentioned link decoration as a way to achieve ad attribution in navigations. Such attribution should serve the destination site information about what ad was clicked and on which site, not information about who the user is.
The kind of link decoration described above is being used for cross-site tracking of users.
What If My Website Uses Query Strings or Fragments?
Just like with cookies and other web storage, there are legitimate and privacy-infringing uses of query strings and fragments, and cross-site trackers try to make their activities indistinguishable from good use. We are obliged to prevent cross-site tracking for Safari users.
It has been suggested that ITP should simply remove any link decoration when the click source has cross-site tracking capabilities. We opted not to do so because of legitimate use and the risk of breaking website compatibility (see the comedy example above).
Note though, the one-day cap on document.cookie storage only applies if your site was navigated to by another site with cross-site tracking capabilities, and only for the current webpage.
Developers, Here’s What You Can Do About It
We have discussed with developers how cross-site tracking through link decoration came about. After all, user IDs are stored in websites’ first-party cookies — a storage space they manage.
Our impression is that many developers never understood it was happening; in many cases, changes to third-party JavaScript embedded on websites introduced link decoration without web developers’ knowledge. However, once developers know that their websites are leveraged for cross-site tracking purposes, they can choose to filter out trackers’ link decoration.
We hope that web developers will join us in better protecting user privacy while concurrently creating the best user experiences on the web.