La fonction de transfert de données distant d’Apple Photos dans iOS 18 et macOS 15

• Photos dans iOS 18 et macOS Sequoia a ajouté Enhanced Visual Search, et la fonction était activée par défaut sur l’iPhone et le Mac de l’auteur
• Cette fonction aide à la recherche en mettant en correspondance de manière privée les monuments et points d’intérêt présents dans les photos avec un index mondial sur les serveurs d’Apple
• Apple explique empêcher l’accès aux informations des photos grâce au chiffrement homomorphe, à la confidentialité différentielle et à des relais OHTTP, mais la communication avec les serveurs est en soi au cœur du débat sur la protection de la vie privée
• Les critiques ne portent pas sur une intention malveillante d’Apple, mais sur la possibilité de bugs logiciels, en s’appuyant sur le fait que des vulnérabilités continuent d’apparaître dans les notes de publication de sécurité d’Apple
• Sur macOS, Little Snitch permet de bloquer dans une certaine mesure ces communications, mais iOS n’offre pas d’option équivalente, ce qui rend difficile pour l’utilisateur de se protéger lui-même

---

Activation par défaut d’Enhanced Visual Search

• Un nouvel élément appelé Enhanced Visual Search a été ajouté aux réglages de Photos sur l’iPhone, et il était activé par défaut
• Le même réglage a aussi été ajouté dans Photos sur macOS Sequoia, et il était également activé par défaut sur Mac
• L’auteur avait désactivé manuellement ce réglage avant de prendre les captures d’écran

Fonctionnement décrit dans la documentation d’Apple

• Le document Photos & Privacy d’Apple indique qu’Enhanced Visual Search permet de rechercher des photos par monument ou point d’intérêt
• L’appareil met en correspondance, de manière privée, les lieux présents dans les photos avec l’index mondial des serveurs d’Apple
• Apple indique utiliser les technologies suivantes pour protéger les données personnelles

  • Chiffrement homomorphe

  • Confidentialité différentielle

    • Un relais OHTTP qui masque l’adresse IP
    • D’après la documentation d’Apple, ce réglage peut être désactivé sur iOS et iPadOS via Settings > Apps > Photos, et sur Mac via Photos > Settings > General
    • L’article d’Apple Machine Learning Research Combining Machine Learning and Homomorphic Encryption in the Apple Ecosystem a été publié le 24 octobre 2024, tandis que la sortie publique générale d’iOS 18 et de macOS 15 a eu lieu le 16 septembre 2024

Critiques sur la protection de la vie privée

• Le point de départ de la critique est qu’Apple a amélioré l’expérience sur l’appareil au moyen de communications serveur, sans demande de l’utilisateur
• Selon le critère de l’auteur, une opération n’est privée que si elle s’achève entièrement sur l’appareil ; si des données sortent vers les serveurs du fabricant, il est difficile de la considérer comme totalement privée
• L’auteur précise qu’il ne peut pas évaluer directement si l’implémentation d’Apple est techniquement sûre
• Cependant, parce que des vulnérabilités continuent d’apparaître dans les notes de publication de sécurité d’Apple, il estime difficile de faire confiance telles quelles aux affirmations d’Apple sur la confidentialité
• La critique est que, même sans malveillance ni complot, de simples bugs logiciels peuvent rendre les utilisateurs vulnérables, et qu’Apple ne peut pas garantir des logiciels sans bugs

Choix de l’utilisateur et outils de blocage

• L’auteur n’ayant aucun intérêt pour Enhanced Visual Search, il considère que même si la fonction fonctionnait parfaitement, il n’aurait aucun bénéfice à accepter ce risque
• Le fait d’activer une fonction sans l’autorisation de l’utilisateur est critiqué comme un manque de respect envers l’utilisateur et ses préférences
• Il affirme que le slogan publicitaire d’Apple « What happens on your iPhone, stays on your iPhone. » ne correspond pas à ce cas
• Sur macOS, Little Snitch permet généralement de bloquer les communications distantes des logiciels Apple
• Sur iOS, les outils comme Little Snitch ne sont pas autorisés, ce qui donne le sentiment qu’Apple empêche les utilisateurs de se protéger eux-mêmes

Ressources ultérieures

• Dans un addendum du 1er janvier 2025, l’article de suivi The internet is full of experts et la synthèse de Michael Tsai sont également présentés

[GN⁺]

Avis de Hacker News

