Quand une app demande une autorisation, il devrait y avoir une option de « fourniture de fausses données »

• Quand une app demande une autorisation, l’OS ne devrait pas se limiter à une réponse oui/non, mais ajouter une « option de fourniture de fausses données » à toutes les catégories d’autorisations
• Si elle demande les contacts, fournir des faux contacts générés ; si elle demande l’accès au micro, fournir un bruit d’ambiance aléatoire ; si elle demande la localisation, fournir les coordonnées d’une petite île de 5×5 m
• Si on bloque l’accès, l’app peut répondre « alors elle ne peut pas être utilisée », mais si on lui donne de fausses données, seules les services qui ont exigé des données inutiles se retrouvent pénalisés
• Le boycott impose un lourd sacrifice personnel aux utilisateurs tout en n’ayant qu’un impact minime sur les entreprises ; l’idée défendue est donc que la conformité malveillante (malicious compliance) est plus efficace qu’un boycott
• Cela rejoint la question du contrôle par l’utilisateur : en tant qu’administrateur d’un appareil qui lui appartient, l’utilisateur devrait pouvoir contrôler les apps et le logiciel système

---

Proposition clé — option de fausses données par autorisation

• L’OS devrait proposer, pour chaque demande d’autorisation, en plus de oui/non, une option « oui, mais en fournissant de fausses données » dans toutes les catégories
  • Demande de contacts → fournir de faux contacts générés aléatoirement
  • Demande de micro → fournir un bruit d’ambiance aléatoire (random ambiance)
  • Demande de localisation → répondre que l’on se trouve sur une petite île de 5×5 m
• Si un service exige des données dont il n’a pas besoin, cela a pour effet de le punir en injectant des informations inutiles dans sa base de données
• Contrairement au simple blocage d’accès, les fausses données empêchent l’app de répliquer par « inutilisable » tout en neutralisant la collecte de données superflues

Pourquoi ce serait supérieur au boycott

• Boycotter une app nécessaire est un sacrifice personnel important qui n’inflige qu’un dommage à peine perceptible à des milliardaires, ce qui en fait un mauvais marché
  • La partie qui se bat est celle qui a le plus à perdre, ce qui défavorise l’utilisateur
• L’injection de fausses données donnerait davantage de pouvoir aux utilisateurs
• L’expression « conformité malveillante (malicious compliance) » est présentée comme plus amusante qu’un boycott

Outils existants mentionnés dans la discussion

• Location spoofing

  • Par le passé, le location spoofing n’était possible que comme réglage global, avec peu de possibilités de choix app par app
  • Dans les options développeur d’Android, on peut désigner une app précise comme app de mock location, ce qui s’applique globalement
  • Firefox dispose d’extensions de spoofing pour divers types de données, dont la géolocalisation, mais il serait plus utile que cela fonctionne directement sur le téléphone
  • Le fait que Pokémon GO ait été détourné via de fausses données de localisation montre que c’est techniquement possible

• XPrivacyLua

  • Sur un appareil rooté, cela faisait exactement ce que voulait l’utilisateur, mais nécessitait Magisk (modification du système)
  • Le projet n’est plus maintenu et n’est pas compatible avec tous les appareils

• Fonctions d’autorisations natives d’Android

  • Android permet déjà de choisir l’accès aux informations app par app, ou de redemander à chaque fois
  • Mais cela reste du blocage, pas une fourniture de fausses données

Idées d’extension et exemples

• Pollution de données avec l’IA

  • Proposition de neutraliser les data miners en leur fournissant récursivement des informations dénuées de sens
  • Idée d’utiliser des données générées par IA pour polluer jusqu’aux contenus destinés à l’entraînement de l’IA

• Réponse au pistage publicitaire

  • Mention de AdNauseam (un fork de uBlock Origin), qui bloque les publicités tout en cliquant sur toutes pour neutraliser les données de ciblage
  • Les tentatives passées ont été jugées gourmandes en ressources

• Brouillage des profils de suivi dans le navigateur

  • Il existe des services qui parcourent rapidement plusieurs sites avec navigateur et cookies pour perturber le fingerprinting et le suivi
  • Possibilité de choisir des schémas aléatoires ou basés sur un profil (par exemple : « naviguer comme un hippie équatorien de 70 ans »)
  • Mention du cas de TrackThis, créé par Mozilla

Limites et inquiétudes soulevées

