Intelligent Tracking Prevention 2.1

The beta releases of iOS 12.2 and Safari 12.1 on macOS High Sierra and Mojave include an updated version of Intelligent Tracking Prevention (ITP). For purposes of developer communication, we’ll refer to it as ITP 2.1.

With this update we further reduce trackers’ ability to establish user identities across sites.

A Single Set of Cookies Per Site

Previous versions of ITP allowed domains that were classified with tracking capabilities to store partitioned cookies, i.e. additional sets of cookies keyed off of the top site. As of ITP 2.1, partitioned cookies are no longer supported and third-parties classified with cross-site tracking capabilities now have to use the Storage Access API to get any cookie access.

The revised timeline for classified domains’ cookies and website data looks like this:

There are multiple reasons for this change:

• Simplify for developers. We’ve received reports of existing site behavior getting tripped up by partitioned cookies. For instance, one site had a script which if it concluded that the user was logged out, overwrote its cookies with blank values to make sure no remnant data persisted (except for the cookie names). When this site was rendered in a third-party iframe, this cookie overwriting would instead create a new set of blank cookies.
• Lower the memory footprint. As of ITP 1.1, partitioned cookies are session cookies which means they are not persisted. By getting rid of partitioned cookies, the storage session doesn’t have to keep multiple sets of cookies in memory.
• Simplify ITP adoption for other WebKit ports. Partitioned cookies require support in the HTTP layer below WebKit. By removing support for them, we increase ITP’s flexibility and can make it work on more platforms.

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.

Mike West (Google) has provided related statistics on cookies.

Will This Change Log Users Out?

Authentication cookies should be Secure and HttpOnly to protect them against man-in-the-middle attacks, cross-site scripting attacks, and speculative execution attacks. Cookies created through document.cookie cannot be HttpOnly which means authentication cookies should not be affected by the lifetime cap. If they are, you need to set your authentication cookies in an HTTP response and mark them Secure and HttpOnly.

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.

Verified Partitioned Cache

WebKit implemented partitioned caches more than five years ago. A partitioned cache means cache entries for third-party resources are double-keyed to their origin and the first-party eTLD+1. This prohibits cross-site trackers from using the cache to track users. Even so, our research has shown that trackers, in order to keep their practices alive under ITP, have resorted to partitioned cache abuse. Therefore, we have developed the verified partitioned cache.

When a partitioned cache entry is created for a domain that’s classified by ITP as having cross-site tracking capabilities, the entry gets flagged for verification. After seven days, if there’s a cache hit for such a flagged entry, WebKit will act as if it has never seen this resource and load it again. The new response is then compared to the cached response and if they match in the ways we care about for privacy reasons, the verification flag is cleared and the cache entry is from that point considered legitimate. However, if the new response does not match the cache entry, the old entry is discarded, and a new one is created with the verification flag set, and the verification process starts over.

ITP currently does this verification for permanent redirects since that’s where we see abuse today.

Removed Compatibility Fix for Popups

As mentioned in the ITP 2.0 blog post, we implemented a temporary compatibility fix for third-party popups, automatically forwarding storage access under the opener page. In ITP 2.1, we’ve removed the compatibility fix for popups that dismiss before they receive user interaction, i.e. dismiss before they receive a tap, click, or text entry.

Removed Support For the DNT (“Do Not Track”) Signal

Apple believes that privacy is a fundamental human right and that users should not be tracked across the web without their knowledge or their consent. Intelligent Tracking Prevention was enabled by default for all users when it was released in 2017, and prevented users from being tracked by third parties they didn’t engage with. ITP has been enhanced since then in response to trackers abusing web technologies to track users and additional on-by-default privacy functionality has been added to Safari, such as browser fingerprinting defenses.

The introduction of ITP 2.1 coincides with Safari removing support for the Do Not Track (DNT) signal. The DNT signal was an attempt by web stakeholders to offer users an off-by-default way to ask servers not to track them. Importantly, DNT did not offer technical enforcement to prevent tracking of users by websites. Apple supported the DNT project starting in 2011, but since then, the vast majority of websites unfortunately have not changed their behavior in response to the DNT signal for the users who elected to turn it on. Instead, online tracking and tracking techniques have become more pervasive and sophisticated in spite of the DNT project.

The DNT project recently ended without the publication of a standard, in part “because there has not been sufficient deployment of these extensions (as defined) to justify further advancement.” Given the lack of deployment of DNT and Safari’s on by default privacy protections such as ITP, Safari removed support for DNT so that users are not presented with a misleading and ineffective privacy control that, if anything, only offered additional browser fingerprinting entropy.