• Ce que je veux est très simple : je veux un logiciel qui n’envoie rien sur Internet tant qu’il n’y a pas d’intention explicite
  Le travail d’ingénierie visant à rendre cette fonctionnalité plausiblement privée est remarquable, et le fait même d’implémenter ce genre de fonctionnalité n’est pas un problème, mais elle doit impérativement être opt-in
  Tant que les logiciels traiteront l’utilisateur final, ses données et des ressources comme sa connexion réseau comme un terrain de jeu pour le fournisseur, la confiance continuera de s’éroder. Les données d’un appareil local ne doivent pas fuir de manière inattendue au-delà de l’interface sans fil, et toute fonctionnalité qui envoie des données locales sur le réseau doit nécessairement être liée à une intention de l’utilisateur
  La réponse cynique à la question de savoir pourquoi Apple n’a pas simplement demandé aux utilisateurs s’ils voulaient activer cette fonctionnalité, c’est qu’Apple sait que certains utilisateurs refuseraient immédiatement si on leur posait la question, mais estime en savoir plus qu’eux. Je n’aime pas cette attitude, et je pense que c’est aussi la raison pour laquelle le mécontentement envers la télémétrie en opt-out grandit

  • C’est ce genre de raisonnement qui a donné naissance aux terribles bannières de cookies
    Ajouter encore plus de boîtes de dialogue sur lesquelles la plupart des utilisateurs cliqueront machinalement sur « Autoriser » ne résout pas le problème
    La société a, de fait, accepté qu’il était normal de céder à des tiers l’accès aux données, et ajouter de la friction revient à punir 98 % des gens pour les 2 % qui, de toute façon, n’utiliseraient pas ce type de services
    Avec un public mieux éduqué, l’équilibre pourrait peut-être changer, mais ce n’est pas la réalité, et une bonne expérience utilisateur doit refléter la réalité
  • L’opt-in ne fonctionne pas, et n’a jamais fonctionné
    L’écrasante majorité des utilisateurs, plus de 95 %, ne comprend pas ce que signifient les pop-ups, semble même ne pas avoir la capacité de les lire, et accepte toujours, refuse toujours, ou clique sur le bouton le plus visible
    Observez des membres de votre famille qui ne travaillent ni dans la tech ni dans les professions de management qualifiées, puis demandez-leur ce qu’était la pop-up qu’ils viennent de fermer et pourquoi ils l’ont fermée : vous en tirerez la meilleure leçon possible sur l’interaction entre technologie et vie privée
  • Les Photos iOS permettent depuis longtemps de rechercher des photos par l’adresse où elles ont été prises
    Pour cela, il faut récupérer la latitude/longitude du lieu de la photo et la convertir en adresse compréhensible par un humain, ce qui passe presque toujours par une requête à un service mondial de géocodage inverse
    Je me demande si vous considérez aussi cette fonctionnalité comme une atteinte à la vie privée nécessitant un opt-in. Sinon, je ne vois pas en quoi un service de géocodage inverse serait plus privé qu’un service de recherche de points d’intérêt
  • Le résultat, c’est quelque chose comme https://chromewebstore.google.com/detail/i-still-dont-care-a...
    Personnellement, je ne crois pas que ces pop-ups atteignent un quelconque objectif. Au final, il est impossible de prouver raisonnablement qu’un site web agit de bonne foi. Ce n’est pas parce qu’une app demande si elle peut contacter un serveur que cliquer sur « non » garantit que le suivi sera réellement bloqué
    Je reste surpris de voir à quel point on se convainc que la protection de la vie privée à grande échelle peut fonctionner avec diverses combinaisons de boutons oui/non. Il n’y a que deux façons de faire confiance à un logiciel : 1. croire naïvement à la mention « privacy first » écrite quelque part 2. comprendre jusqu’aux instructions que le logiciel en cours d’exécution peut exécuter
    Les pop-ups de permissions manquent aussi de granularité. Quand on autorise l’accès à la liste de contacts, à quels contacts accède-t-on réellement ? Peut-on autoriser seulement les noms et bloquer les numéros de téléphone ? Le traitement se fait-il hors ligne ou en ligne ? S’il est en ligne, faut-il afficher une autre pop-up d’accès à Internet ? Et dans ce cas, doit-on aussi pouvoir filtrer le type d’activité Internet effectuée ? En descendant ainsi, on finit par arriver à un système de permissions Turing-complet ; sinon, la « vie privée » comporte des failles
  • Même avec de l’opt-in, les fournisseurs continueront à harceler l’utilisateur jusqu’à ce qu’il clique sur « oui » dans un moment d’inattention
    J’ai même clairement déjà vu des cases que je n’avais pas cochées se retrouver cochées. J’aimerais pouvoir désactiver tout ça et empêcher que ce soit réactivé un jour, mais les fournisseurs ne le permettront évidemment pas. C’est pour ça que j’utilise Linux

