Safari 17 Link Tracking Protection
In Safari 17, Private Browsing gets even more private with added protection against some of the most advanced techniques used to track you. Technical changes include:
- Adding blocking for known trackers and fingerprinting.
- Adding support for mitigating trackers that map subdomains to third-party IP addresses.
- Adding blocking for known tracking query parameters in links.
- Adding noise to fingerprintable web APIs.
- Adding console log messages when blocking requests to known trackers.
- Adding support for blocking trackers that use third-party CNAME cloaking.
- Adding support for Private Click Measurement for direct response advertising, similar to how it works for in-app direct response advertising.
Adding tracking parameters to links is one way advertisers and analytics firms try to track user activity across websites. Rather than storing third-party cookies, a tracking identifier is simply added to the end of the page URL. This would circumvent Safari’s standard intelligent tracking prevention features that block cross-site cookies and other methods of session storage.
Navigating to that URL allows an analytics or advertising service at the destination to read the URL, extract those same unique parameters, and associate it with their backend user profile to serve personalized ads.
Many of these items are already handled by Webkit’s Tracking Prevention, which historically hasn’t leveraged the full suite of capabilities when used in Private Mode, as nothing in private mode was persisted beyond the tab being closed.
[…]
I also believe that the blocking for known trackers is likely to leverage the tracker list provided by DuckDuckGo, in much the same way that IP Address Obscurification(released in iOS15) works today. This is new behavior as previously the identified domains would be routed across the internet to mask the user’s IP Address. Now they will be blocked at the network layer and the external resource won’t be loaded in a way similar to what Brave’s Shield technology does today. This may cause website features to fail unless you have designed the site to fail gracefully. There is a high likelihood that this will affect attribution and analytics platforms and prevent them from being loaded in Private Browsing instances.
In particular there’s a
QUERY_PARAM.wplistfile that contains a list of URL query parameters to be removed. This list currently comprises 25 of the usual suspects, click identifiers such asfbclid(Facebook),gclid(Google), andmsclkid(Microsoft).Incidentally, most of these parameters, and others not on Apple’s list, are already automatically removed by my Safari extension StopTheMadness.
[…]
I’ve been informed by a reliable source that Apple’s
QUERY_PARAM.wplistlist of tracking query parameters came from PrivacyTests.org.
See also: MacRumors.
Previously:
Update (2023-07-25): See also: Hacker News.
This Safari query parameter removal thing is just going to become a cat-and-mouse game, right? Google can easily start using gclid2 or even switch to using something like “a,” that you’d be less willing to indiscriminately chop off the URL. Eventually, you could even imagine a dynamic query key scheme, where you can identify it with a credit-card-style hash function. For example, if f(KEY) = (char1 + char2 + … + charN) % 64 = 39, then it knows that that query key is its tracking ID.
[…]
My point is that you only feel safe mutating query parameters if you know for sure that they are tracking query parameters. You wouldn’t for example ever want to either remove, nor mutate, “q=”. That would break search. If trackers just start using less identifiable query keys, then it becomes very difficult to do anything to them without also potentially breaking legitimate websites.
Anything like it in the Android side of things?