WebKit has implemented tracking prevention technologies, spanning from 2003 with Safari 1.0 until today. Most of them are on by default. This document describes shipping behavior including Intelligent Tracking Prevention (ITP).
You can learn more about why we prevent cross-site tracking and how we handle the inherent tradeoffs by reading our Tracking Prevention Policy.
Let’s define what we mean by a few things first.
- A registrable domain is a website’s eTLD+1 or effective top-level domain plus one label. Effective top-level domains are defined in the Public Suffix List.
- Website or site. A website is a registrable domain including all of its subdomains. Others define site to also include the scheme, making http://news.example and https://news.example be two different sites. For the purposes of this document, we consider http and https to be be same site, since cookies can (still) span schemes.
- Cross-site. The user can be navigated across different websites or a website can load subresources form a different website. These are referred to as cross-site navigations and cross-site loads. When it comes to tracking, cross-site means tracking across different websites.
- First and third-party. If news.example is shown in the URL bar and it loads a subresource from adtech.example, then news.example is first-party and adtech.example is third-party. Note that different parties have to be different websites. sub.news.example is considered first-party when loaded under news.example because they are considered to be the same site.
- Third-party cookies. There is no special kind of cookie that constitutes a third-party cookie. Instead, it’s about content having access to its cookies when it’s loaded from a third-party. Let’s say your browser is loading an image from the third-party adtech.example on a webpage from the first-party news.example. If your browser allows it, a third-party request to adtech.example may include cookies and the subsequent response from adtech.example may set new cookies. Both those capacities – sending existing cookies and accepting new cookies for third-party content – are what’s referred to as third-party cookies.
- User interaction is a user click, tap, or keyboard entry on a website. Some refer to it as a user gesture. Scrolling is not considered user interaction.
- Partitioning is a technology to allow third-parties to use storage and stateful web features, but have those isolated per first-party website. Let’s say adtech.example is a third-party under both news.example and blog.example and that adtech.example uses LocalStorage. With partitioned LocalStorage, adtech.example will get unique storage instances under news.example and blog.example which removes the possibility to do cross-site tracking through LocalStorage.
- Ephemeral. When we say ephemeral storage, we mean the storage does not persist to disk and goes away with the application, for instance when the user quits the browser or reboots their device.
The basis for what in Safari is Private Browsing Mode is an ephemeral session which ensures that cookies and other stateful things are not persisted and go away when the user closes the tab, quits the browser, or reboots their device. Safari’s Private Browsing Mode uses a new ephemeral session for each tab the user opens to isolate tabs from each other.
Third-party LocalStorage is partitioned per first-party website and also made ephemeral.
Third-party IndexedDB is blocked by default in modern WebKit (it is partitioned in the deprecated WebKitLegacy). The check is done on the origin level which means a same-site iframe with a differing origin, such as a differing subdomain, cannot use IndexedDB.
Third-party Service Workers are partitioned and their cache and IndexedDB is partitioned too.
HTTP cache entries for third-party content is partitioned per first-party website.
Fingerprinting involves measuring the uniqueness of static device configuration (e.g. built-in hardware), dynamic device or browser configuration (e.g. user settings or installed peripherals), and user browsing data (e.g. checking which sites the user is logged in to, so-called login fingerprinting).
As we implement new web features, we look for fingerprinting vulnerabilities and opportunities to improve user privacy. We aim to collaborate with other implementers through the web standards process to advocate for users, and ensure that the specifications allow for, or preferably require, the protections we have added.
Here are examples of already existing such behavior changes:
- Require a user permission for websites to access the Device Orientation/Motion APIs on mobile devices, because the physical nature of motion sensors may allow for device fingerprinting.
- Prevent fingerprinting of attached cameras and microphones through the Web Real-Time Communication API (WebRTC).
- Changed font availability to web content to only include web fonts and fonts that come with the operating system, but not locally user-installed fonts. Web fonts and the common set of web-safe fonts, as well as other OS-bundled fonts, are still available.
- Altered the user agent string to not change with minor software updates. The string only changes with the marketing version of the platform and the browser.
Our next line of defense is to remove existing fingerprinting vectors where possible. The last few years, we’ve made these changes:
- Removed the Do Not Track flag, which ironically was used as a fingerprinting vector, adding uniqueness to the users who had enabled it.
- Removed support for any plug-ins on macOS. Other desktop ports may differ. (Plug-ins were never supported on iOS.)
Finally, if we find that features and web APIs increase fingerprintability and offer no safe way to protect our users, we will not implement them until we or others have found a good way to reduce that fingerprintability. We continue to have open discussions with other browser makers through the web standards process, many of whom share these concerns. Here are some examples of features we have decided to not yet implement due to fingerprinting, security, and other concerns, and where we do not yet see a path to resolving those concerns:
- Web Bluetooth
- Web MIDI API
- Magnetometer API
- Web NFC API
- Device Memory API
- Network Information API
- Battery Status API
- Web Bluetooth Scanning
- Ambient Light Sensor
- HDCP Policy Check extension for EME
- Proximity Sensor
- Serial API
- Web USB
- Geolocation Sensor (background geolocation)
- User Idle Detection
ITP by default blocks all third-party cookies. There are no exceptions to this blocking. Third-party cookie access can only be granted through the Storage Access API and the temporary compatibility fix for popups.
Once a request is blocked from using cookies, all redirects of that request are also blocked from using cookies.
All third-party referrers are downgraded to their origins by default. This applies to both HTTP referrer headers and
document.referrer. For example, if the full referrer is https://www.social.example/feed?clickID=123456, it will show up as https://www.social.example/.
HSTS, or HTTP Strict Transport Security, can only be set by the first-party website and only for the current host/domain and the website’s registrable domain. Further, HSTS is not applied to third-party requests that don’t carry cookies and since all third-party cookies are blocked by default, so is third-party HSTS.
Beyond across-the-board blocking of third-party cookies and downgrades of third-party referrers, ITP collects statistics on resource loads and matches it with known patterns of cross-site tracking. If a registrable domain matches at least one such pattern, it is classified as having cross-site tracking capabilities.
One such pattern is showing up as third-party resource under several first-party websites. A machine learning model decides when these three numbers leads to classification of
- The number of unique websites
domain.examplehas been seen as third-party subresource under.
- The number of unique websites
domain.examplehas been seen as third-party iframe under.
- The number of unique websites
domain.examplehas been seen doing cross-site redirects under.
Another pattern that is detected as the capability to track cross-site is top frame redirects, often referred to as bounce tracking. ITP counts the number of unique such redirects that
domain.example does, and classifies based on that number. ITP will count it as a bounce even if the redirect is delayed by landing on a webpage and triggering a navigation a couple of seconds later.
The third pattern that is detect is called tracker collusion. If domain.example gets classified as having cross-site tracking capabilities, a check is made to see which other domains have previously redirected to
domain.example and all of them get classified too. Then the process repeats recursively through the graph of redirects.
All website data is deleted for classified domains which have not received user interaction as first-party or been granted storage access as third party through the Storage Access API (see below) in the last 30 days of browser use. Such website deletion happens at an interval so as to not cause too much disk I/O.
Classified domains which have received user interaction as first-party or been granted storage access, but are found to engage in bounce tracking (top frame redirects) may have their cookies rewritten to SameSite=strict.
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.
- Media keys
- Service Worker registrations and cache