• Les utilisateurs de mon application open source gratuite semblent surpris d’apprendre que nous n’avons absolument aucune visibilité sur leurs usages
  Il y a des situations où une petite quantité de télémétrie anonyme serait extrêmement utile, mais je n’ai pas l’intention d’y toucher
  L’opt-in ne se contente pas de réduire fortement le volume de données : il introduit aussi un biais important dans les données sélectionnées, au point de les rendre inutilisables. Les personnes qui accepteraient ne seraient probablement pas un bon échantillon de « l’utilisateur typique »
  L’opt-out, même avec des garde-fous ou des garanties, est inacceptable pour certains utilisateurs, qui le feront savoir avec vigueur
  Je comprends qu’un acteur malveillant puisse facilement abuser de la télémétrie, et que des « données anonymes » puissent se révéler, de façon surprenante et de multiples manières, pas anonymes du tout. Mais j’ai tout de même ce regret du genre « voilà pourquoi on ne peut pas avoir de bonnes choses »

  • Je ne me souviens plus où j’ai vu ça, mais il y avait un site qui collectait les données d’analyse côté client dans une sorte de tampon circulaire, et permettait depuis le menu des paramètres de les envoyer une seule fois, de toujours les envoyer, ou de les télécharger soi-même
    En cas d’erreur, un toast demandait de partager les données d’analyse pour aider au dépannage, avec bien sûr la possibilité de refuser. C’était probablement le meilleur système que j’aie vu, mais je ne me souviens plus de quel site il s’agissait
  • Le point essentiel, c’est que tout relève du consentement. Sans opt-out, il n’y a pas vraiment de consentement ; si l’opt-out est l’option par défaut, la qualité du consentement chute fortement. La confiance est le seul chemin vers le consentement
    1. Pour instaurer la confiance, il faut trois voies : opt-in, consentement sous forme de questionnaire, et opt-out. Le questionnaire est un validateur actif de la confiance et facilite une communication à faible bande passante. La question doit être posée au premier usage, ou au prochain lancement de l’app après l’ajout de cette fonctionnalité
    2. Il faut fournir aux utilisateurs finaux les informations d’analyse exactes souhaitées, afin qu’ils puissent eux aussi les analyser. Proposer un rapport ou une vue qui leur permette d’évaluer eux-mêmes les informations dont le partage est autorisé améliore la confiance
    3. Une autorisation accordée en confiance mène à davantage de consentement. On peut aussi orienter le support prioritaire sur les fonctionnalités et les bugs pour les utilisateurs ayant accepté. L’historique d’analyse et les informations de performance peuvent aider à résoudre un bug qui vient d’être signalé
       Apple, Microsoft, Google, etc. traitent le partage d’analyses de manière vague, sans détails, et sans expliquer clairement comment ces données peuvent être utilisées ou détournées. La plupart ne proposent même pas d’opt-out. Je ne fais pas confiance à ces organisations, mais je dois les côtoyer dans ma vie. Je peux me passer de Facebook ou Twitter, et c’est effectivement ce que je fais. Les enquêtes Steam, je les accepte
       Pour résoudre le manque d’informations d’analyse dont la communauté open source pourrait bénéficier, un RFC de standard d’analyse accepté serait une étape possible. Ce serait une façon pour les deux parties de consentir à une communication convenue
       De mon point de vue, les métadonnées sont aussi des données personnelles. Sans utilisateur, il n’y a ni données ni métadonnées. L’utilisateur final étant l’entropie des métadonnées, le propriétaire des métadonnées comme des données est l’utilisateur
  • Je me demande si l’on ne pourrait pas collecter les statistiques sur l’appareil, puis afficher tous les quelques mois une fenêtre contextuelle montrant ces statistiques
    Je ne sais pas très bien quel biais cela ajouterait
    Par exemple, on demanderait : « Nous avons créé cette application et la confidentialité compte pour nous. Voici les informations collectées pendant votre utilisation le mois dernier. Pouvons-nous nous les envoyer pour améliorer l’application ? », en affichant les données collectées sous une forme lisible par un humain
  • Il n’est pas évident de comprendre pourquoi l’opt-in rendrait les données inutilisables. Cela peut aussi dépendre de la façon dont l’opt-in est présenté
    En général, je m’attendrais à ce que ce soit une solution praticable. Même si le groupe opt-in diffère de « l’utilisateur typique », ce sont les meilleures données que l’on puisse obtenir de façon honnête et éthique. Cela devrait tout de même être mieux que de n’avoir aucune donnée
    Tous les sites web et applications qui affichent une bannière de consentement opt-in pour les cookies fonctionnent déjà implicitement dans cet état
  • C’est l’une des principales raisons pour lesquelles les gens construisent généralement sur le web
    Il est très difficile d’améliorer un logiciel desktop, et les utilisateurs Linux, en particulier, ont tendance à être hostiles aux schémas qui permettraient ces améliorations

