Gains :
- Possibilité de demander des autorisations avec justification, contexte et scénario de rejet, en utilisant le principe du moindre privilège
- Possibilité de stocker des données sensibles cryptées avec trousseau/keystore, d'appliquer la minimisation des données et de contrôler la tendance de l'intelligence artificielle à ajouter trop d'autorisations
- Capacité à gérer le flux de données utilisateur vers le cloud ou le service d'intelligence artificielle en tant que décision de confidentialité, à obtenir le consentement de l'utilisateur et à utiliser des techniques de sécurité uniquement à des fins défensives autorisées.
L'application mobile fonctionne sur l'appareil le plus privé de l'utilisateur : elle connaît sa localisation, ses contacts, ses photos, ses données de santé, son microphone. Cet accès est un grand pouvoir, et le pouvoir signifie la responsabilité. La confidentialité et la sécurité ne sont pas une « fonctionnalité complémentaire » dans le développement mobile, mais un principe intégré dès le départ à l’architecture ; C’est ce qu’on appelle la confidentialité dès la conception. De plus, il ne s'agit pas seulement d'un choix éthique, c'est une obligation légale (KVKK, RGPD) et de magasin (App Store, Google Play). Dans cette unité, nous apprendrons comment demander correctement les autorisations, traiter les données en toute sécurité, utiliser l'IA comme assistant dans ce domaine et nous protéger de ses pièges. Il existe un problème critique supplémentaire dans le contexte de l'IA : les données des utilisateurs transmises aux modèles d'IA (en particulier le cloud) sont une décision en soi en matière de confidentialité.
L’art de demander la permission : le moindre privilège
Le principe de base de la sécurité est celui du moindre privilège (ne pas demander plus de privilèges que ce qu'exige un emploi). Votre application ne doit demander que l’autorisation dont elle a réellement besoin, au moment où elle en a besoin. S'il n'y a pas de fonction de caméra, l'autorisation de la caméra ne sera pas demandée ; Si l'emplacement n'est requis que lorsque la carte est ouverte, l'autorisation « lors de l'utilisation » est suffisante, et non « toujours ». Des autorisations excessives causent un triple préjudice : elles sapent la confiance des utilisateurs, entraînent le rejet des magasins et amplifient le risque de fuite de données.
Un timing approprié et une explication de la demande d’autorisation sont essentiels. Demandez à l'utilisateur l'autorisation dans le contexte et avec une justification, par exemple "Un accès à la caméra est requis pour numériser votre reçu". iOS nécessite cette description dans Info.plist ; Une description vide ou trompeuse constitue un refus du magasin.
Type d'autorisation
mauvaise approche
bonne approche
timing
Demander tout au lancement
invite lors de l'utilisation de la fonctionnalité
Portée
"Toujours la localisation"
"emplacement lors de l'utilisation"
Descriptif
Vierge ou générique
Justification concrète et spécifique
statut de rejet
L'application plante/plante
Veuillez proposer des alternatives
Astuce : Votre application devrait pouvoir continuer à s'exécuter lorsque l'autorisation est refusée. Si l'utilisateur rejette la caméra, proposez une option de « connexion manuelle ». L'imposition de « autorisez-le ou l'application ne fonctionnera pas » est à la fois une mauvaise expérience et un problème de magasin. Demandez toujours le scénario de rejet lors de l’impression d’un code d’autorisation sur l’IA.
Code de consentement et de confidentialité avec l’IA : considérations
L’IA génère rapidement du code de demande d’autorisation, mais elle présente deux pièges typiques. Tout d'abord, en ajoutant plus d'autorisations que nécessaire : l'emplacement, les contacts peuvent définir en masse des autorisations de stockage "juste au cas où". Deuxièmement, ignorer le scénario de rejet : écrivez simplement le statut "autorisé" et ignorez le rejet. Pour chaque permis généré, il vous sera demandé : « est-ce vraiment nécessaire ? » et "que se passe-t-il en cas de rejet ?" Posez vos questions.
Attention : l'exemple de code généré par l'IA peut stocker les données utilisateur sans cryptage ou les transmettre de manière non sécurisée. Les données sensibles (mot de passe, santé, finances) doivent être conservées dans un stockage sécurisé sur l'appareil (Keychain — iOS, Keystore — Android ; zone de coffre-fort cryptée du système d'exploitation) et transmises sur le réseau via une connexion cryptée (HTTPS/TLS). L’IA ne le fait pas toujours spontanément ; Demandez clairement et vérifiez.
Minimisation des données et envoi de données à l'IA
Les données que vous ne collectez pas ne peuvent pas être divulguées. La minimisation des données (collecter uniquement les données réellement nécessaires) est l’outil le plus puissant en matière de confidentialité. Dans les fonctionnalités d'IA, ce principe est doublement important : lors de l'envoi de données vers un LLM cloud ou un service d'IA externe, ces données sont hors de votre contrôle. Avant d'envoyer le message de santé, le contenu d'une conversation ou les informations personnelles d'un utilisateur vers le cloud, posez trois questions : (1) Ces données sont-elles vraiment nécessaires ? (2) Peut-il être traité sur l'appareil ? (3) S'il doit être envoyé, l'utilisateur le connaît-il et l'approuve-t-il ? Il s’agit d’une exigence à la fois légale et éthique d’informer clairement l’utilisateur que ses données seront transmises à un service d’IA.
Utilisation sûre et orientation vers la défense
Un avertissement du point de vue informatique et de sécurité : les techniques apprises dans ce module sont destinées à un usage autorisé et défensif uniquement. Il est légitime de tester la sécurité de votre propre application, de protéger les données des utilisateurs et de corriger les vulnérabilités. L'ingénierie inverse de l'application de quelqu'un d'autre sans autorisation, la collecte de données utilisateur sans consentement ou l'utilisation de l'IA pour créer des logiciels malveillants sont illégales et contraires à l'éthique. Lorsque vous demandez de l’aide à l’IA en matière de sécurité, restez toujours dans le cadre de la défense de votre propre système.
trois mini-cases
Cas 1 — Refus de congé excédentaire. Une application de note demandait des autorisations de caméra, de microphone, de localisation et de contact au démarrage avec le code produit par l'IA. Google Play a rejeté la version, citant des "autorisations non pertinentes pour les fonctions". La version a été approuvée lorsque l’équipe n’a libéré que l’autorisation de stockage réellement utilisée. Leçon : chaque congé supplémentaire est un risque.
Cas 2 — Stockage sans mot de passe. Une application de santé stockait les mesures des utilisateurs dans un fichier texte brut, comme dans l'exemple de l'IA. Un audit de sécurité a révélé que toute personne ayant obtenu l'appareil pouvait lire toutes les données de santé. Données déplacées vers un stockage crypté avec Keystore/Keychain. Leçon : les données sensibles restent toujours cryptées.
Cas 3 — Push inopiné vers le cloud. Une application envoyait les notes quotidiennes des utilisateurs à un LLM cloud pour les résumer, mais elle n'en informait pas l'utilisateur. Lorsque cela a été rapporté dans la presse, il y a eu une perte de confiance et un contrôle juridique. L'équipe a ajouté une notification et une confirmation claires, ainsi qu'une option sur l'appareil. Leçon : l’utilisateur doit savoir et confirmer que les données vont vers l’IA.
Invite faible/Invite forte
Invite faible : « Demander l'autorisation de localisation. »
Invite puissante : "Demander l'autorisation de localisation sur iOS/Swift avec le principe du moindre privilège. - Uniquement l'autorisation "en cours d'utilisation", pas "toujours" - Description Info.plist : "Pour afficher les magasins à proximité" - Si l'autorisation est refusée : offrez une option pour sélectionner manuellement la ville, crash - Si l'autorisation a déjà été refusée, redirigez vers les paramètres. N'ajoutez pas plus d'autorisations que nécessaire. Écrivez également le flux de refus.
Modèles copiables
Modèle de demande d'autorisation : "Demander l'autorisation de [type d'autorisation] pour [plate-forme]. - Portée minimale (lors de l'utilisation/au besoin) - Dans le contexte, avec explication motivée - Alternative polie en cas de rejet, ne plantez jamais - Donner également l'entrée Info.plist / Manifest N'ajoutez pas d'autorisations supplémentaires ; justifiez chaque autorisation. "
Modèle d'audit des autorisations : "Vérifiez les autorisations demandées par mon application : [liste des autorisations + propriétés]. Pour chaque autorisation : est-elle vraiment nécessaire ? Une portée plus étroite serait-elle suffisante ? Cela entraînerait-il le rejet du magasin ? Signalement inutile.
Modèle de stockage de données sécurisé : "Stockez en toute sécurité les données sensibles ([type]) pour [plate-forme] : - Chiffrées avec un trousseau/un magasin de clés - Ne pas conserver en mémoire inutilement longtemps - Ne pas divulguer dans les journaux et les sauvegardes Fournissez le code et les étapes de vérification.
Modèle d'envoi de données à l'IA : "J'envisage d'envoyer les données suivantes à un service cloud d'IA : [données]. Évaluer : est-ce vraiment nécessaire ? Peuvent-ils être traités sur l'appareil ?
Erreurs courantes
- Demander plus de permission que nécessaire. Triple menace de confiance, d'approbation du magasin et de sécurité.
- Demander des autorisations en masse au démarrage. Une demande d'autorisation sans contexte est rejetée ; demandez la fonctionnalité instantanément.
- Ne pas écrire le script de rejet. L'application qui plante lorsque l'autorisation est refusée est à la fois mauvaise et rejetée.
- Stockage de données sensibles sans mot de passe. La santé, les finances et les mots de passe doivent être conservés dans un stockage sécurisé.
- Envoi de données vers le cloud/IA sans en informer l'utilisateur. Violation légale et éthique ; Une notification et une approbation sont requises.
- Utilisation non autorisée de techniques de sécurité. Ce n'est légitime qu'à des fins défensives sur votre propre système.
En résumé
La confidentialité et la sécurité sont conçues dès le début et ne sont pas ajoutées ultérieurement. Le principe de base est celui du moindre privilège : ne demander que l'autorisation nécessaire, lorsque cela est nécessaire, avec justification, et proposer une alternative courtoise en cas de refus. Les données sensibles sont stockées dans un stockage crypté et transmises via une connexion cryptée. La minimisation des données constitue la protection la plus efficace : les données que vous ne collectez pas ne peuvent pas fuir. L’envoi de données à l’IA, en particulier vers le cloud, est une décision en soi en matière de confidentialité ; Sa nécessité est remise en question, si possible, le on-device est privilégié, l'utilisateur est informé et son approbation est obtenue. Chaque code produit est comparé aux tendances de l'IA à ajouter des autorisations excessives et à stocker de manière non sécurisée. Les techniques de sécurité sont utilisées uniquement à des fins autorisées et défensives.
Tâche de candidature
Faites une liste des autorisations demandées par une application (votre propre projet ou imaginaire) et demandez à l'IA de vérifier celles qui sont inutiles ou excessives avec le "Modèle d'audit des autorisations". Affinez ou supprimez au moins une autorisation et rédigez le scénario de refus pour cette fonctionnalité. De plus, si vous envoyez des données utilisateur vers le cloud, déterminez la conception la plus sécurisée avec le « Modèle de décision d'envoi de données à l'IA » et rédigez le texte d'approbation de l'utilisateur.
liste de contrôle
- [ ] J'ai demandé chaque autorisation avec justification, avec le principe du moindre privilège.
- [ ] J'ai demandé des autorisations en contexte, au moment de la fonctionnalité, et non en masse au lancement
- [ ] J'ai écrit un script de rejet pour chaque autorisation, pas de crash
- [ ] J'ai stocké des données sensibles cryptées avec trousseau/keystore
- [ ] J'ai minimisé les données allant vers le cloud/IA et ajouté l'approbation des utilisateurs
- [ ] J'ai utilisé des techniques de sécurité uniquement sur mon propre système à des fins défensives