• Si l’on saisit une date de naissance aléatoire, on recevra des messages d’anniversaire à une date arbitraire ; et avec les questions de sécurité, on risque de ne plus savoir quelle date a été utilisée
  • D’où l’idée complémentaire que l’OS devrait pouvoir montrer à l’utilisateur les valeurs de ses fausses données
• L’idée avait été étudiée comme idée de startup il y a une dizaine d’années, mais sans trouver de juriste capable de la rendre défendable
• Les développeurs commerciaux en auraient trop peur, donc Google a peu de chances de l’implémenter
• La cause fondamentale, selon cette critique, est que ni Google ni Apple ne veulent que les utilisateurs aient le contrôle

[GN⁺]

Commentaires sur Hacker News

• Favorable à l’idée des « fausses données », mais les apps devraient aussi être tenues de gérer ça proprement quand l’utilisateur refuse l’accès aux vraies données
  Quand je développais sur iOS, la politique d’Apple disait qu’une app ne devait pas punir l’utilisateur parce qu’il refusait une permission ni quitter via exit(), et qu’elle devait continuer à fonctionner
  Il fut un temps encore plus ancien où une app ne pouvait pas non plus exiger un « compte » pour se lancer. Je me souviens qu’il y a plus de dix ans, mon entreprise avait rendu le compte obligatoire et l’app s’était fait refuser à juste titre sur l’App Store. Vu le nombre croissant d’apps qui exigent aujourd’hui un compte, cette position semble s’être assouplie

  • Il manque probablement une grosse réserve à l’affirmation « une app ne peut pas exiger un compte pour fonctionner », ou bien je n’en comprends pas le sens
    Comment des apps bancaires, des jeux en ligne, l’app Twitter actuelle, ou des apps comme Dropbox/Nextcloud pourraient-elles fonctionner sans compte ?
    C’est vrai que, dans beaucoup d’apps, l’exigence d’un compte est une astuce marketing, mais une règle générale de ce genre ne semble pas pouvoir fonctionner
  • WhatsApp continue de « punir » l’utilisateur si l’accès aux contacts est refusé. Tous les noms sont masqués et seuls les numéros de téléphone s’affichent, même si le correspondant a défini son nom dans son propre profil
    Facebook/Meta, c’est vraiment de la merde
  • De fausses données personnelles pour les contacts ou les photos, très bien, mais dès qu’on parle de localisation, ça devient plus ambigu
    Si c’est pour afficher ma position sur une carte ou chercher des commerces à proximité, on peut fournir de fausses données
    Mais si c’est une app de test de débit Internet qui cartographie les vitesses par opérateur, ou une app où les utilisateurs signalent la météo locale pour améliorer les prévisions, je pense qu’elle devrait pouvoir dire : « donnez une position précise ou pas de position du tout, nous ne voulons pas de fausse localisation »
    La plateforme devrait décider s’il faut accorder une exception aux apps qui reçoivent des données contributives des utilisateurs ayant un impact sur d’autres personnes
    Apple semble avoir trouvé ici un compromis assez correct. On n’est pas obligé d’autoriser une app à accéder à la « localisation précise », et pour les photos, l’app peut aussi ne voir que celles choisies par l’utilisateur via le sélecteur d’images fourni par le système
  • Sur iOS, le pire, c’est Google Photos. Si on ne lui donne pas accès à toutes les photos, il est impossible d’ouvrir l’app, et elle n’accepte même pas l’option n’autorisant que des photos sélectionnées
    C’est pareil même si l’on veut seulement regarder des photos déjà stockées dans le cloud
  • Même si l’on dit que « les apps doivent gérer proprement le refus d’accès aux vraies données par l’utilisateur », que faire si elles ne le font pas ?
    Cela revient à proposer une solution organisationnelle à un problème technique, ce qui a peu de chances de marcher ; la seule solution pratique, ce sont les fausses données. Du point de vue de l’app, il faut que cela ait l’air autorisé même si la permission réelle ne l’est pas

