Dernière mise à jour le 19/08/21.

Contexte

En ce début de mois d'août 2021, Apple annonça une série de mesures visant à protéger les enfants :

• Détection de contenu suggestif dans Messages
• Détection CSAM (Child Sexual Abuse Material) pour iCloud Photos
• Ressources additionnelles pour Siri et Search (anecdotique)

Nous avons eu droit récemment à des débats passionnés autour des efforts annoncés d'Apple contre le contenu pédopornographique. Malheureusement, certaines personnes - notamment sur les réseaux sociaux - saisissent l'occasion de la confusion générale pour avancer des inexactitudes, ce qui a le don de m'agacer particulièrement. Il est important de se poser des questions, mais il convient d'avoir les bons éléments en sa possession sans quoi l'on risque de décrédibiliser sa propre cause.

Ce présent article ne portera pas sur la pertinence des mesures concernant la lutte contre la pédopornographie, qui est un problème sociétal majeur. Je n'émettrai pas non plus mon avis sur cette question car je ne suis pas en mesure de le faire.

Sources

La seule et unique question que je me pose et à laquelle je tenterai de répondre est la suivante :

Est-ce que ces mesures sont réellement invasives envers notre vie privée ?

Pour ce faire, j'ai pris le temps de lire - outre les torchons qui s'entêtent à se recopier entre eux - les différents documents fournis par Apple et les chercheurs consultés :

• CSAM Detection — Technical Summary
• Expanded Protections for Children - Frequently Asked Questions
• Expanded Protections for Children - Summary
• Security Threat Model Review of Apple's Child Safety Features
• Apple’s CSAM detection technology - David Forsy
• Review of the Cryptography Behind the PSI System - Benny Pinkas
• AppleNeuralHash2ONNX (extraction présumée du modèle)

Conformément à ce que j'écrivais précédemment, je m'intéresse uniquement à des faits plutôt que de la spéculation parfois mensongère : ce qui n'empêche absolument pas de s'interroger sur les limitations et dérives de ces nouvelles mesures.

Il faut cependant garder à l'esprit que peu importe le modèle de disponibilité du code source, des chercheurs en sécurité s'empresseront de passer au peigne fin* ce qu'ils pourront une fois que la fonctionnalité sera mise en place sur les systèmes concernés. Une grande partie (mais pas l'entièreté) de ce qui est avancé par Apple dans ses whitepapers pourra être vérifiée, et Apple n'a donc aucun intérêt de mentir à ce sujet. Je partirai donc de ce principe, sans quoi la suite de cet article n'aurait aucun intérêt.

* Apple devrait néanmoins davantage travailler avec des chercheurs de sécurité indépendants. Des programmes du genre existent, mais il n'y a pas de moyen "facile" de plonger à l'intérieur de ce qui s'apparente à des boîtes noires. Cela constitue un axe d'amélioration qu'Apple doit étudier pour que son mécanisme de détection CSAM puisse être mieux appréhendé.

Détection de contenu suggestif dans Messages

En guise de contexte : sur iOS, l'application Messages est un client qui sert à la fois de client SMS mais également de client iMessage, le protocole maison d'Apple qui est chiffré de bout-en-bout (E2EE).

La première mesure annoncée concerne donc l'ajout de moyens de détection de contenu suggestif dans Messages.

Cette détection employant le machine learning se fait sur l'appareil. Il serait effectivement impossible d'effecter ce genre d'analyse sur un serveur distant puisque ce service est, et restera chiffré de bout-en-bout. Apple n'aura donc jamais accès au contenu du message ni à l'image en question (sous réserve que iCloud Backup n'est pas activé).

Ce mode de détection basé sur l'apprentissage intelligent permet de balayer un ensemble potentiellement infini d'images, avec évidemment son énorme lot de faux positifs. Il n'aurait pas été concevable que des autorités puissent se servir directement de ce mécanisme tant il est trivial d'abuser du fonctionnement des réseaux neuronaux : imaginez si vous pouviez envoyer votre pire ennemi en prison aussi facilement (si seulement !).

