Vous avez installé un logiciel de contrôle parental sur le Mac de votre enfant. Ou votre entreprise a déployé un filtre réseau pour bloquer les sites non professionnels. Dans les deux cas, une question s’impose : comment ce logiciel peut-il décider qu’une adresse web est dangereuse, s’il ne sait pas quelle adresse vous êtes en train de visiter ?
C’est exactement le paradoxe que macOS 26 Tahoe résout avec une nouvelle API discrète, présentée au WWDC 2025 : NEURLFilter. Une architecture cryptographique sophistiquée qui permet, pour la première fois à l’échelle d’un système d’exploitation, de filtrer des URLs complètes sans jamais les exposer, ni à Apple, ni au fournisseur du filtre.
Le problème fondamental que personne n’avait vraiment résolu
Depuis les débuts du filtrage web, les logiciels de sécurité, de contrôle parental et de protection d’entreprise fonctionnent tous selon le même principe : ils s’intercalent entre votre navigateur et le réseau, lisent chaque URL, la comparent à une liste noire, et décident d’autoriser ou de bloquer.
Cette approche est efficace. Elle est aussi profondément intrusive. L’application de filtrage voit absolument tout ce que vous consultez. Elle connaît vos habitudes, vos centres d’intérêt, vos recherches médicales, vos lectures politiques. Pour fonctionner, elle doit voir. Et ce « voir » crée une tension permanente entre la sécurité que l’on cherche à assurer et la vie privée que l’on sacrifie pour y parvenir.
Sur macOS 26, Apple propose une réponse architecturale à ce dilemme. Pas un compromis. Une solution technique qui brise le présupposé de base : un filtre n’a pas besoin de voir une URL pour décider si elle est dangereuse.
NEURLFilter : l’API que les développeurs attendaient
NEURLFilter est une nouvelle interface de programmation intégrée au framework NetworkExtension, disponible sur macOS 26, iOS 26 et iPadOS 26. Elle permet à une application tierce, une application de contrôle parental ou un client MDM d’entreprise, de filtrer l’ensemble du trafic HTTP et HTTPS du système en se basant sur l’URL complète, et non plus seulement sur le nom de domaine.
La distinction entre domaine et URL complète est importante. Avec les anciens filtres, une application pouvait bloquer « reseausocial.com » tout entier. Avec NEURLFilter, elle peut bloquer « reseausocial.com/groupes/extremisme » tout en laissant passer le reste du site. La précision passe d’un fusil de chasse à un scalpel.
Mais la vraie nouveauté n’est pas là. Ce qui rend NEURLFilter remarquable, c’est que l’application de filtrage n’a jamais accès au trafic réseau réel. Elle ne s’insère pas dans le flux de données. Elle gère un système de décision distribué en quatre couches, chacune répondant à une contrainte précise.
Les quatre couches qui rendent l’impossible possible
Le filtre de Bloom : la première ligne, ultra-rapide
Tout commence par un filtre de Bloom, téléchargé depuis les serveurs du fournisseur de filtrage et stocké localement sur le Mac. Un filtre de Bloom est une structure de données probabiliste, comparable à une empreinte condensée d’une très grande liste d’URLs dangereuses.
Quand le système visite une URL, il consulte d’abord ce filtre local en quelques microsecondes. Deux résultats possibles :
- Le filtre dit « pas de correspondance » : l’URL est autorisée immédiatement. Un filtre de Bloom ne produit jamais de faux négatifs. S’il dit que l’URL est inconnue, elle l’est vraiment.
- Le filtre dit « correspondance possible » : le système passe à la couche suivante.
L’intervalle minimum entre deux mises à jour du filtre de Bloom est fixé à 45 minutes, ce qui constitue l’une des limitations documentées de l’API. Pour une liste noire évoluant rapidement, comme lors d’une campagne de phishing active, ce délai peut laisser passer des menaces récentes.
La récupération d’informations privée (PIR) : interroger sans révéler
Lorsqu’une correspondance potentielle est détectée par le filtre de Bloom, le système doit vérifier si l’URL est effectivement dans la base de données complète du fournisseur. C’est là qu’intervient la Private Information Retrieval, ou PIR.
La PIR est une technique cryptographique fondée sur le chiffrement homomorphe. Le principe : le client génère une clé de chiffrement qui ne quitte jamais l’appareil. Il chiffre sa requête (l’URL à vérifier) avec cette clé, l’envoie au serveur du fournisseur. Le serveur effectue une recherche dans sa base de données en opérant directement sur les données chiffrées, sans jamais les déchiffrer. Il renvoie un résultat chiffré. Seul le client peut déchiffrer la réponse.
En termes pratiques, cela signifie que le serveur du fournisseur de filtrage reçoit une requête cryptée, traite cette requête de manière aveugle, et retourne une réponse cryptée. Il sait qu’une requête est arrivée. Il ne sait absolument pas quelle URL a été vérifiée.
Le relais HTTP « oblivieux » : masquer l’identité du client
La PIR protège le contenu de la requête. Mais il reste un problème : l’adresse IP. Si le fournisseur de filtrage ne peut pas voir quelle URL est vérifiée, il peut encore voir d’où vient la requête. Et une adresse IP, c’est une identité.
Apple résout ce problème avec un relais HTTP oblivieux hébergé par Apple elle-même. Ce protocole, standardisé sous le nom de Oblivious HTTP (OHTTP), fonctionne ainsi : la requête PIR chiffrée est d’abord envoyée au relais Apple. Le relais enlève l’adresse IP du client et transmet la requête au serveur du fournisseur. Le serveur retourne sa réponse au relais, qui la renvoie au client.
Résultat : le fournisseur voit des requêtes chiffrées sans adresses IP. Apple voit des adresses IP sans contenu chiffré. Aucune des deux parties n’a la vue complète. Ni Apple ni le fournisseur ne peuvent identifier qui a vérifié quelle URL.
Privacy Pass : l’autorisation sans identification
La quatrième brique est Privacy Pass, un protocole de jetons cryptographiques. Il permet de prouver qu’une requête est légitime (émise par un appareil autorisé) sans que cette preuve permette de tracer la requête dans le temps ou de la relier à d’autres requêtes. C’est le mécanisme d’authentification qui ne crée pas de corrélation entre les vérifications successives.
Ce que l’application de filtrage voit vraiment
L’aspect le plus surprenant de NEURLFilter est peut-être ce qu’il cache aux développeurs eux-mêmes. L’application de filtrage n’est pas dans le chemin du trafic réseau. Elle gère un « pré-filtre », c’est-à-dire la base de données du filtre de Bloom, qui est téléchargée et mise à jour par le système. Le filtrage automatique s’applique à tout le trafic WebKit et URLSession sans que l’application soit impliquée dans chaque décision.
Pour les navigateurs non basés sur WebKit, comme les versions macOS de Chrome ou Firefox, l’API expose une méthode que les développeurs peuvent appeler explicitement pour soumettre une URL à la vérification.
L’application de filtrage est seulement appelée pour prendre la décision finale, après que les couches cryptographiques ont fait leur travail. Et même là, elle reçoit un verdict binaire, bloquer ou autoriser, sans jamais voir l’URL réelle du trafic utilisateur.
Les cas d’usage concrets
Cette architecture ouvre des possibilités précises :
Le contrôle parental y gagne en profondeur : les applications comme Circle ou Screen Time pourraient implémenter NEURLFilter pour bloquer non plus des domaines entiers, mais des chemins précis à l’intérieur de ces domaines, tout en préservant la confidentialité de la navigation de l’enfant vis-à-vis du fournisseur.
Pour les environnements éducatifs, les systèmes MDM déployés par les établissements scolaires peuvent configurer des filtres ciblés sur des contenus spécifiques sans exposer la navigation complète des élèves à un tiers.
En entreprise, les solutions de sécurité réseau peuvent déployer des listes noires granulaires pour des politiques d’usage acceptable, sans que le fournisseur de sécurité accumule de données de navigation identifiables.
Les limites à connaître
NEURLFilter n’est pas sans contraintes, et il est honnête de les mentionner.
La latence du filtre de Bloom, 45 minutes au minimum entre deux mises à jour, est un vrai déficit dans un contexte de sécurité dynamique. Les campagnes de phishing modernes peuvent se déployer et disparaître en moins d’une heure.
L’absence de verdict gradué est une seconde limitation : l’API ne permet que bloquer ou autoriser. Pas de « avertir et laisser passer sur confirmation », ce qui est une modalité courante dans les produits de sécurité d’entreprise.
L’impossibilité pour le fournisseur de découvrir de nouvelles URLs inconnues supprime ce que l’industrie de la sécurité appelle la « telemetry », la capacité à remonter des signaux depuis les clients pour améliorer la protection collective.
Apple a clairement choisi la vie privée comme contrainte non négociable dans la conception de cette API. C’est un choix assumé, pas une omission.
Ce que cela dit de la direction d’Apple
NEURLFilter est une réponse à une question qui agite la sécurité informatique depuis des années : peut-on protéger sans surveiller ? L’architecture mise en place combine des techniques cryptographiques issues de la recherche académique, filtre de Bloom, PIR homomorphe, OHTTP, pour répondre oui à cette question dans un contexte opérationnel réel, sur des millions d’appareils.
Apple devient ici, pour la première fois, un intermédiaire neutre dans un système de filtrage. Le relais OHTTP qu’elle héberge n’est pas sous le contrôle du fournisseur de filtrage, et ne donne pas non plus à Apple une vue sur le contenu des décisions. C’est une architecture de confiance distribuée plutôt que centralisée.
Pour les utilisateurs de macOS 26, cela signifie que les applications de contrôle parental et de sécurité réseau qui adopteront NEURLFilter offriront une garantie cryptographique, pas seulement contractuelle, de non-surveillance de leur navigation. Pour les développeurs et les architectes de solutions MDM, c’est une infrastructure prête à l’emploi pour des politiques de filtrage précises et défendables.
La documentation complète de l’API est disponible sur Apple Developer Documentation. La session WWDC 2025 « Filter and tunnel network traffic with NetworkExtension » (session 234) est le point d’entrée technique recommandé pour les développeurs souhaitant implémenter NEURLFilter.
| Titre de la page du support technique | URL officielle | Date de publication |
|---|---|---|
| URL filters, Apple Developer Documentation | https://developer.apple.com/documentation/networkextension/url-filters | Juin 2025 |
| Filtering traffic by URL, Apple Developer Documentation | https://developer.apple.com/documentation/NetworkExtension/filtering-traffic-by-url | Juin 2025 |
| Filter and tunnel network traffic with NetworkExtension, WWDC25 session 234 | https://developer.apple.com/videos/play/wwdc2025/234/ | Juin 2025 |
| Filter content for Apple devices, Apple Support | https://support.apple.com/guide/deployment/filter-content-dep1129ff8d2/web | Mise à jour 2025 |
En savoir plus sur Les miscellanées Numériques
Subscribe to get the latest posts sent to your email.