Ce qu'App Tracking Transparency ne bloque pas sur iOS — et comment vraiment empêcher le pistage des applications

En bref : ATT bloque un seul identifiant spécifique (l'IDFA — l'identifiant publicitaire d'Apple). Les applications qui souhaitent continuer à vous pister cessent simplement d'utiliser l'IDFA et se tournent vers une douzaine d'autres identifiants qu'ATT ne touche pas. Des recherches indépendantes ont montré que de nombreuses applications continuent à vous pister par fingerprinting, même après que les utilisateurs ont appuyé sur « Ask App Not to Track ». Voici ce qu'ATT fait réellement, ce qu'il ne fait pas, et ce qui comble l'écart.

Ce qu'App Tracking Transparency bloque réellement

ATT, introduit avec iOS 14.5 en avril 2021, oblige les applications à afficher une invite système avant de pouvoir accéder à l'IDFA (Identifier for Advertisers) de l'appareil — une chaîne globale unique qu'Apple attribue à chaque appareil. Si vous appuyez sur « Ask App Not to Track », l'application est censée recevoir un IDFA rempli de zéros. C'est tout. C'est l'intégralité du mécanisme.

Cette protection étroite est cohérente avec la conception d'Apple : ATT porte sur un seul identifiant contrôlé par Apple. Ce qu'ATT n'a jamais été conçu pour faire — et ce que la plupart des utilisateurs supposent qu'il fait — c'est d'empêcher les applications de suivre votre comportement par d'autres moyens.

Ce vers quoi les applications se sont tournées après ATT

Quand l'IDFA a été coupé, l'industrie de la publicité mobile n'a pas renoncé. Elle a changé de techniques :

Empreinte numérique de l'appareil. Combiner la résolution de l'écran, le modèle, la version du système d'exploitation, les langues installées, le fuseau horaire, les variations du bruit de l'accéléromètre et une trentaine d'autres signaux pour former une empreinte suffisamment unique pour ré-identifier votre appareil d'une application à l'autre. Cette empreinte est construite à partir de données qu'Apple laisse les applications lire librement.
Identifiants utilisateur hachés. Si vous vous connectez à une application gratuite avec votre e-mail, le SDK hache cet e-mail et envoie le hachage au réseau publicitaire. Ce hachage correspond à celui d'autres applications qui disposent de votre e-mail. ATT n'empêche pas cela — vous avez accepté en vous inscrivant.
SDK partagés comme liant inter-applications. Le SDK de Facebook est intégré dans environ 30 % des applications mobiles. Quand vous utilisez l'une de ces applications, le SDK envoie un rapport à Meta — même si vous n'avez pas de compte Facebook. ATT interpelle l'application hôte, pas les identifiants distincts du SDK intégré.
Dissimulation CNAME. Un site ou une application crée un alias DNS (analytics.bigsite.com → en réalité hotjar.com) pour que le traceur paraisse être de première partie. ATT ne dispose d'aucune couche DNS ; les bloqueurs de contenu des navigateurs ne peuvent pas facilement résoudre la chaîne d'alias.
Attribution SKAdNetwork. Le propre remplaçant d'Apple compatible avec ATT — les applications signalent les événements d'attribution d'installation via des canaux agrégés par Apple. Moins précis que l'IDFA, mais toujours de l'attribution. Ce n'est pas rien.

Le tableau empirique

Des chercheurs indépendants ont montré à maintes reprises qu'ATT, en pratique, bloque un seul canal tout en laissant de nombreux autres ouverts : de nombreuses applications continuent sous une forme ou une autre à pister l'utilisateur après qu'il a refusé l'autorisation ATT, principalement via le fingerprinting et les identifiants SDK partagés.

Il ne s'agit pas de dire qu'ATT est mauvais — c'est une protection utile, bien que limitée. Il s'agit de dire qu'ATT seul est insuffisant si votre objectif est « les applications ne devraient pas me pister ».

Ce qui comble réellement l'écart

Toutes les techniques décrites ci-dessus partagent une caractéristique structurelle : elles exigent que le SDK atteigne un serveur distant. L'empreinte doit être envoyée quelque part. L'e-mail haché doit appeler la maison-mère. Le SDK de Facebook doit envoyer sa charge utile à graph.facebook.com. Les traceurs dissimulés par CNAME finissent toujours par pointer vers une vraie destination.

Cela signifie qu'un filtre au niveau réseau (DNS) qui bloque les connexions aux domaines de traceurs connus intercepte tous ces cas en une seule intervention, quel que soit l'identifiant que l'application s'apprêtait à envoyer. C'est l'approche que Pi-hole a initiée pour les réseaux domestiques, et que des outils mobiles tels que Casper's Cloak, NextDNS et AdGuard DNS appliquent pour les appareils individuels.

Le mécanisme, simplifié :

Le SDK intégré à l'application tente d'envoyer son empreinte / identifiant haché / signal comportemental à son serveur (p. ex. graph.facebook.com, amplitude.com, mixpanel.com).
Avant que cette connexion puisse s'établir, l'appareil effectue une résolution DNS pour trouver l'IP du serveur.
Le profil VPN système envoie les requêtes DNS via un résolveur filtrant.
Le résolveur reconnaît que le nom d'hôte est un traceur et refuse de renvoyer une IP.
La connexion ne s'ouvre jamais. Les données ne quittent jamais votre téléphone.

Ce qui est crucial, c'est que cela fonctionne pour toutes les applications de l'appareil — pas seulement Safari. ATT opère au niveau de l'API SDK applicative. Les bloqueurs de contenu des navigateurs opèrent au niveau du DOM. Le filtrage DNS opère au niveau réseau, en dessous des deux, là où toutes les applications convergent.

Ce qu'ATT fait bien — là où il faut lui rendre crédit

ATT est véritablement utile pour deux choses :

Il a changé le comportement par défaut. Avant ATT, l'IDFA était toujours actif. Après ATT, la plupart des utilisateurs refusent lorsqu'on le leur demande. C'est un vrai changement de confidentialité à l'échelle de la population, même avec des contournements.
Il a poussé Meta et d'autres à divulguer leur infrastructure de pistage qui était auparavant invisible. Les étiquettes App Privacy de l'App Store, que les applications doivent remplir avec précision, sont une conséquence directe de cela.

ATT était une mesure qui en valait la peine. Elle n'est simplement pas complète — et Apple n'a jamais prétendu le contraire.

Recommandations pratiques

Continuez à appuyer sur « Ask App Not to Track ». La protection marginale vaut bien la seconde d'effort.
Utilisez un filtre au niveau DNS en complément d'ATT — Casper, NextDNS, AdGuard DNS, ou un Pi-hole auto-hébergé. C'est ce qui intercepte les techniques qu'ATT ne traite pas.
Vérifiez les étiquettes App Privacy des applications avant de les installer. Si les étiquettes d'une application indiquent « Données liées à vous — Identifiants » pour des finalités non essentielles, cherchez une alternative.
Reconnaissez que les applications « gratuites » se monétisent par le pistage par défaut. Les alternatives payantes ont souvent une posture de confidentialité nettement différente car elles n'en dépendent pas.
Ne vous connectez pas avec Apple/Google/Facebook si un vrai e-mail fonctionne. Le SSO enchaîne des identifiants qui, autrement, resteraient isolés.

En conclusion

ATT est une fonctionnalité de confidentialité utile mais limitée. Elle bloque un seul identifiant contrôlé par Apple. Les applications qui souhaitent continuer à pister utilisent simplement d'autres identifiants. Si votre objectif est le plus large « les applications ne devraient pas me pister », ATT n'est que le début, pas la fin — associez-le à un filtre au niveau réseau qui intercepte ce qu'ATT n'a jamais été conçu pour traiter.