À la suite de la détection d'une image présumée suggestive, l'enfant est mis en garde en premier lieu. S'il a moins de 12 ans et qu'il accepte de voir le contenu malgré l'avertissement, une notification est envoyée à ses parents dont la famille a été préalablement configurée sur iCloud. S'il a entre 13 et 17 ans, cette notification n'est pas envoyée. Dans tous les cas, cette option de contrôle parental est opt-in.

Détection CSAM dans iCloud Photos

J'ai abordé la mesure précédente pour établir qu'il y a une nette distinction entre celle-ci et celle que nous allons désormais aborder, et qui a particulièrement fait couler beaucoup d'encre.

Apple a donc également annoncé dans la foulée l'arrivée d'un système de détection CSAM pour iCloud Photos. La sémantique est importante, puisqu'elle indique déjà que ce système concerne uniquement les photos mises en lignes sur iCloud (et Apple insiste bien évidemment sur cela dans ses documents).

Mais c'est pas vrai ! Ils vont analyser tous les iPhones !

Ce genre de remarque me laisse toujours pantois, et je vous réfère à ce que j'ai indiqué ci-dessus : il n'y a aucune raison, sauf preuve du contraire, que le système de détection CSAM sera étendu à tous vos fichiers.

J'aimerais également insister sur le fait que la détection de contenu pédopornographique ou illégal en général n'est pas une chose nouvelle pour les fournisseurs de services cloud. En effet, PhotoDNA est une technologie conçue par Microsoft qui est employée massivement depuis 2009 pour détecter ce genre de contenu sur les serveurs. iCloud Photos, tout comme ses concurrents, n'ont jamais été chiffrés de bout-en-bout : vous devriez partir du principe que tout ce qui vous y mettez en ligne est susceptible d'être directement analysé sur les serveurs concernés, à distance.

Ce qui change ici, c'est que la détection proposée par Apple se déroule au moins en partie sur l'appareil : c'est la réelle nouveauté notable. Cette détection hybride appareil/serveur vient bien sûr avec son lot de considérations en matière de vie privée, et il est légitime de s'interroger sur la nature des opérations effectuées sur votre appareil.

NeuralHash : source de confusions

Le système permettant de détecter une correspondance entre une image que vous vous apprêtez à mettre en ligne sur iCloud et une image connue à caractère pédopornographique repose sur la comparaison de hash entre ces deux images. Contrairement à Messages où le machine learning était directement utilisé dans le système de détection, ce n'est pas le cas ici (du moins pas directement) : les images à détecter sont connues d'avance et fournies à Apple par des organisations de protection des enfants.

Du hachage cryptographique au hachage perceptuel

Succinctement, une fonction de hachage en cryptographie est une fonction déterministe qui renvoie une valeur (aussi appelée le hash) pour une donnée. Une fonction de hachage fonctionne à sens unique : il n'est pas possible de retrouver la donnée à partir de la valeur obtenue.

Maintenant que les rappels sont faits, il va déjà falloir sortir des cas généraux. NeurelHash est un algorithme un peu atypique en effet, puisqu'il permet de générer des hash correspondants pour des images différentes mais suffisamment proches en termes de données pures (considérez que classiquement, un algorithme fonctionnerait au pixel/bit près). NeuralHash est sensible à des modifications telles que des changements de résolution, de compression, de bruit, ou encore de couleurs.

Il s'agit donc évidemment d'éviter des contournements basiques du système de détection, qui doit se montrer flexible dans une certaine mesure.

Conformément à l'exemple, NeuralHash génère un hash :

• Correspondant pour des photographies différentes mais très proches
• Différent pour des photographies évidemment différentes

Enfin ça, c'est la promesse faite par Apple.

