L'API de Apple et son filtrage système - une bonne chose ou pas

L'approche d'Apple en matière de filtrage à l'échelle du système a récemment donné lieu à l'introduction d'une API qui diffère considérablement de ce à quoi les développeurs sont habitués. Les changements qu'elle apporte m'ont amené à réfléchir à plusieurs nouvelles idées sur la manière dont le filtrage peut être mis en œuvre au niveau du système d'exploitation, ce qui en fait une étude de cas intéressante pour l'avenir du blocage de contenu.

Alors que les discussions pemdant l'AFDS se concentrent généralement sur les navigateurs et les extensions web (les environnements où s'effectue la plupart du filtrage de contenu), le filtrage à l'échelle du système présente un défi plus large et de plus en plus pertinent. L'examen des limites et des capacités de la nouvelle API d'Apple offre des informations qui peuvent également contribuer à améliorer le filtrage basé sur les navigateurs. Mais tout d'abord, explorons ce que nous entendons exactement par « filtrage à l'échelle du système ».

Qu'est-ce que le filtrage à l'échelle du système ?

Le filtrage à l'échelle du système est essentiellement la capacité d'intercepter et de bloquer le trafic web de n'importe quelle application, et pas seulement celui des navigateurs.

Le filtrage du trafic à l'intérieur d'un navigateur a toujours été relativement simple grâce aux extensions de navigateur. Même avec Manifest V3, le navigateur fournit toujours une API claire et bien définie pour le filtrage de contenu.

Lorsque nous élargissons notre champ d'analyse et nous intéressons aux systèmes d'exploitation, nous constatons que la situation est complètement différente ici. Aucune d'entre elles n'offre d'API dédiée au filtrage de contenu, de sorte que les développeurs de bloqueurs de publicités doivent s'appuyer sur des techniques spécifiques à chaque plateforme, chacune présentant ses propres inconvénients.

Vous posez peut-être la question pourquoi le filtrage à l'échelle du système est-il si important ? N'est-ce pas assez de bloquer les publicités dans les navigateurs ? Selon des études récentes, le trafic provenant des navigateurs représente moins de 15 % du trafic total sur les appareils mobiles. Sur les ordinateurs de bureau, les navigateurs dominent toujours avec environ 55 à 60 % du trafic global, mais si l'on examine les chiffres pour toutes les plateformes, seuls 30 % environ du trafic Internet total proviennent des navigateurs. Les 70 % restants proviennent des applications.

Et c'est là que réside le véritable défi en matière de confidentialité. Le suivi interne des applications est souvent beaucoup plus invasif que sur les sites web. Les applications peuvent accéder à davantage de données personnelles, interagir directement avec les ressources de l'appareil et utiliser des identifiants persistants, ce que les sites web ne peuvent tout simplement pas faire. Cela rend d'autant plus importante la tâche de filtrer l'ensemble du trafic de l'appareil.