• D’accord à 100 % :
  « Le seul moyen de garantir la confidentialité en informatique, c’est de ne pas envoyer les données hors de l’appareil »
  « Le niveau de risque d’atteinte à la vie privée que l’on accepte devrait être décidé par chaque utilisateur. [...] En activant une “fonctionnalité” sans même demander, Apple ne respecte ni ses utilisateurs ni leurs préférences. Je n’ai jamais voulu que mon iPhone contacte des serveurs Apple. »
  Peu importe à quel point la fonctionnalité est obfusquée, « sûre » ou autrement « protectrice de la vie privée » : cela ne change rien au fait que des informations dérivées de contenus personnels sont transmises sans consentement préalable.
  Même si l’information est protégée, toute requête réseau est une information. Un horodatage indiquant qu’une action précise a été effectuée à un moment donné ; par exemple, si quelque chose est envoyé à ce service juste après l’ajout d’une nouvelle photo, cela peut révéler qu’une photo a été prise, un lieu précis corrélé aux données de localisation à ce moment-là, etc. — et ce n’est que la partie émergée de l’iceberg. Transmettre des informations depuis l’appareil d’un utilisateur sans consentement explicite constitue une atteinte à la vie privée.

  • Cela veut-il dire que les messages Signal ne sont pas sûrs parce qu’ils sont eux aussi transmis, et que l’« obfuscation » ne suffit pas à protéger les données ? Je me demande si l’auteur a lu ce qu’Apple dit réellement faire aux données avant leur transmission — passage qu’il cite, puis admet plus tard ne pas comprendre.
    L’argument sur les métadonnées me semble possible, mais il repose lui aussi sur plusieurs hypothèses. En particulier, il faut supposer qu’Apple n’utilise pas réellement OHTTP et conspire pour savoir quand l’utilisateur a pris une photo. En fait, si l’on ne fait pas confiance aux mathématiques, je ne vois pas où s’arrêtent l’incertitude et la suspicion.
  • La prémisse « comme pour prendre une photo, supposons que quelque chose soit envoyé à ce service dès qu’une nouvelle photo est ajoutée » est fausse, et la conclusion saute à partir de là.
    Il est facile de vérifier que cela ne se produit pas immédiatement après la prise d’une photo. Premièrement, le trafic réseau le montrerait, et en réalité ce n’est pas le cas. Deuxièmement, le chiffrement homomorphe est coûteux, donc ce n’est pas faisable de cette manière. Photos ne synchronise généralement pas immédiatement, et on le voit au fait que la plupart des utilisateurs d’iPhone constatent dans l’app Photos quand la synchronisation a lieu. Les tâches coûteuses sont en général mises en file d’attente jusqu’à ce que l’appareil soit branché sur secteur et connecté au Wi‑Fi.
  • Quelle capacité faudrait-il pour stocker tous les lieux connus du monde et les modèles d’objets courants ?
    Par exemple, j’ai envoyé à une amie une photo d’un chien dans une baignoire, et ses AirPods lui ont annoncé via l’iPhone que « quelqu’un a envoyé une photo de chien dans une baignoire ». Mon amie a trouvé ça génial, et personnellement je trouve aussi la fonction utile. Je ne sais simplement pas dans quelle mesure cela nécessite un traitement hors de l’appareil.
  • Tous ces problèmes sont abordés dans le billet de blog d’Apple sur l’implémentation de cette fonctionnalité. Deux mesures sont appliquées pour réduire les risques :
    1. iOS génère des requêtes factices supplémentaires, et toutes les requêtes passent par un ordonnanceur qui empêche de distinguer les vraies requêtes des requêtes factices à partir de l’heure de consultation, ou d’identifier le moment de la prise de vue.
    2. Toutes les requêtes sont effectuées anonymement via un service relais tiers. Apple ne peut donc pas relier une requête donnée à un appareil ou à une adresse IP spécifique.
       Avec ces deux mesures d’atténuation, pour obtenir des données personnelles via cette fonctionnalité, il faudrait d’abord compromettre le téléphone de la cible afin de désactiver les requêtes factices, puis compromettre le relais pour corréler les requêtes à une adresse IP donnée.
       Si l’on peut faire tout cela, honnêtement, ce serait une perte d’efforts absurde : autant utiliser la compromission d’iOS pour faire envoyer directement les données de localisation par l’appareil. Il n’y a pas besoin d’attendre que la cible prenne une photo, de suivre plusieurs recherches de monuments, et de collecter un peu plus de données à chaque requête pour finir par identifier sa position.
       Tout cela me fait penser à XKCD 538.
       https://machinelearning.apple.com/research/homomorphic-encry...