• Sur Android rooté, XPrivacy savait déjà faire ça il y a 7 ans, et il existe aussi des alternatives modernes. Cela dit, comme je n’ai pas rooté de téléphone depuis longtemps, difficile de garantir quoi que ce soit : https://github.com/M66B/XPrivacy
  Bien sûr, ce n’est pas une approche grand public, et je suis d’accord pour dire que cela devrait être intégré par défaut. Mais Android comme iOS autorisent aussi des absurdités comme les apps à restriction géographique ou le blocage des captures d’écran sur des contenus DRM, donc ça ne sera pas simple

  • En l’écrivant ainsi, je me rends compte à quel point tout est conçu contre l’utilisateur, et ça m’a fait abandonner l’idée qu’un téléphone est un ordinateur
    Un téléphone est un dispositif de diffusion de contenu du fournisseur, et l’utilisateur est à leur merci
  • XPrivacy était vraiment génial, mais sur les téléphones modernes, rooter l’appareil et installer Xposed est devenu bien plus compliqué, voire carrément bloqué
    GrapheneOS ne s’entendait pas très bien avec les apps bancaires, Google a cassé plusieurs fois le root via Magisk dans Android Beta, et à un moment j’ai cessé de m’en soucier
    Un projet comme GrapheneOS, ou similaire, pourrait peut-être offrir cette fonctionnalité
  • XPrivacy était excellent, mais les apps plantaient souvent quand certaines permissions étaient refusées. Au final, il n’arrivait donc pas à fournir des fausses données assez convaincantes
    C’était à ce point que je ne cliquais jamais tout de suite sur « refuser » ; je commençais toujours par « refuser temporairement ». Si l’app fonctionnait, je refusais ensuite définitivement ; si elle plantait, il fallait trouver l’ensemble minimal de permissions à autoriser
  • Cette fonctionnalité n’entrera probablement jamais dans l’image d’usine ni dans l’amont d’Android, mais si la demande des utilisateurs est suffisante, elle pourrait finir dans des projets comme LineageOS
  • Par « apps à restriction géographique », ce n’est en réalité pas de cela qu’il s’agit, mais du fait que chaque app store permet de distribuer une app seulement dans les régions choisies
    C’est une fonction importante des app stores, parce qu’une app peut ne pas offrir une bonne expérience dans tous les pays, ne pas être localisée dans toutes les langues, ne pas avoir de modérateurs pour le contenu dans telle ou telle langue, devoir respecter les lois nationales, ou avoir des licences de diffusion limitées à certains pays pour des contenus protégés par le droit d’auteur
    L’empêchement des captures d’écran sur du contenu DRM est une fonctionnalité demandée par les développeurs d’apps pour répondre à des exigences juridiques liées aux licences de contenus comme les films. Les studios ne veulent pas que les gens diffusent ou enregistrent les films, donc les plateformes d’apps doivent fournir un moyen d’afficher ces contenus de manière sécurisée

• « Si quelqu’un pose une question qu’il n’a pas qualité à poser, vous n’avez aucune obligation de lui dire la vérité »
  — Leonard Schiffman
  Source : “Blend me in: Privacy-Preserving Input Generalization for Personalized Online Services” https://drive.google.com/file/d/10OmoqMmHFcb7PsQtaU_GW4aCAJe...

• L’idée selon laquelle, lors d’une demande d’autorisation d’application, le système d’exploitation devrait proposer non seulement oui/non mais aussi « oui, mais en fournissant à l’app des données factices » pose problème
  Beaucoup d’utilisateurs ne savent même pas comment transférer un e-mail
  Imaginez la confusion si ces mêmes personnes choisissaient des données factices en utilisant la navigation Google Maps sans en comprendre le sens
  Google Maps : « Tournez à droite »
  Conducteur sur une route en bord de mer : « D’accord »
  Voiture : plouf

  • C’est entièrement un problème d’expérience utilisateur
    Il suffit de cacher la fonction de falsification des données assez profondément dans les réglages, de l’expliquer clairement en termes simples avant son activation, et d’indiquer explicitement à l’écran que l’app reçoit des informations de substitution à cause d’une fonction de protection de la vie privée activée par l’utilisateur, et qu’elle peut être désactivée facilement
    Il y aura quand même des personnes qui l’activeront par erreur, mais cela pourrait apporter une grande valeur à beaucoup d’autres utilisateurs
  • Ça ressemble à une occasion d’apprentissage. Ou peut-être à une occasion darwinienne
    Dans les deux cas, c’est un problème qui se résout tout seul
  • Dans ce cas, il suffit d’en faire une option avancée destinée aux utilisateurs expérimentés. Les utilisateurs peu familiers n’ont tout simplement pas besoin de voir l’option
  • Dans un tel cas, cela voudrait dire que le conducteur ne regardait pas correctement dans la direction où il avançait, et c’est un autre problème
    Le système d’exploitation devrait plutôt proposer « oui », « non » et « personnalisé ». Si l’utilisateur choisit « personnalisé », on peut afficher des avertissements dans ce menu si nécessaire, mais il ne faut pas empêcher l’utilisateur de configurer cela comme il le souhaite
  • Je me demande si Google Maps est beaucoup utilisé sur iOS. L’option « fournir des données factices » est quelque chose qu’Apple pourrait peut-être faire, mais j’ai beaucoup de mal à croire que Google le ferait
    Apple Maps n’aurait pas ce problème. On peut télécharger les cartes sur l’appareil, ce qui permet un fonctionnement hors ligne sans connexion de données

