iOS17 filtering click tracking links

I’ve heard quite a bit of concern about what iOS 17’s automatic removal of click-tracking parameters means, but less discussion of what it actually does.

Broadly it’s Apple trying to improve user-privacy by making it harder to do cross-site tracking at scale. Cross-site tracking is the basis of a lot of privacy-violating tracking technologies, and tracking parameters added to links evade Safari’s technologies that mitigate tracking via cross-site cookies or other forms of session storage.

(As partial compensation, Apple is supporting Private Click Measurement. That’ll allow ad click measurements without sending PII to the advertisers.)

But, what does it actually mean? I’ve not seen much in the way of documentation, so I built a test harness, installed an iOS 17 developer beta on a spare iPad and looked at what it does.

The test setup is very, very simple. I have a custom webserver that accepts clicks and logs the URL and the parameters it received. I send simple HTML mail containing links with parameters that point at that server to my ipad. I click on the link and see what parameters make it to the server.

General results first. It doesn’t seem to matter how the link appears. It can be in the href of a tag containing the word “link”, it can be a URL in plain text, it can be an anchor tag that has the URL as the visible text and in the href. It’s all treated the same. The non-parameter parts of the URL don’t seem to have any effect.

I tested a bunch of URLs, with parameters taken from real tracking links in use in the wild. Here’s the results:

email	<the recipients email address>	ok
cid	bid_mol_pch_r03_co_cp1579 _pjt10368_col120764_0so_fbk _da_awa_vt_s23_pi_ss439	ok
comm_track_id	r_739d3289-15ac-4e54-8d4e-ec051c133b5d_2_x	ok
code	NTQwMTA5MDZ8bGF1cmEtaXJpc2hyYWlsQ GNhcnJvdGNhZmUuY29tfFMz	ok
utm_campaign	booking+email	ok
utm_content	Click+here+to+view+amend+or+ cancel+your+booking	ok
utm_medium	email	ok
utm_source	product+first+class	ok
n	2	ok
u	KFozupC4hMau3PknCEub8g-ChJ5g7 eF4gyyKU8jq64yySCPp9oID	ok
e	fa66f2ceeaa926c1057d8a99e77d09b8	ok
qs	126f50db688ae59e1b0e437e72c49b784 5c4a1fb2055f86231f0b0555cdebee4606 cf936f3e09462e8221b25857373e9d7d3 286f5808f23b	ok
Email	<recipients email address>	ok
continue	https://myaccount.google.com/alert/nt /1687004<long, probably sensitive cookie>	ok
articleTitle	Posterior%20Reversible%20Encephalo pathy%20Syndrome…	ok
external	true	ok
fb_id	5748591	ok
nl_campaignid	1046	ok
nl_eventid	15275	ok
profileId	302978008	ok
fbclid	IwAR3s_u-Pj6O3WhT813GTkgbPGslqK-o7JgssKKtx81hA1SowosXAunH7RnY	stripped
fbclid	hello	stripped
twclid	2-5h05u3egjyi9q5dpj6m957385	stripped
gclid		stripped
wttwclid		ok

And everything listed in the “Tracking query parameter tests” at privacytests.org was stripped.

Fields containing the recipents actual email address were fine. Fields with 400 bits of opaque data, enough to identify everything you’d ever want to identify, were fine. Obvious customer or profile identifiers, or UTM tracking data, all fine.

None of the fields had their contents modified – they were all either stripped or passed through unchanged.

The only tags that were stripped were those listed at privacytests.org.

It seems pretty clear that the target right now is the large scale marketing and social media attribution PII sharing marketplace, not click tracking and attribution by ESPs or email marketers.

Apple aren’t going to take your clicks away.

(Edited to add: https://github.com/wttw/clickcheck has the test harness I used, if you want to play with it yourself).

Edited further to add: The parameter stripping is being done by Mail.app, not Safari. If the link in Mail.app is copied, or shared via the Share… context menu the tracking parameters are stripped then. Conversely, a link with tracking parameters in a page open in Safari doesn’t seem to have those parameters stripped when it’s followed or shared (except sometimes / possibly in private browsing mode?).

This means that if you have a link in your mail that goes to a click-tracker, and the click-tracker then redirects to a URL with fbclid, gclid parameters in it then those parameters won’t be stripped in a vanilla setup. That may be different if the user has an alternate browser set, is using Safari in private mode or, possibly, is using Apple’s private browsing setting. It may well change in the future, too.