• J’ai l’impression que c’est peut-être un écran de fumée pour réintroduire lentement le scan CSAM après le tollé de la dernière fois. Le fait que ce comportement soit activé par défaut est suspect.
  [1] https://www.wired.com/story/apple-photo-scanning-csam-commun...

  • Je pense exactement la même chose. Ça ressemble à : « Nous avons une technologie astucieuse d’empreintes d’images, mais son usage pour détecter le CSAM est trop controversé pour être lancé ; mettons donc le flux central dans quelque chose qui semble utile aux utilisateurs, afin que le code reste vivant, s’améliore et soit prêt à être étendu plus tard. »
    La question de savoir si ce type d’empreinte peut être limité de manière fiable aux monuments publics est intéressante, et dépend de détails d’implémentation qui ne sont pas clairs.
    Même si la recherche visible par l’utilisateur est limitée aux « monuments », le processus prépare-t-il, ne serait-ce que sur l’appareil, des empreintes de beaucoup d’autres choses ? Si oui, un malware non persistant activé brièvement pourrait immédiatement trouver des images d’intérêt, sans avoir besoin de l’accès plus large ni du traitement supplémentaire qui auraient normalement été nécessaires.
  • Oui. C’est une façon d’injecter un élément de contact serveur sous prétexte de « correspondance de localisation » apparemment inoffensive.
    L’index global correspondra évidemment aussi à d’autres marqueurs qu’Apple juge pertinents, même s’ils ne sont pas renvoyés à l’utilisateur.
  • C’est exactement la même manière dont Microsoft a « reculé » sur Recall. Puis ils ont fini par le réintroduire et le rendre impossible à supprimer.
  • Je pense pareil. La technologie était probablement trop coûteuse, et ils avaient besoin de la tester ou de la faire tourner pour prouver qu’elle était privée.
    J’aurais tendance à penser qu’un modèle permettant de trouver des monuments dans des photos peut aussi s’exécuter localement, mais je n’en suis pas sûr à 100 % ici.
  • Non. Quels que soient les autres défauts d’Apple, je ne pense pas que ce soit ça.
    Pour donner une raison cynique : une fonctionnalité d’ingénierie de cette ampleur ne peut pas être planifiée sans documentation, et ces documents ressortiraient forcément au tribunal.
    La raison apparente est qu’Apple veut sincèrement proposer une fonctionnalité utile nécessitant une participation côté serveur.

• À propos du fait de ne pas comprendre la plupart des détails techniques du billet du blog d’Apple : j’ai compris les passages cités, et désolé, mais cet article aurait pu être optimiste. Du genre « Regardez cette superbe nouvelle technologie ! »
  Je déteste autant que les autres les pratiques d’Apple qui vont à l’encontre des hackers au sens de HN, et pour ces raisons, entre autres, je ne possède même pas d’appareils Apple. Mais dire « peu importe comment ils ont résolu le problème de confidentialité, je n’ai pas l’impression que ce soit privé » ne crée pas un fait.
  La plupart des autres gens ne comprennent pas non plus les termes cités, et il n’est même pas certain qu’ils aient lu jusque-là ; cela ressemble donc à une critique injuste.

  • Le chiffrement homomorphe, j’en ai entendu parler il y a quelques années dans des articles de recherche.
    D’après ce que j’en avais compris à l’époque, des opérations comme SUM pouvaient calculer la somme d’une liste de nombres chiffrés. Grâce au mode de chiffrement, on pouvait additionner toutes les valeurs sans les déchiffrer, et le résultat restait chiffré ; son propriétaire pouvait ensuite le déchiffrer pour obtenir un nombre avec une précision connue.
    Si Apple utilise correctement le chiffrement homomorphe, Apple ne devrait avoir aucun moyen de voir les données reçues du téléphone. Les autres éléments mentionnés dans l’article sont des moyens d’empêcher les fuites d’informations via les métadonnées ou des canaux auxiliaires.
    Que cette fonctionnalité soit activée par défaut n’est pas très bon. Après la mise à niveau, elle aurait dû demander à l’utilisateur s’il voulait l’activer.
  • La critique centrale est qu’elle envoie à Apple des données privées et sensibles sans consentement ni avertissement.
  • Comment faire confiance à quelque chose qu’on ne comprend pas ? Au bout du compte, la confiance doit venir d’une personne ou d’une organisation dont on croit qu’elle comprend ces problèmes : une autorité.
    Pour beaucoup de gens, cette autorité n’est pas Apple. Je fais prudemment confiance à la politique de confidentialité d’Apple, mais beaucoup ne font pas confiance à Apple, et ils ont leurs raisons.
    Donc, si une fonctionnalité Apple non activée explicitement partage des données personnelles et que l’on ne comprend pas non plus l’explication technique d’Apple, le sentiment d’avoir subi une atteinte à sa vie privée augmente, ce qui entraîne encore plus de méfiance. Peut-on alors dire que c’est une critique injuste ?
  • Est-ce que je critique quelqu’un qui est concerné alors que je n’ai même pas d’appareil Apple ?
    Mon billet de blog est écrit du point de vue d’un utilisateur Apple dont la confiance a été trahie. C’est très bien de trouver la technologie impressionnante depuis une distance sûre, et elle peut effectivement l’être, mais cela n’a rien à voir avec le problème central : l’absence de consentement de l’utilisateur.