• Je suis surpris que le commentaire le mieux classé ne mentionne pas qu’il est impossible sur iOS de distinguer si une autorisation a été accordée ou non
  Par exemple, quand une app demande l’accès aux photos, elle reçoit toujours un tableau. Simplement, si l’autorisation est refusée, ce tableau est vide, donc on ne peut pas savoir si la photothèque de l’utilisateur est réellement vide ou si l’accès a été refusé. C’est simple et élégant
  Bien sûr, pour les photos, on peut utiliser une heuristique puisque presque tout le monde en a au moins quelques-unes. Mais pour d’autres types de données, comme les données de santé, ce n’est pas aussi évident

  • Ce n’est pas exact. Par exemple, pour l’accès aux services de localisation, il existe CLAuthorizationStatus : https://developer.apple.com/documentation/corelocation/claut...
    Pour les notifications push, il existe UNAuthorizationStatus : https://developer.apple.com/documentation/usernotifications/...
    Pour les données de santé, il existe HKAuthorizationStatus : https://developer.apple.com/documentation/healthkit/hkauthor...
    Pour les contacts, il existe CNAuthorizationStatus : https://developer.apple.com/documentation/contacts/cnauthori...
    Pour les photos, il existe PHAuthorizationStatus : https://developer.apple.com/documentation/photokit/phauthori...
    Les photos constituent un cas particulier, car l’utilisateur peut choisir entre accès refusé, accès limité ou accès complet. On peut savoir si l’accès a été refusé, mais on ne peut pas distinguer l’accès limité de l’accès complet
  • Je me demande comment cela fonctionne pour la localisation
    Et si le dossier des photos est vide, cela voudra presque certainement dire qu’il n’y a pas d’autorisation. Les personnes n’ayant jamais pris de photo sont extrêmement rares
  • Qu’en est-il des autres autorisations pour lesquelles il n’est pas réaliste d’envoyer un objet vide
    Par exemple, si l’utilisateur autorise l’accès à sa position, l’objet de localisation transmis à l’app contiendra évidemment les informations correspondantes. Si le système d’exploitation transmet un objet de localisation vide, cela ne rend-il pas le refus d’autorisation évident, ou bien est-ce caché derrière une erreur d’une manière ou d’une autre
  • C’est manifestement faux, et on peut le constater dans presque toutes les applications qui demandent l’accès aux notifications

• Je pense que « fournir des données factices » est une mauvaise approche. Une meilleure approche serait de fournir des données issues d’une source alternative, et cette source alternative devrait pouvoir être n’importe quel autre programme
  La source alternative pourrait être des données vides, des données aléatoires, des données fictives mais cohérentes, des données issues d’un fichier alternatif (par exemple une liste de contacts distincte ou des photos provenant d’un fichier au lieu de la caméra), des données transformées (par exemple retourner les photos de la caméra à l’envers), un filtrage, un enregistrement, interroger l’utilisateur pour chaque donnée individuelle, fournir des codes d’erreur au lieu de données et permettre à l’utilisateur de choisir le code d’erreur, etc. Cela devrait même inclure l’accès à la date et à l’heure actuelles
  Cela renforce le contrôle de l’utilisateur et peut aussi être utile pour les tests et l’accessibilité
  L’une de mes idées de conception d’OS est celle des autorisations proxy. Intégrer des autorisations proxy dans une sécurité fondée sur les permissions, faire passer toutes les entrées/sorties par elles, pouvoir les utiliser dans un shell de commande d’une manière meilleure que les pipes UNIX, ainsi que d’autres usages. Cela inclut aussi la date et l’heure. À part Yield et Quit, aucun appel système ne devrait être utilisable sans clé d’autorisation

  • C’est la meilleure approche, et à mon avis la seule réellement praticable
    Il est très difficile pour les développeurs d’apps de bien gérer des permissions qu’ils ne peuvent pas utiliser, et comme cela élargit fortement et complique le périmètre de test pour un nombre relativement faible d’utilisateurs, la plupart des petites apps commerciales n’essaieront probablement pas de le gérer correctement
    Autoriser la permission tout en injectant une source de données alternative est la solution la plus simple à la fois pour les développeurs et pour les utilisateurs
    Bien sûr, cela pourrait aussi faciliter la fraude. Par exemple, les banques adopteraient probablement des procédures d’enregistrement de l’appareil plus complexes