Plus précisément, NeuralHash est une fonction de hachage perceptuelle, en opposition aux fonctions cryptographiques classiques qui reposent sur l'effet d'avalanche : la propriété selon laquelle un changement (d'un bit par exemple) aussi simple soit-il génère une valeur finale totalement différente, ce qui est l'effet souvent souhaité.

Ici, plutôt que de hacher en prenant compte des pixels exacts de l'image, NeuralHash utilise les propriétés géométriques de la représentation de l'image : la génération de vecteurs descripteurs se fait suivant la méthode LSH (locality-sensitive hashing), vecteurs ensuite convertis en nombres pour composer le hash final.

Ces vecteurs sont générés par un réseau neuronal qui s'entraîne lui-même à partir d'un ensemble d'images en effectuant des transformations sur celles-ci. Ce réseau neuronal apprend ainsi à générer des vecteurs qui seront proches entre eux et qui pourront produire un hash final qui correspond.

À la grande différence du mécanisme vu ci-dessus concernant iMessage, il ne s'agit pas ici de machine learning à proprement dit. Le réseau neuronal de NeuralHash ne s'entraîne pas particulièrement sur du contenu CSAM.

Une technologie qui n'est pas sans défauts...

Cette technologie n'est pas nouvelle et son efficacité doit être relativisée.

• Mathématiquement, il existera toujours un seuil à partir duquel des images pourtant similaires auront un hash différent. L'objectif pour les malins sera de trouver le plus petit changement possible permettant d'atteindre ce seuil.
• Des risques de collision existent et sont attendus pour de tels algorithmes : en d'autres termes, deux images qui n'ont rien à voir et produiront le même hash, ou à quelques bits près (assez probable).

On comprend déjà un peu mieux pourquoi la base de données est aveuglée (cf. partie suivante), du moins un de ses intérêts pratiques : si les hash CSAM sont connus, il serait plus simple de faire des attaques ciblées de collision compte tenu de la nature des algorithmes de hachage perceptuel.

Des petits malins ont vraisemblablement (ne pouvant pas vérifier moi-même) déniché un proof-of-concept de NeuralHash caché dans classes obfusquées d'iOS 14.3+. Son modèle MobileNetV3 a ensuite pu être exporté au format ONNX, nous permettant de nous amuser un peu avec ce qui semblerait être une version générique de NeuralHash qui génère des hash en 96 bits.

Cela nous permet d'effectuer quelques remarques préliminaires sur certains points qui étaient malheureusement attendus :

• NeuralHash semble effectivement sensible aux changements de taille et de compression, mais pas de rognage ou de rotation.
• Les hash produits sur différents appareils peuvent être différents : c'est un effet de bord classique et attendu dû à l'utilisation de réseaux neuronaux complexes à plusieurs couches.
• De la même façon, il ne serait pas rare de constater quelques erreurs mineures dans le calcul du hash.

D'un iPad Air 4 à un Mac M1 en passant par un iPhone 11, le hash pourrait donc différer : il serait intéressant de voir comment Apple prend en compte une telle marge d'erreur de quelques bits. Peut-être et sans doute avec une méthode de correspondance approximative (fuzzy matching) ; mais là, je commence à me gratter la tête en me demandant comment tout ce système peut bien fonctionner avec la partie suivante...

Chiffrement à double couche (two-layers encryption)

Vous savez désormais plus ou moins comment la correspondance se fait entre une image mise en ligne et une image connue. Cependant, cela ne répond pas vraiment encore à la question de la confidentialité et quels sont les moyens mis en place par Apple pour éviter des dérives.

Base de données "aveugle"

La base de données contenant les hash des images reconnues à caractère CSAM est fournie à Apple par NCMEC (National Center for Missing and Exploited Children) aux États-Unis, mais pas exclusivement. Apple clame que les hash retenus doivent provenir d'au moins deux sources différentes.

Cette base de données subit ensuite une série de transformations à l'issue de laquelle les données fournies sont chiffrées par une clé privée que Apple détient.

C'est donc une base de données aux hash obfusqués qui se retrouvera sur l'appareil de l'utilisateur final directement par la distribution d'iOS (aucun téléchargement additionnel n'est effectué). L'index est calculé à partir de la valeur du NeuralHash, et pointe vers un hash obfusqué correspondant, ou un hash aléatoire dont le seul but est de remplir la base de données (ce détail prendra sens par la suite).

Dans les faits, il est donc impossible pour les utilisateurs d'extraire la base de données pour posséder une liste exacte des NeuralHash qui intéressent Apple. Déjà parce qu'ils sont mélangés avec d'autres hash générés aléatoirement pour remplir les index non-utilisés, mais aussi et surtout car Apple dispose de la clé privée obfusquant les hash de contenus CSAM.

Private Set Intersection (PSI)

PSI est un procédé cryptographique en 2 étapes : d'abord sur l'appareil, puis sur le serveur distant. Au final, l'appareil est agnostique : il ne saura pas si match il y a eu lieu, et les serveurs d'Apple ont toujours un rôle.

Sur l'appareil, le hash de l'image mise en ligne sur iCloud est calculé avec NeuralHash. Ce hash obtenu est ensuite confronté à la base de données : il pointe entre autres (je passe quelques détails techniques) vers une position correspondante à un hash obfusqué par Apple, ou un hash aléatoire qui ne servira à rien en cas de non-match. En parallèle, une en-tête cryptographique est générée à partir du hash de l'image mise en ligne.

Une clé de dérivation obtenue à partir du hash obfusqué sera quant à elle utilisée pour chiffrer le payload ("charge utile" : tout ce qui ne relève pas forcément des métadonnées). L'ensemble compose un "bon de sécurité" (safety voucher) qui est envoyé sur les serveurs en même temps que l'image.

Enfin, une fois les données sur le serveur :

• S'il y a correspondance entre le hash de l'image mise en ligne et le hash d'une image CSAM, Apple sera en mesure de déchiffrer le payload à l'aide de sa clé privée (qui été prélablement utilisée pour masquer le hash CSAM) combinée à l'en-tête cryptographique du bon de sécurité.
• Cependant, s'il n'y a pas correspondance, le système est tel qu'Apple ne pourra utiliser la clé de dérivation (le hash n'ayant aucun rapport et inconnu d'Apple), et est donc incapable de connaître des information à propos d'images qui ne correspondent pas.

Comme je l'expliquais plus haut, l'appareil lui-même est agnostique : il ne connaît pas la nature du résultat du final puisque la clé privée utilisée pour "aveugler" la base de données est seulement connue d'Apple.

Threshold Secret Sharing (TSS)

PSI est combiné à TSS, une seconde couche de chiffrement. TSS permet à Apple de définir un seuil de détections CSAM (entre autres critères) à partir duquel Apple sera en mesure de pouvoir exploiter les données et de les déchiffrer. TSS repose sur un algorithme de reconstruction qui nécessite plusieurs "morceaux de clé" pour pouvoir procéder au déchiffrement.

Par "morceaux de clé", je simplifie volontairement. TSS repose sur le concept cryptographique du secret réparti qui permet de distribuer des informations sur un secret à différents dépositaires. Une information individuelle sur le secret n'a aucune utilité : mais combinée à suffisamment d'informations, le secret pourra être reconstitué.

Pour ce faire, chaque utilisateur dispose d'une clé de chiffrement générée sur l'appareil et inconnue d'Apple. Toutes les informations utiles au système de détection dont le hash sont chiffrées avec cette clé. Enfin, une information à propos de cette clé (qui, encore une fois, n'a aucune utilité quand elle est isolée) est envoyée aux côtés du payload généré et chiffré par PSI : TSS forme ainsi une seconde couche effective de chiffrement.

Craig Federighi (VP Software Engineer - Apple) mentionne dans le Wall Street Journal que le seuil est fixé à environ 30 détections CSAM.

Pour résumer...

PSI est la couche externe qui opère lors de la correspondance proprement dite des hash. Si correspondance est faite, Apple dispose des données suffisantes pour déchiffrer cette partie.

TSS est la couche interne garante du respect de certains critères, en l'occurrence du seuil de détections CSAM pour un utilisateur à partir duquel Apple estime qu'il est nécessaire de prendre une action. Ce seuil ne peut être contourné car c'est un processus cryptographie : Apple doit attendre de récolter suffisamment d'informations pour reconstituer la clé nécessaire.

Une fois que PSI (match ?) et TSS (seuil ?) sont passés, Apple a accès au bon de sécurité contenant des informations sur la photo mise en ligne. Il y a également une étape de vérification manuelle, même si Apple a l'air visiblement très sûr de son coup en annonçant que ce système aurait une probabilité de faux positif d'1 sur 1 billion (1 "trillion" pour les anglo-saxons, soit 10¹² = 1 billion pour nous j'imagine).

Apple serait en théorie en mesure de pouvoir compter le nombre de détections CSAM sans pour autant accéder au bon de sécurité. Il a donc été mis en place un système de bons synthétiques envoyés occasionnellement par l'appareil qui contient évidemment des données factices et un faux morceau de clé.

Ainsi, Apple n'est pas en mesure de déterminer avec certitude le nombre de détections CSAM pour un utilisateur. PSI est également le garant cryptographique du fait qu'Apple n'aura aucune information à propos d'images qui ne correspondent pas.

Réflexions et considérations

Apple n'a pas lésiné sur le sujet, et peu importe notre position sur la pertinence de ces mesures, nous pouvons reconnaître leur attachement à une cryptographie de pointe qui n'est pas sans rappeler les vertus vantées de la confidentialité différentielle. Ceci étant, des interrogations sont légitimes sur des dérives potentielles.

Comment peut-on être sûr que la détection CSAM ne s'appliquera qu'aux images mises en lignes sur iCloud ?

J'ai un sentiment de déjà-vu en évoquant cette question. Pour l'instant, il n'est clairement pas dans l'intention d'Apple d'étendre ce système à d'autres types de contenus, et encore moins à du contenu qui ne sera pas mis en ligne sur iCloud. Apple semble insister que leur méthode de détection qui se fait partiellement sur l'appareil est supérieure à ce qui se fait déjà, mais sur des serveurs distants.

Dans tous les cas, Apple est maître de ce qui se passe sur ses serveurs, et vous devriez partir de ce principe pour tout service qui n'est pas chiffré de bout-en-bout (la liste est disponible ici pour iCloud). Nous avons vu que PhotoDNA est une technologie déjà massivement employée de cette façon.

Si Apple venait à scanner frénétiquement tout le contenu des iPhones comme certains aiment à le penser, ne doutez pas une seconde que des chercheurs en sécurité le sauront. Tout la partie de détection CSAM qui se passe sur l'appareil peut et pourra être passé au peigne fin. Par contre, ce serait plus simple si Apple faisait un peu moins chier lesdits chercheurs en sécurité.

La base de données est-elle susceptible d'évoluer au-delà de contenus CSAM fournis par des organisations ?

Apple clame que non : la base de données serait pour l'instant seulement alimentée par des organisations telles que NCMEC aux États-Unis. Là je me demande : comment en être sûr ? Même si au fond, la même interrogation se pose pour les formes de détection sur serveur comme PhotoDNA.

Sur la question de savoir si des gouvernements pourront demander à Apple d'aliment la base de données, Apple indique qu'il refusera toute demande du genre. Toutefois, j'ai mes doutes si la Chine ou autre pays autoritaire se contentera d'une réponse négative (dans ce cas, les dérives peuvent être considérablement graves).

En conclusion, on doit faire confiance à Apple sur de nombreux aspects, et ça me gêne un peu pour être honnête. Il faudrait songer à un moyen de rendre ce système de transmission encore plus transparent, même si cela contrevient au principe de la base de données aveugle.

Quelques éléments de réponse :

• Craig Federighi (VP Software Engineer pour Apple) mentionne la possibilité d'audits indépendants. Ok, mais en pratique ?
• Apple insiste que les images dont les bons de sécurité ont été déchiffrés sont systématiquement vérifiées manuellement par du personnel humain qui ne laissera pas passer du contenu non-CSAM.
• Les hash intégrés par Apple à la base de données doivent être communs à au moins deux listes fournies par des organisations différentes : la base de données traitée est la résultante d'une intersection entre plusieurs listes.
• La base de données est distribuée directement par iOS qui est lui-même bien entendu signé : elle n'est pas téléchargée ou obtenue autrement.
• Par soucis de transparence, Apple semble avoir l'intention de publier les hash-sommet (root hashes) des bases de données CSAM pour chaque version d'iOS, dans une Knowledge Base publique.

Je ne saurais dire personnellement si cela suffira.

Est-ce que des innocents seront ennuyés par les autorités à cause de ce système ? À quels types d'attaques doit-on s'attendre ?

A priori, pas plus qu'un système de détection sur serveur.

Apple insiste que le processus de report aux autorités n'est pas automatique, et qu'une vérification manuelle est faite de leur côté une fois les conditions réunies (PSI + TSS).

Une attention particulière a été apportée (selon Apple) à des potentielles attaques ciblées qui pourraient tromper NeuralHash. Cependant, le risque zero n'existe pas et personne n'est dupe. Je mettrai peut-être à jour cet article avec des idées d'attaques hypothétiques contre NeuralHash.

Un scénario peut être imaginé dans lequel un attaquant réussit à faire envoyer suffisamment d'images en collision avec les hash CSAM. Et effectivement, ça n'a pas tardé car des collisions intéressantes ont été constatées depuis le modèle extrait sur les versions actuelles d'iOS. Mais ça ne veut pas dire grand chose : pour casser un algorithme de hachage, il faut savoir comment créer une collision plutôt que d'en trouver une (ce qui n'est pas rare pour du hachage perceptuel). Une question de temps ?

Il n'est pas si anodin d'imaginer un scénario dans lequel l'attaquant aura déjà à sa disposition du contenu CSAM ; à partir de ce contenu probablement connu des organisations, il pourra générer un hash, trouver une collision avec une image visuellement/humainement différente, et envoyer suffisament de ces images à sa victime ne se doutant de rien.

De plus, je suis très sceptique quant au fonctionnement de NeuralHash qui devrait impliquer de la correspondance approximative (tolérant plusieurs bits d'erreurs dans le hash généré sur l'appareil) avec les procédés cryptographiques comme PSI. Nous devrons peut-être attendre la version finale pour constater si Apple a volontairement omis des détails.

Est-ce que ce système ne s'applique qu'aux États-Unis ?

Pour l'instant, il semble que oui. Apple indique toutefois que ce système est destiné à s'étendre dans le futur.

Quand est-ce que ce sera mis en place exactement ?

Apple indique sans plus de précisions que ces mesures feront parties d'une mise à jour distribuée pour iOS 15, iPad OS 15 et macOS Monterey.

Est-ce qu'on peut dire que je ne possède plus vraiment mon appareil ?

Question légitime qui ne se pose pas vraiment quand les analyses sont faites sur des serveurs distants. Ici, la détection prend place sur du matériel que l'on possède, ce qui pose la question : est-ce qu'on loue l'appareil à Apple plus qu'on ne le possède vraiment ?

Je n'irais pas jusque-là, car comme vous le savez maintenant, je n'aime pas les grandes phrases sans vraiment de sens. Je dirais que ce système est cohérent avec la politique de traitement local d'Apple, de plus, n'importe quelle application sur n'importe quelle plateforme est susceptible de faire la même chose dans une certaine mesure.

Pourquoi Apple fait ça maintenant ?

Ce thread Twitter apporte à mon avis des éléments de réponse intéressants. Il faut d'abord savoir qu'aux États-Unis ainsi que d'autres pays, le simple fait d'avoir en sa possession des images à caractère pédopornographique est passable d'une sanction pénale.

Ce qu'Apple propose avec ce système de détection sur appareil pourrait être le meilleur compromis auquel ils auraient pu effectivement penser. Apple a effectivement un historique favorable au traitement local des données : par exemple, contrairement à Google Photos, l'apprentissage d'iCloud Photos se faisait déjà principalement sur l'appareil plutôt que sur les serveurs d'Apple.

Est-ce que c'est une étape vers le chiffrement de bout-en-bout d'iCloud Photos et d'autres services iCloud ?

Un argument peut être fait qu'Apple projette de rendre de plus en plus de services E2EE (chiffrés de bout-en-bout), dont iCloud Photos, et que ce système de détection était la seule possibilité convenue avec les autorités pour qu'une telle évolution puisse voir le jour. Cela reste hypothétique, bien évidemment ; et il s'agirait dans tous les cas d'un E2EE affaibli puisqu'Apple doit bien posséder une clé privée utilisable pour accéder au contenu détecté...

"I hate to be that guy"

Apple ne fait évidemment pas dans la charité, et ses discours sur la vie privée sont tout sauf des discours humanitaires : il y a un but derrière, celui de conforter leurs utilisateurs dans l'alimentation de leur modèle économique en les incitant à rester dans leur écosystème. Rien de neuf, c'est bien l'Apple que l'on connaît.

Je ne comptais pas vraiment écrire cet article, mais je m'y sentais obligé en quelque sorte. J'ai précédemment ouvertement recommandé des appareils Apple, les considérant généralement comme de très bons compromis par rapport au "reste qui ne fait pas mieux et souvent pire". Je suis moi-même utilisateur d'appareils Apple (bien que n'utilisant pas leurs services iCloud), donc je suis directement concerné.

C'est finalement un cas d'école : de nombreux médias se sont recopiés entre eux sans vérifier les informations, si bien que l'information de base s'en est retrouvée déformée. NeuralHash est devenu un système de machine learning pour certains, et la confusion entre iCloud Photos et les données locales d'un iPhone fut également assez pénible à constater. La faute est également en partie imputable à Apple : qui va sérieusement lire leurs dizaines de pages de whitepapers ? Pas grand monde, et je me dis qu'ils auraient pu forcément mieux gérer la communication à ce sujet.

Cela dit, le phénomène d'echo chamber médiatique et des réseaux sociaux est complètement responsable de cette confusion également : priorité à l'information "choc" et au format de la pensée "fast food", aux grands titres racoleurs, aux tweets destinés à amasser les partages, si bien qu'il est difficile de trouver la véritable information pour le néophyte qui se retrouve au milieu d'un véritable champ de bataille.

Pour être clair, je ne défends pas non plus Apple dans l'histoire et ce serait avoir mal compris ma démarche : je souligne qu'on ne peut pas indéfiniment porter une critique sans que celle-ci n'adopte une approche basée sur l'évidence des faits.

Concernant les mesures pour la protection des enfants elles-mêmes, je me refuse d'évaluer leur pertinence car ce n'est pas ma place et je n'ai pas de données sur lesquelles fonder une opinion qui va au-delà de mon intuition. Si vous tenez réellement à votre vie privée, vous devriez déjà faire attention aux services en ligne que vous utilisez. Encore une fois, cette mesure n'affecte que iCloud Photos que vous pouvez désactiver complètement. Pas tout le monde ne le sait évidemment, et beaucoup se retrouveront sous le joug de la détection CSAM sans même le savoir (et si vous avez suivi jusque-là, ça se fait déjà sur des serveurs distants).

Espérons simplement qu'elle soit aussi robuste en pratique qu'elle ne l'est en théorie, et qu'Apple ne cédera pas à des demandes de gouvernements autoritaires et que ses mesures de transparence seront efficaces.

Il faudra également attendre la version mise en production pour voir la réponse d'Apple à certaines zones d'ombre, notamment les défauts inhérents au hachage perceptuel qui implique l'utilisation d'un facteur d'approximation (et à voir comment il s'assemblera avec PSI) et des risques évidents de collisions qui pourraient être utilisées dans des scénarios d'attaques ciblées.

Bien que je refuse de donner un avis tranché, je partage mon inquiétude.

Je conseille évidemment de désactiver iCloud Photos pour toute personne potentiellement ciblée par certains acteurs. Si vous cherchez une solution pour remplacer iCloud Photos, je ne peux que vous conseiller la "moins pire" des solutions qui est Nextcloud et qui fonctionne très bien sur iOS. Si vous cherchez malgré tout à remplacer votre iPhone, je vous conseille de jeter un coup d'oeil à ce que propose GrapheneOS.

The screeching voice of the minority.