• Pour moi, cela ressemble globalement à une fonctionnalité raisonnable, mise en œuvre avec une forte prise en compte de la confidentialité des utilisateurs. Mais il se peut que je fasse trop confiance à l’explication.
  Cet article me semble surtout conçu pour susciter l’indignation, et je pense qu’il faut faire attention à ne pas se faire « appâter » par ce genre d’article sur Hacker News. Un peu comme il faut se méfier des articles destinés à provoquer l’indignation dans les tabloïds ou sur Facebook.
  Une partie des inquiétudes de l’article ou de ce fil n’a probablement que peu d’impact sur les revenus d’Apple. Une inquiétude réelle que certains clients pourraient avoir concerne l’utilisation des données ; je suppose que cette fonctionnalité est probablement désactivée en mode faible consommation de données.
  Je me demande si ce type de problème pourrait être résolu par un réglage du type paramètres de confidentialité par défaut. Les journalistes, les militants, certains services IT d’entreprise et les personnes qui écrivent des articles comme l’original pourraient choisir une configuration qui communique moins avec le réseau lors des mises à jour de l’OS. Concevoir une UI facile à comprendre semble difficile. iOS dispose déjà d’un « mode Isolement », mais je ne sais pas s’il influe sur ce réglage.

  • Tout ce qu’Apple aurait dû faire, littéralement, c’était de ne pas l’activer par défaut. Envoyer quelque chose sur le réseau sans demander réduit de plus en plus la confiance envers Apple.
  • C’est une fonctionnalité raisonnable, mais elle nécessite quand même un opt-in de l’utilisateur. Pour réduire la gêne, on pourrait regrouper les demandes d’opt-in lors de l’installation ou de la mise à niveau.
  • Ce qui n’est particulièrement pas clair, c’est de savoir si iOS scanne toutes les données du téléphone et en envoie une partie comme élément d’un index public.
    D’après la façon dont la fonctionnalité semble fonctionner dans l’UI, il ne semble pas que ce soit le cas. Si la fonctionnalité est activée par l’action de l’utilisateur, je me demande s’il faut aussi considérer cela comme une prise de contact avec le serveur.
  • Si une autre entreprise l’avait fait, on pourrait probablement considérer que c’est une fonctionnalité raisonnable, conçue raisonnablement. Le problème, c’est qu’Apple a dépensé des dizaines à des centaines de millions de dollars en publicité pour dire qu’elle ne fait pas ce genre de choses.
    Le message était que ces choses restent dans l’iPhone, contrairement à cet autre OS détestable exploité par une société publicitaire. Qu’Apple n’exfiltre jamais les données, que vous n’êtes pas le produit et qu’Apple se soucie de vous.
    Ce genre de chose, qu’elle soit raisonnable ou non prise isolément, détruit complètement ce récit. Si Apple est prête à mentir aussi ouvertement sur d’immenses panneaux publicitaires, on ne sait pas ce qu’elle fera d’autre quand ses intérêts l’exigeront.