• Pas besoin de se montrer inutilement hostile les uns envers les autres. La règle simple, c’est : « non est aussi une option », sauf si ce n’en est vraiment pas une
  Si ce n’est pas une option, il faut que la raison soit extrêmement claire, elle devrait probablement être explicitée lors du processus de validation de l’app, et sinon l’app devrait être refusée
  Par exemple, si TikTok/Instagram demande l’accès à la caméra et au micro, dans les deux cas ce n’est pas indispensable à l’utilisation de l’app, donc non est une option. Si une partie de l’app reste utilisable sans une permission donnée, c’est à l’app d’être conçue pour fonctionner ainsi. Si la caméra ou le micro est désactivé, il suffit de désactiver de façon conditionnelle uniquement les fonctionnalités qui nécessitent cette permission
  Plus simplement, la charge de la preuve incombe au demandeur. Si ce n’est pas clair ou si l’on essaie de contourner la question avec malice, la réponse est non. Cela peut paraître strict, mais les créateurs d’apps peuvent éviter entièrement cette étape supplémentaire en rendant les permissions facultatives
  Se concentrer sur l’application de cette règle éviterait d’avoir besoin d’une petite course aux armements mesquine, et ce serait aussi un meilleur choix pour les gens

  • Ça semble bien, mais comment l’imposer ?
    Les seuls acteurs capables de l’imposer ici sont les app stores de Google/Apple/Microsoft. Il est difficile d’être certain qu’ils aient suffisamment d’incitation à l’appliquer de manière cohérente et favorable aux utilisateurs. Si c’était le cas, ils l’auraient déjà fait

• Les téléphones Samsung ont des interrupteurs pour l’accès à la caméra et l’accès au micro
  Quand on les désactive, ce message s’affiche :

  Turn off Camera access?  
  All apps will be blocked from using the camera. Apps  
  will still work, but they will only be able to access an  
  empty black screen. For example, you can still make  
  and receive video calls, but the other person won't be  
  able to see you.  
  

  • Pour l’accès au micro :

    Turn off Microphone access?  
    All apps will be blocked from using the microphone  
    Apps will still work, but they won't be able to access  
    any sounds from the microphone. For example, you  
    can still make and receive calls, but the other person  
    won't be able to hear you.  
    

• Des réglages par application seraient préférables à une option du type « oui, mais fournir de fausses données à l’app » pour toutes les catégories
  On peut ne vouloir donner ses données de localisation à presque aucune app, tout en acceptant de les fournir à Google Maps et à une app d’appel d’urgence. Même chose pour les contacts et les données personnelles
  Mais de telles apps se heurteraient probablement à une forte résistance de la part de Google et d’autres entreprises qui tirent profit du profilage des utilisateurs

  • D’accord, mais cela devrait être à la fois par application et par catégorie de permission
    Par exemple, on devrait pouvoir donner à une app des données réelles pour une permission, de fausses données ou des données personnalisées/saisies manuellement pour une autre, et refuser une troisième permission
    On peut aussi vouloir modifier temporairement ces réglages à des fins de test, ou dans des cas comme une app météo fondée sur la position actuelle, pour consulter un moment la météo d’un autre lieu puis revenir à sa position réelle

• Si une app a besoin de mes données pour améliorer mon expérience, et uniquement mon expérience, alors si je lui fournis de fausses données, seule mon expérience devrait se dégrader. Cela ne devrait pas avoir d’importance pour le développeur ou le propriétaire de l’app
  Mais si, comme c’est le cas le plus souvent, l’objectif est de faire du data mining sur moi, alors les fausses données fonctionneront très bien pour contrarier cela
  Bien sûr, dans le cas de WhatsApp, cela ne sert pas à grand-chose. Les gens sont prêts à synchroniser tout leur carnet de contacts avec Facebook/Meta pour obtenir une expérience de messagerie à peine meilleure

  • J’ai dû faire pareil et cela m’a profondément agacé, mais ce n’était pas juste une « expérience légèrement meilleure »
    Au moins sur mobile, l’app et le service sont à peine utilisables avant la synchronisation des contacts