Le filtrage à l'échelle du système a toujours été l'un des principaux atouts d'AdGuard. En fait, la toute première version d'AdGuard, lancée il y a plus de 15 ans, était une application Windows qui bloquait les publicités au niveau du réseau. Au fil du temps, nous nous sommes étendus à toutes les principales plateformes et sommes allés encore plus loin en lançant AdGuard DNS et AdGuard Home, deux autres produits destinés à protéger l'ensemble de l'appareil (voire l'ensemble du réseau !), et pas seulement à filtrer le trafic au sein d'un seul navigateur.

C'est ce qui rend ce sujet particulièrement intéressant à mes yeux. Il y a encore beaucoup à améliorer, et je suis heureux de voir qu'un des fournisseurs de systèmes d'exploitation, Apple, s'y intéresse enfin.

Comment ça marche

Pour comprendre mon point de vue, vous devez d'abord savoir comment le filtrage à l'échelle du système a commencé, comment il fonctionne aujourd'hui et quels sont les défis auxquels les développeurs de bloqueurs de publicités sont encore confrontés. Un petit test pour les anciens : saviez-vous que le blocage des publicités a en fait commencé avec les fichiers HOSTS qui étaient utilisés pour rediriger les serveurs publicitaires vers des adresses IP inexistantes ? HOSTS est un fichier texte brut qui associe les noms d'hôtes aux adresses IP, tout comme le fait un serveur DNS.

Snippet from Peter Lowe’s blocklist

Bien sûr, les fichiers HOSTS ont leurs limites : ils sont statiques, ils ne peuvent bloquer que des domaines précis, ils sont difficiles à mettre à jour et ils peuvent être contournés. Mais c'est pourtant là que tout a commencé. Une autre approche courante était le DNS sinkholing, qui repose sur le même principe que les fichiers HOSTS, mais appliqué au niveau du DNS afin de fonctionner simultanément sur plusieurs appareils.

Example of using a DNS server to block access to a domain

Cela a résolu certains problèmes, mais présentait des limites importantes : cela ne permettait toujours que de bloquer des domaines et pouvait toujours être contourné. C'est pourquoi le DNS sinkholing est utile dans de nombreux cas, mais ne constitue pas une solution complète.

Viennent ensuite les proxys, des serveurs qui agissent comme intermédiaires entre votre appareil et Internet pour le trafic HTTP. Cette approche était extrêmement populaire aux débuts du blocage des publicités. De nombreux outils « classiques » s'en servaient, comme Ad Muncher ou même les premières versions d'AdGuard. La capture d'écran que vous voyez ici date d'il y a environ 15 ans, lorsque AdGuard (qui s'écrivait alors Adguard) fonctionnait essentiellement comme un proxy HTTP.

L'avantage principal d'un proxy est qu'il peut filtrer le trafic en fonction des URL complètes et pas seulement des noms de domaine, tant que le trafic n'est pas crypté. Et même lorsqu'il l'est, il peut toujours voir le nom de domaine.

Quelle que soit la méthode que vous utilisez pour le filtrage à l'échelle du système, le premier défi technique consiste à intercepter le trafic et à le rediriger vers votre filtre, qu'il s'agisse d'un DNS, d'un proxy ou de tout autre dispositif. Différentes plateformes nécessitent différentes techniques :

• Android : VPN local
• iOS : VPN local, extension des paramètres DNS
• macOS : extension réseau (proxy transparent, proxy DNS)
• Windows : pilotes WFP/TDI/WinSock/NDIS

Je ne vais pas entrer dans les détails de chacune de ces méthodes, cela n'est pas nécessaire. Il suffit de savoir qu'elles sont toutes difficiles à mettre en œuvre, qu'il est facile de se tromper et qu'elles posent souvent des problèmes de compatibilité. Pourtant, ce sont les primitives avec lesquelles nous devons composer si nous voulons filtrer le trafic au niveau du système.

Même si nous résolvons tous les défis précédents, il reste un problème majeur : nous avons besoin d'une visibilité complète des URL pour un filtrage précis. Pourquoi est-ce important ? Je vais vous donner deux exemples.

1. Le premier concerne le réseau publicitaire de Facebook. Facebook diffuse à la fois du contenu légitime et des demandes de suivi à partir du même domaine : graph.facebook.com. Sans accès à l'URL complète, le blocage de ce domaine perturberait également le fonctionnement de Facebook lui-même.
2. Le deuxième exemple est la nouvelle proposition de l'IAB appelée Trusted Server (serveur de confiance). Je n'entrerai pas dans les détails ici, mais en bref, elle déplace les enchères publicitaires vers le côté serveur et diffuse les publicités à partir du domaine propre à l'éditeur, les faisant ainsi apparaître comme du contenu de première partie.

À l'heure actuelle, le seul moyen fiable d'inspecter les URL complètes est d'utiliser un proxy avec interception TLS. Il s'agit toutefois d'une tâche extrêmement complexe, mais que nous devons tout de même accomplir.

Proxy + TLS interception diagram

Quelqu'un doit donc surveiller votre trafic pour que le filtrage fonctionne, qu'il s'agisse d'une extension de navigateur, d'un VPN ou d'un antivirus. C'est tout simplement inévitable. Idéalement, ce traitement s'effectue localement, sur l'appareil de l'utilisateur. C'est plus sûr, car les données ne quittent jamais l'appareil. Mais même cela nécessite de la confiance, et l'histoire montre que la confiance peut être compromise. Ainsi, même si le filtrage local est préférable, il ne garantit pas la confidentialité : les utilisateurs doivent toujours faire confiance à celui qui gère le filtre.

À quoi devrait donc ressembler une solution de filtrage idéale à l'échelle du système ? Elle devrait répondre à plusieurs critères.

1. Tout d'abord, il doit prendre en charge le filtrage complet des URL, ce qui est essentiel pour garantir la précision.
2. Ensuite, il doit offrir des capacités de filtrage étendues. Il ne suffit pas de bloquer les requêtes ; il faut parfois les modifier ou les rediriger, ou encore inspecter les réponses.
3. Il doit également pouvoir gérer des listes de blocage très volumineuses.
4. Et pourtant, les mises à jour doivent rester rapides et efficaces.
5. Bien sûr, il doit être conçu pour préserver la confidentialité, ce qui signifie que le bloqueur de contenu ne doit pas avoir besoin de savoir quels sites web l'utilisateur visite ; il doit simplement appliquer les règles localement.
6. Néanmoins, le système doit fournir un certain type de retour d'information, au moins des statistiques de base ou une confirmation de ce qui a été bloqué, afin de le rendre observable et utile.
7. Enfin, il faut disposer d'outils de débogage appropriés, tant pour les développeurs comme nous que pour les responsables de la maintenance des filtres qui doivent dépanner efficacement leurs règles.

Avec cette liste à l'esprit, passons au filtre URL d'Apple.

Le filtre URL d'Apple

Il y a environ dix ans, Apple est devenu le premier développeur de navigateurs à introduire une API dédiée au blocage de contenu. Aujourd'hui, dix ans plus tard, la société a franchi une nouvelle étape importante, cette fois au niveau du système d'exploitation. Pour la première fois, Apple fournit une API officielle pour le filtrage des URL à l'échelle du système. Sur le papier, c'est une excellente nouvelle. Et franchement, c'est quelque chose que nous attendions depuis longtemps : une opportunité passionnante pour tous ceux qui travaillent dans le domaine de la confidentialité et du filtrage réseau.

Voyons donc comment cette API fonctionne concrètement. Nous commencerons par une présentation très générale.

1. Tout d'abord, votre application enregistre un filtre URL spécial dans le système d'exploitation. Cela s'applique à la fois à iOS et à macOS.
2. Ensuite, pour l'activer, le système effectue une étape d'autorisation : il communique avec votre serveur pour vérifier la configuration et les informations d'identification.

Une fois cette étape terminée, le filtre passe à l'état « En cours d'exécution » et, à partir de ce moment, le système commence à l'utiliser pour vérifier les URL des requêtes. Lorsque le filtre d'URL est actif, il examine toutes les requêtes Web effectuées par n'importe quelle application du système.

Voyons ce qui se passe lorsqu'une application souhaite envoyer une requête à https://example.org/test:

Apple’s URL filter high-level overview — Filtering

1. Le système divise l'URL en sous-URL.
2. Celles-ci sont vérifiées à l'aide d'un préfiltre local afin de déterminer rapidement quelles URL peuvent être classées comme sûres.
3. Les autres sont envoyées à votre serveur externe pour une vérification ultérieure.
4. En fonction de la réponse du serveur, le système bloque ou autorise la requête.

Il est facile de comprendre comment une mise en œuvre naïve de ce système pourrait se transformer en cauchemar pour la vie privée. Pour remédier à cela, Apple a pris plusieurs décisions de conception intelligentes qui visent à préserver la vie privée des utilisateurs tout en permettant un filtrage efficace.

L'ensemble de l'API de filtrage des URL repose sur plusieurs technologies modernes de protection de la vie privée.

1. Tout d'abord, il y a Privacy Pass, qui est utilisé pour l'authentification des utilisateurs.
2. Ensuite, il y a le service Private Information Retrieval, ou PIR, utilisé pour les recherches sur le serveur. Il est accompagné d'un filtre Bloom, qui agit comme un préfiltre local.
3. Et enfin, il y a Oblivious HTTP.

Toutes ces technologies sont assez récentes et à la pointe de la technologie. Il est donc fascinant de voir Apple non seulement les adopter, mais aussi les intégrer dans un système réel comme celui-ci. Examinons de plus près chacun de ces composants et leur fonctionnement.

Privacy Pass

Le premier composant est Privacy Pass. Il s'agit d'un système d'authentification moderne qui préserve la confidentialité. Il permet aux clients d'obtenir des jetons anonymes qui prouvent leur légitimité sans révéler leur identité ou leur comportement.

Diagramme du flux Privacy Pass. Source : Blog Cloudflare

Selon le diagramme :

1. Lorsqu'un client envoie une requête au serveur d'origine, il peut demander un jeton valide.
2. Le client contacte un Attesteur pour confirmer son éligibilité ; s'il est approuvé, un Émetteur fournit un jeton Privacy Pass.
3. Le client envoie le jeton à l'Origine, qui le vérifie à l'aide des clés publiques de l'émetteur et accepte la requête.

Le principe fondamental de la confidentialité est la séparation des rôles : si l'Origine et l'Émetteur restent indépendants, l'authentification reste anonyme — le serveur sait que le jeton est valide, mais ignore l'identité de l'utilisateur. C'est ainsi que fonctionne Privacy Pass en théorie — mais voyons comment Apple l'utilise dans son système.

Privacy Pass — le PIR d'Apple

1. Le client s'authentifie d'abord à l'aide d'un identifiant permanent (tel qu'un compte utilisateur) pour obtenir des jetons Privacy Pass à durée de vie limitée.
2. Chaque demande PIR utilise l'un de ces jetons, prouvant ainsi sa légitimité.

Cela ressemble à l'idée initiale. Mais voici le point essentiel : contrairement à la conception idéale de Privacy Pass, l'Émetteur et l'Origine (le service PIR) dans le système d'Apple appartiennent à la même entité, à savoir le développeur. Étant donné que le développeur contrôle les deux, les jetons peuvent potentiellement être liés aux utilisateurs. Ainsi, le véritable anonymat dépend entièrement de la mise en œuvre par le développeur. Concentrons-nous maintenant plus précisément sur le PIR, ou Private Information Retrieval (récupération d'informations privées).

Private Information Retrieval (PIR — récupération d'informations privées)

En termes simples, le PIR est une famille de protocoles cryptographiques qui permettent à un client de récupérer des données sur un serveur sans que celui-ci ne sache quel élément spécifique a été demandé. L'idée n'est pas nouvelle, elle est explorée depuis les années 1990. Le plus ancien exemple de système de type PIR largement utilisé est Google SafeBrowsing, lancé il y a 20 ans. Il suit un principe similaire, mais sans la cryptographie lourde.

La mise en œuvre du Private Information Retrieval par Apple est un système beaucoup plus sophistiqué, une véritable conception cryptographique privée. Voici un aperçu général de son fonctionnement :

l'implémentation de PIR par Apple

1. Le serveur prépare une base de données — essentiellement une table de hachage — où chaque entrée est cryptée et indexée.
2. Il publie ensuite une configuration décrivant comment les clients doivent interagir avec le service : structure de la table de hachage, paramètres de cryptage et autres métadonnées.
3. Lorsqu'un client souhaite vérifier une URL spécifique, il détermine l'index correspondant dans cette table de hachage.
4. Le client crée ensuite une requête indiquant « Je veux l'élément X », mais la requête est cryptée, de sorte que le serveur ne peut pas savoir à quoi correspond réellement l'élément X.
5. Le serveur évalue cette requête cryptée à l'aide d'un cryptage homomorphe, produisant une réponse cryptée qui comprend plusieurs entrées possibles.
6. Le client décrypte la réponse localement et vérifie si X figure parmi ces résultats.
7. Si X est trouvé, la requête est marquée comme bloquée.

Comme vous pouvez le constater, cela ressemble à une véritable recherche d'informations privées et l'objectif semble être atteint.

Mais parlons des performances. Le système PIR d'Apple est gourmand en ressources :

• Chaque requête peut atteindre environ 30 Ko, c'est beaucoup pour une seule requête API
• Une seule recherche peut prendre plus de 100 millisecondes, même dans des conditions idéales

Et, comme on peut s'y attendre, plus la base de données est volumineuse, plus chaque opération de recherche devient lente. Pour résoudre ce problème, l'API PIR d'Apple permet le partitionnement (sharding), c'est-à-dire la division de la base de données principale en plusieurs parties plus petites. Le serveur définit plusieurs partitions ; lors de la vérification d'une URL, le client calcule son numéro de partition à l'aide d'une fonction et l'inclut dans la requête. Cela accélère les requêtes, mais introduit un risque potentiel de fuite de données confidentielles : si le nombre de partitions est suffisant, une partition peut correspondre à une seule URL, révélant ainsi ce que l'utilisateur est en train de vérifier.

Ce risque peut-il être atténué ? Oui, je pense qu'Apple pourrait atténuer ce risque en imposant une taille minimale ou un nombre maximal de fragments, et j'espère qu'ils envisageront de le faire. Mais même le partitionnement n'est pas suffisant si le client doit envoyer chaque URL au serveur. Apple a donc ajouté une autre étape d'optimisation : un préfiltre, qui est essentiellement un filtre de Bloom.

Schéma du filtre Bloom. Source : bytedrum.com

Je ne vais pas m'étendre sur le fonctionnement des filtres Bloom, mais voici ce que vous devez savoir :

• Ils sont très rapides et peu encombrants.
• Un filtre Bloom est conçu pour répondre à une question simple : « Cette URL figure-t-elle dans l'ensemble de données ? »
• Les réponses possibles sont :
  • Certainement pas
  • Peut-être oui (ce qui signifie qu'elle pourrait figurer dans la liste de blocage, nous devons donc la vérifier à l'aide du PIR)

Il en résulte que la plupart des recherches ne quittent jamais l'appareil.

Oblivious HTTP

Le dernier composant de l'API de filtrage d'URL est Oblivious HTTP (soit OHTTP). Pour résumer, Privacy Pass garantit une authentification anonyme, PIR masque la requête et OHTTP supprime l'identifiant final, à savoir l'adresse IP de l'utilisateur. OHTTP sépare le client du serveur à l'aide de quatre parties :

• Client (appareil de l'utilisateur)
• Relais (Apple)
• Passerelle (développeur)
• Cible (serveur final, PIR ou Privacy Pass)

Oblivious HTTP dans le PIR Apple

Le client chiffre la requête destinée à la passerelle et l'envoie via le relais, qui se contente de la transférer. La passerelle la déchiffre et la traite, chiffre la réponse et la renvoie au client via le relais. L'idée est que le relais connaît l'identité de l'utilisateur, mais pas ce qu'il envoie ; la passerelle connaît la requête, mais pas l'utilisateur.

Mais même si vous avez réussi à tout faire fonctionner, il reste une dernière étape : le processus de vérification d'Apple. Avant que votre application puisse utiliser la nouvelle API, votre service PIR et votre passerelle HTTP Oblivious doivent être vérifiés et approuvés par Apple. Soyez prêt : la vérification peut prendre un certain temps, alors planifiez à l'avance si vous développez autour de cette API.

Résumé

Alors, quelle est la qualité du filtre URL d'Apple ? Dans le premier chapitre, j'ai présenté une liste des propriétés qu'une solution de filtrage idéale à l'échelle du système devrait présenter. Revenons maintenant sur cette liste et voyons dans quelle mesure la nouvelle API de filtrage URL d'Apple répond à ces attentes.

✅ Filtrage URL complet

Oui, en effet.

🚫 Capacités de filtrage avancées

Malheureusement, celui-ci ne passe pas le test. Le système d'Apple vous permet de bloquer des requêtes, mais c'est à peu près tout. Il existe également plusieurs limitations importantes :

• Vous ne pouvez pas débloquer vous-même des domaines individuels : c'est tout ou rien. Soit la liste de blocage est entièrement active, soit elle est complètement désactivée.
• Vous ne pouvez pas passer d'une liste de blocage à une autre. Chaque application ne peut fournir qu'une seule liste.

Il existe certes quelques solutions de contournement théoriques, mais celles-ci s'apparentent davantage à des piratages qu'à de véritables solutions.

✅ Prise en charge des listes de blocage énormes

Là aussi c'est un oui. Du début l'API a été conçue pour des listes de blocages d'envergure.

✅ Des mises à jour rapides pour les listes de blocage

Ici aussi, Apple obtient une note satisfaisante. L'API prend en charge les mises à jour automatiques, et l'intervalle minimum entre deux mises à jour est de 45 minutes, ce qui est en réalité très satisfaisant.

❔ Conçu pour préserver la confidentialité

Le point suivant est un peu plus compliqué. Pour moi, « conçu pour préserver la confidentialité » signifie que lorsqu'une application utilise cette API, l'utilisateur reste totalement anonyme et le développeur n'a aucun moyen de savoir qui il est. Et bien que ce soit clairement l'objectif d'Apple (toute l'architecture est conçue pour préserver la confidentialité des utilisateurs), dans la pratique, je constate quelques failles qu'un développeur pourrait exploiter pour réidentifier les utilisateurs ou suivre leur activité. Espérons qu'Apple corrigera ces problèmes dans les prochaines versions et renforcera considérablement les garanties d'anonymat.

🚫 L'API fournit une rétroaction

L'API fournit-elle donc une rétroaction au développeur sur son fonctionnement réel ? Non, absolument pas. L'application n'a aucun moyen de savoir si son filtre d'URL a bloqué quelque chose ou même vérifié une URL particulière. En d'autres termes, c'est une boîte complètement opaque.

🚫 Des outils de déboggage

Malheureusement, il n'existe aucun outil intégré pour aider les développeurs ou les responsables de filtres à comprendre ce qui se passe en arrière-plan. Et comme vous pouvez l'imaginer, le dépannage d'un filtre d'URL est une tâche très, très difficile.

✅✅✅ Enfin, malgré toutes les lacunes dont nous avons discuté, je tiens à terminer sur une note positive. Cette API est infiniment préférable à l'absence totale d'API. Il s'agit d'un grand pas en avant, la première véritable tentative d'un fournisseur de système d'exploitation pour rendre le filtrage à l'échelle du système à la fois sécurisé et respectueux de la vie privée. Je suis sincèrement reconnaissant à Apple d'avoir pris cette initiative et d'avoir été le premier à réfléchir sérieusement à ce cas d'utilisation. Ce n'est pas encore parfait, mais c'est un début très prometteur, et je suis impatient de voir comment cela évoluera à l'avenir.

J'aimerais ajouter que nous avons mis au point notre propre implémentation de PIR et qu'elle est actuellement en cours d'examen par Apple (depuis plus d'un mois, en fait). J'espère vivement qu'elle passera l'examen avec succès le plus tôt possible et que nous pourrons ajouter cette fonctionnalité aux produits AdGuard.

Si vous décidez de tester le système PIR d'Apple, voici quelques outils et ressources qui pourraient vous aider à commencer :

• Service PIR + Privacy Pass : Apple fournit un exemple d'implémentation des services PIR et Privacy Pass. Il n'est pas prêt pour la production, mais c'est une excellente référence pour comprendre comment tous les composants sont censés fonctionner ensemble.
• Test du PIR et du Privacy Pass : pour faciliter les tests, j'ai créé un petit outil en ligne de commande qui permet de simuler le flux du PIR et du Privacy Pass. Il est open source et disponible sur GitHub.
• Filtre Bloom : Apple n'a publié aucun code officiel pour en créer un, et leur documentation à ce sujet était initialement assez vague. J'ai donc créé une bibliothèque Swift capable de générer des filtres Bloom entièrement compatibles avec l'API de filtrage d'URL d'Apple.
• Passerelle Oblivious HTTP : pour Oblivious HTTP, Cloudflare fournit à la fois une bibliothèque de référence et une implémentation serveur prête à l'emploi.
• GoCurl — test Oblivious HTTP : enfin, si vous avez besoin de tester votre configuration OHTTP, vous pouvez utiliser mon projet parallèle à long terme appelé GoCurl. Il s'agit essentiellement d'une réimplémentation de curl basée sur Go, avec des fonctionnalités supplémentaires telles que la prise en charge intégrée d'Oblivious HTTP.