• Je crois que je viens de voir un réglage similaire lié à la recherche, qui ne semblait pas exister avant iOS 18.
  En allant dans Réglages -> Recherche, il y a une option « Help Apple Improve Search », activée par défaut.
  « Aidez Apple à améliorer Search en l’autorisant à stocker les recherches que vous saisissez dans Safari (!!), Siri et Spotlight d’une manière qui ne vous est pas associée. Les recherches incluent les requêtes de connaissances générales et les demandes comme écouter de la musique ou obtenir un itinéraire. »
  Si elle existait déjà auparavant, elle a été réactivée.

  • La partie « stocker les recherches saisies dans Safari [...] d’une manière qui ne vous est pas associée » : les recherches sur la désanonymisation montraient déjà clairement il y a dix ans que l’historique de recherche révèle entièrement l’utilisateur.
    Il faudrait beaucoup de détails pour que je croie que la manière dont Apple les stocke protège réellement ma vie privée. Bien sûr, la citation ne l’affirme pas.
  • C’est plus grave que l’article original. Dans quel univers parallèle Apple vit-elle pour penser qu’il est acceptable de faire de la collecte de l’historique de recherche une option activée par défaut sans consentement ?
  • Merde, c’est vrai. C’était aussi activé par défaut sur mon appareil, et je ne pense pas avoir jamais pu consentir à ça.
  • Oui. C’est encore un autre réglage activé par défaut.

• À noter que, sur macOS, le service photoanalysisd s’exécute en arrière-plan et parcourt vos photos même si vous n’avez jamais ouvert Apple Photos.
  Impossible de le désactiver sans couper SIP, c’est-à-dire la protection de l’intégrité du système, ce qui exige une procédure compliquée avec plusieurs redémarrages et des avertissements à valider. Si vous réactivez SIP, il se réactive aussi.
  Pour une raison quelconque, Apple semble assez enthousiaste à l’idée d’analyser les photos, que l’utilisateur le veuille ou non.

  • Vous serez peut-être aussi surpris d’apprendre que Spotlight parcourt tous les fichiers de votre Mac.
  • Mais au moins, ça s’exécute localement sur le Mac, non ?
  • En théorie, la détection CSAM pourrait déjà faire partie d’un service local. À partir du moment où un compte lié à l’appareil devient nécessaire, la vie privée est terminée. Pas seulement iCloud : un compte lié à l’appareil lui-même. On n’a pas besoin de compte pour utiliser un ordinateur Linux.
  • Est-ce que ça contacte un serveur ? Que mes fichiers soient scannés ne me dérange pas. Ce qui me préoccupe, c’est que les détails de mes données privées quittent l’appareil.
  • Le passage « Pour une raison quelconque, Apple semble assez enthousiaste à l’idée d’analyser les photos, que l’utilisateur le veuille ou non » ne serait-il pas vulnérable si les utilisateurs finaux l’empoisonnaient ?
    Et si tout le monde faisait tourner un générateur d’images local entraîné sur ses propres photos, le détériorait légèrement, puis remplissait de déchets la collecte de hachages de photos d’Apple ?
    Et ensuite ?
    Ce serait une très bonne opération de nettoyage. On apprendrait beaucoup en voyant qui se met en colère, et à quel point.

• Cette affaire me rappelle l’indignation, à l’époque du Covid, autour du système de notification d’exposition préservant la vie privée d’Apple et Google.
  L’idée de pouvoir signaler une exposition sans pistage est contre-intuitive, mais c’est bien ce que cette technologie a rendu possible.
  Ici aussi, l’auteur semble s’appuyer sur une réaction immédiate à une atteinte à la vie privée, sans vraiment chercher à évaluer les effets de techniques comme la vectorisation côté client, la confidentialité différentielle, le relais OHTTP ou le chiffrement homomorphe.
  Cela dit, je suis d’accord à 100 % sur le fait qu’Apple devrait d’abord demander le consentement des utilisateurs pour ce genre de fonctionnalité.

  • J’aimerais pouvoir évaluer la confidentialité de ces technologies.
    Si quelqu’un mettait un lien vers le code source, je pourrais voir exactement ce que ça fait au lieu de croire un inconnu sur Internet.
    Mieux encore, j’aimerais pouvoir le compiler moi-même.
  • Cette fonctionnalité COVID était opt-in. Ce dont l’auteur se plaint ici, c’est de l’absence d’opt-in.

• À propos du passage disant « je ne comprends pas la plupart des détails techniques du billet de blog d’Apple », moi, je les comprends.
  Vectorisation côté client : les photos sont traitées localement afin de préparer une représentation vectorielle irréversible avant l’envoi. Pensez à une sorte de hachage sémantique.
  Confidentialité différentielle : une quantité assez importante de bruit est ajoutée au vecteur avant l’envoi. Suffisamment pour rendre impossible une recherche inverse du vecteur. Ici, le niveau de bruit est ε = 0,8, ce qui offre une confidentialité plutôt bonne.
  Relais OHTTP : l’envoi passe par un tiers, donc Apple ne connaît pas l’adresse IP. Le contenu est chiffré, donc le tiers n’apprend rien non plus. Il existe un risque de révéler quelque chose comme « l’IP X est un utilisateur d’Apple Photos », mais pas le contenu de la bibliothèque.
  Chiffrement homomorphe : l’opération de recherche est effectuée côté serveur sur des données chiffrées. Apple ne peut pas déchiffrer le contenu du vecteur ni celui de la réponse ; seul le client peut déchiffrer le résultat de la recherche.
  Voilà à quoi ressemble une bonne conception de la confidentialité. Il y a plusieurs couches de protection, et chacune des trois dernières devrait à elle seule suffire à protéger la vie privée.
  À propos de l’argument selon lequel « le niveau de tolérance au risque d’atteinte à la vie privée doit être décidé par chaque utilisateur », l’auteur semble être un chercheur en sécurité chez Apple, mais il dit en substance qu’il n’est pas capable de faire ici un choix éclairé.
  Je ne sais pas avec certitude quel est le bon jugement. Mais la conclusion « par conséquent, la seule façon de garantir la confidentialité informatique est de ne pas envoyer les données hors de l’appareil » n’est pas vraie. Il existe des outils qui permettent d’offrir des services tout en préservant la vie privée, par exemple la confidentialité différentielle et le chiffrement homomorphe. C’est très complexe et les utilisateurs ne peuvent pas évaluer le risque de façon réaliste, mais si l’on veut des fonctionnalités nécessitant des jeux de données plus grands que le disque ou du contenu qui change fréquemment, ces outils sont nécessaires.

  • Merci pour l’explication, mais j’ai l’impression qu’elle ne traite pas le problème central : mes données sont envoyées hors de l’appareil par défaut, sans notification raisonnable.
    Beaucoup d’utilisateurs pourraient accepter cette fonctionnalité. Comme vous le dites, elle est peut-être très sûre. Mais le problème, c’est que tout le monde est considéré comme ayant donné son accord par défaut.
  • « Une bonne conception de la confidentialité », ce serait que mes photos ne soient envoyées nulle part, sous quelque forme que ce soit, sans autorisation opt-in explicite.
  • Vous présentez un faux dilemme entre « compréhension parfaite par l’utilisateur » et « absence de choix pour l’utilisateur ». L’enjeu n’est pas de savoir si les utilisateurs peuvent comprendre parfaitement le chiffrement homomorphe ou la confidentialité différentielle, mais le consentement et la transparence de base.
    Les utilisateurs n’ont pas besoin d’un doctorat pour comprendre « cette fonctionnalité envoie des données sur vos photos aux serveurs d’Apple afin d’améliorer la recherche ».
    Le fait que les protections de confidentialité soient complexes ne justifie pas de supprimer le choix de l’utilisateur. Avec cette logique, aucune fonctionnalité technique ne devrait jamais être soumise à l’avis de l’utilisateur.
    Beaucoup d’utilisateurs soucieux de leur vie privée suivent un principe simple : ils veulent contrôler ce qui sort de leur appareil, quelle que soit la méthode de protection.
    L’argument « c’est trop complexe à expliquer » pourrait justifier n’importe quel réglage par défaut portant atteinte à la vie privée. Appliqueriez-vous le même critère aux services de localisation activés par défaut au motif que l’explication technique du GPS est trop complexe ?
    La vraie solution est simple : expliquer la fonctionnalité en termes accessibles, mettre en avant ses avantages, résumer les mesures de protection de la vie privée, puis laisser l’utilisateur choisir. Apple le fait déjà pour beaucoup d’autres fonctionnalités. Le réglage par défaut désactivé et l’opt-in sont des principes essentiels d’une conception respectueuse de la vie privée, quelle que soit la solidité des protections sous-jacentes.
  • Une bonne conception de la confidentialité, en réalité, c’est de n’envoyer aucune information à qui que ce soit, nulle part, jamais.
  • L’auteur n’est pas un chercheur en sécurité chez Apple.
    Jeff Johnson développe des apps pour les plateformes Apple, en particulier des extensions Safari, et blogue souvent sur ses griefs envers Apple, mais ce n’est pas un chercheur en sécurité.