La checklist CNIL des applications mobiles

L’ensemble des données personnelles et les traitements qui s’y rapportent sont identifiés

Chaque traitement mis en œuvre a une base légale identifiée.

Les opérations de lecture et/ou d’écriture sur les terminaux des personnes mis en œuvre au sein des applications sont identifiés.

Aucune collecte de données non nécessaire n’est opérée. Celles nécessaires sont minimisées.

Une durée de conservation des données est associée à chaque traitement.

Les données sensibles traitées sont identifiées.

Des mesures additionnelles sont appliquées sur les données des personnes mineures.

La liste des paramètres minimaux pour fournir le service demandé est déterminée et sont proposés par défaut.

Ces paramètres sont analysés au regard des différentes catégories d’usagers.

La possibilité d’intégrer des mécanismes de protection de la vie privée est étudiée dès la conception.

Un registre des traitements est réalisé.

Les durées de conservation sont justifiées et documentées.

Une AIPD est réalisée si le traitement en remplit les critères.

Un délégué à la protection des données est nommé au sein de l’éditeur.

La qualification du développeur est convenue entre celui-ci et l’éditeur.

L’ensemble des mentions de l’article 28 du RGPD figurent dans le contrat avec le développeur.

Les instructions données au développeur sur les traitements à mettre en œuvre sont claires et documentées, et un point de contact dédié aux problématiques de vie privée est mis à sa disposition.

L’ensemble des tiers impliqués dans l’application sont analysés pour identifier s’ils procèdent à des traitements de données personnelles.

Tout SDK mis en œuvre est analysé avec l’aide potentielle du développeur pour identifier s’il procède à des traitements de données personnelles.

Une politique de confidentialité complète, concise et compréhensible par son public est rédigée.

La politique de confidentialité est accessible avant tout téléchargement de l’application, par exemple sur la page de téléchargement de celle-ci. La politique de confidentialité est également accessible au sein de l’application.

Les obligations en termes de recueil de consentement telles qu’explicitées par la CNIL dans ses lignes directrices et recommandations sur les cookies et autres traceurs sont mises en œuvre.

Une analyse sur les droits applicables aux personnes est effectuée (droit d’accès, droit à la portabilité, droit à la limitation, etc.).

Un centre de gestion des droits est mis en place directement au sein de l’application.

Les exigences en termes de mesures techniques attendues sont formalisées auprès des sous-traitants.

Les obligations en termes d’alerte de sécurité afin de permettre la notification de violations de données personnelles sont rappelées aux sous-traitants.

Le processus de mise à jour en cas de vulnérabilité est contractualisé avec les tiers.

Si les risques le justifient, des audits sont mis en œuvre auprès des sous-traitants pour contrôler le respect des instruction données.

Les mises à jour sont reflétées dans le registre des traitements, dans l’AIPD et dans la politique de confidentialité.

Des instructions sont données aux sous-traitants pour que toute évolution impactant les problématiques de vie privée soit approuvée avant mise en œuvre.

Les données personnelles sont protégées et leur accès est journalisé pour éviter tout détournement.

La suppression des données dont la durée est échue est organisée.

Pour chaque donnée dont la collecte est nécessaire, la permission impliquant le moins de collecte supplémentaire de données est choisie.

Des alternatives à l’usage des permissions sont proposées aux personnes lorsque cela est possible.

Les données collectées sont traitées localement lorsque cela est possible.

Le consentement est valablement recueilli lorsqu’il est nécessaire (voir 3.2.1).

Avant toute collecte distante, la précision de la donnée est diminuée au minimum nécessaire.

Des instructions exhaustives et claires sur les traitements à mettre en œuvre sont fournies lors de la contractualisation, incluant la qualification de chacun des acteurs.

Un point de contact chez l’éditeur est désigné pour la validation de tout choix impactant les traitements de données personnelles.

Les données ne sont traitées que sur la base des instructions spécifiques fournies.

Les obligations du développeur sous-traitant (article 28 RGPD) sont identifiées et mises en œuvre.

Toute décision impactant la vie privée des utilisateurs est validée par l’éditeur par écrit, après information et conseil du développeur.

Un processus de suivi des évolutions externes pouvant impacter les traitements est mis en œuvre, processus qui inclut l’alerte de l’éditeur.

L’ensemble des éléments nécessaires à la bonne information des personnes est transmis par l’éditeur en cas de délégation de la publication dans les magasins d’applications.

Les traitements mis en œuvre par l’OS à travers l’usage de fonctionnalités qu’il met à disposition sont identifiés et validés par l’éditeur.

Les traitements mis en œuvre suite à l’intégration des SDK sont identifiés et validés par l’éditeur. Sont collectés à cette fin auprès du SDK toutes les informations nécessaires pour cette qualification (liste des données personnelles collectées et l’objet, la nature et la finalité des traitements mis en œuvre sur ces données)

Si certains traitements mis en œuvre dans ce cadre contreviennent au RGPD, l’éditeur en est immédiatement averti.

L’exercice des droits est possible simplement, par exemple au moyen d’une page intégrée dans l’application.

L’exercice des droits inclut l’ensemble des traitements mis en œuvre au sein de l’application, y compris ceux effectués par des tiers comme les SDK.

Une politique de confidentialité lisible sur support mobile est fournie par l’éditeur et intégrée au sein de l’application, de manière accessible.

Des solutions techniques à l’état de l’art sont analysées et proposées à l’éditeur pour minimiser les collectes et limiter l’impact de la mise à disposition des données aux tiers.

Les permissions demandées sont strictement nécessaires au fonctionnement de l’application. Des alternatives à l’usage de permission sont prévues.

Les données sensibles (au sens de l’article 9 du RGPD) sont distinguées des autres types de données, notamment en termes d’architecture.

Les données sensibles ne sont pas rendues accessibles aux tiers (par exemple, aux SDK).

Les opérations visées par la nécessité du consentement sont identifiées et les modalités de recueil sont validées en amont avec l’éditeur.

Les consentements obtenus répondent aux exigences décrites dans la recommandation « Cookies et autres traceurs », adaptées pour améliorer la lisibilité sur terminal mobile.

Si une même opération est visée par un consentement et une permission, l’articulation entre ces éléments n’est pas de nature à créer de la confusion chez les utilisateurs ou mène à les solliciter excessivement.

Des documents permettant de déterminer l’ensemble des traitements et données collectées lors de l’intégration du SDK est mis à disposition par le fournisseur de celui-ci.

Le SDK permet de répondre aux demandes d’exercice des droits.

Les responsabilités sont qualifiées pour chacun des traitements mis en œuvre dans le cadre de l’intégration du SDK, et validées par écrit par l’éditeur.

Le SDK fournit une information permettant d’assurer la bonne information sur les finalités poursuivies lors du recueil du consentement.

Le SDK permet la granularité et le retrait du consentement.

Le SDK doit permettre une configuration en faisant aucune lecture et/ou écriture avant le consentement (notamment au premier lancement de l’application).

Le respect des engagements pris par le fournisseur du SDK est audité, avec le concours de celui-ci.

Les communications sont systématiquement encapsulées dans un canal TLS.

Les suites cryptographiques de l’OS sont utilisées, ainsi que les protections matérielles des secrets.

Les sauvegardes (notamment automatiques) sont chiffrées avec une clé conservée localement.

Le niveau L1 de l’OWASP MAS est atteint.

Le modèle de sécurité ne repose pas sur l’intégrité du terminal.

Toute détection de défaut d’intégrité est indiquée à l’utilisateur et non utilisée pour bloquer celui-ci.

Les API intègrent des éléments permettant de sécuriser les services.

Les données personnelles sont protégées contre d’éventuels détournement internes ou par des sous-traitants.

L’application est mise à jour aussi souvent que nécessaire en termes de sécurité.

Les éventuelles évolutions malveillantes des SDK ou bibliothèques utilisées sont surveillées dans le cadre de pratiques de « supply-chain security ».

L’application est mise à jour en cas d’évolution de l’OS à la suite de failles de sécurité, en fonction de la sensibilité des traitements.

Toute violation de données personnelles, suspectée ou avérée est signalée à l’éditeur.

Une qualification au sens du RGPD (responsable de traitement, responsable de traitement conjoint ou sous-traitant) est définie pour chaque traitement de données à caractère personnel opéré par le SDK.

Les données sensibles (au sens de l’article 9 du RGPD) sont identifiées et leur traitement modifié en conséquence.

Les données collectées par le SDK ainsi que celles transmises aux partenaires sont minimisées.

Les différentes fonctionnalités proposées par le SDK peuvent être intégrées et exécutées de manière décorrélée, en particulier si elles n’impliquent pas toutes les mêmes responsabilités ou finalités.

Plutôt que de regrouper plusieurs fonctionnalités différentes au sein d’un même SDK, celles-ci sont scindées en plusieurs SDK distincts.

Les permissions requises pour l’exécution du SDK sont minimisées, en distinguant celles strictement nécessaires de celles souhaitées mais non indispensables.

Lorsque plusieurs permissions peuvent autoriser la collecte d’une donnée sous sa forme souhaitée, le choix est porté sur celles aux capacités techniques les moins intrusives.

Une analyse claire des traitements entraînés par l’utilisation du SDK est réalisée et accessible.

Pour chaque traitement, la qualification des acteurs, au sens du RGPD, est identifiée.

Pour chaque traitement impliquant le recours à un sous-traitant ultérieur, l’analyse des finalités est effectuée et l’autorisation du responsable de traitement est obtenue.

La présence de traceurs mettant en œuvre une lecture ou une écriture sur le terminal de l’utilisateur final est indiquée précisément et explicitement, en explicitant les finalités poursuivies.

Le caractère optionnel ou obligatoire pour chacune des permissions requises par le SDK est indiqué, en fonction des fonctionnalités utilisées.

Les documentations et informations précitées sont à jour.

Les informations précitées sont formalisées dans la documentation contractuelle lorsqu’elles doivent l’être.

Une information spécifique est délivrée lorsque les mises à jour du SDK impliquent une évolution des traitements mis en œuvre.

Le registre des traitements distingue clairement les finalités associées à chaque traitement.

Si les finalités poursuivies dépendent du paramétrage du SDK, un registre dynamique ou distinct est mis à disposition, en fonction des possibilités de paramétrage du SDK, de sorte que le responsable de traitement puisse facilement identifier les éléments du registre qui correspondent à son paramétrage.

Le format du registre, par exemple sous forme de tableau, permet d’identifier facilement et de manière exhaustive chaque donnée collectée, ainsi que les éléments juridiques (base légale, finalité, obligations) et techniques (lectures, écritures) associés.

Des exemples de formulation relatives aux traitements effectués sont directement proposés, de sorte qu’un tiers partenaire puisse facilement les réutiliser pour ses propres recueils de consentements.

Des API sont mises à la disposition des tiers partenaires, lorsqu’ils reçoivent des demandes d’exercices de droits, de sorte que ces demandes puissent être répercutées de manière automatique dans les infrastructures techniques du SDK.

La mise en place de ces API n’utilise pas, ou le moins possible, d’identifiants additionnels, afin que ces demandes de droit puissent recevoir une réponse effective.

La seule obtention d’une permission ne peut être considérée comme indiquant que le consentement a été valablement recueilli pour les traitements effectués par le SDK

Le SDK est conçu techniquement pour permettre une suspension de son exécution tant qu’un consentement valable, par finalité, n’est pas recueilli.

Si plusieurs finalités sont poursuivies, le SDK permet techniquement la prise en compte d’un signal distinct par finalité, toujours indépendamment des permissions système.

Des alternatives sont proposées aux tiers partenaires dans le cas d’un refus de l’utilisateur final, afin de ne pas altérer la bonne exécution de l’application intégrant le SDK.

La révocation d’un consentement n’altère pas la bonne exécution de l’application du tiers partenaire, tant fonctionnellement que vis-à-vis l’expérience utilisateur (telle qu’une demande de consentement affichée en boucle).

Les demandes de permissions système s’effectuent pendant l’exécution de l’application plutôt que lors de son installation, lorsque cela est possible.

Se référer aux points 4.1.1-4.3.4 de la liste de vérifications relative aux développeurs.

Des rapports d’audits du SDK sont réalisés régulièrement et sont tenus à disposition des éditeurs partenaires et des autorités de protection des données qui en feraient la demande.

Le SDK peut être mis en pause par l’éditeur, à distance et en production, dans le cas où le résultat d’un audit entrainerait une incertitude juridique ou un dysfonctionnement technique.

Un processus technique et organisationnel relatif aux éventuelles violations de données est établi, qui prévoit la transmission d’informations aux responsables de traitement ainsi que le formalisme des notifications de violation aux autorités de protection des données.

Une veille régulière est appliquée sur les évolutions techniques des systèmes d’exploitation mobiles et des API qu’ils mettent à disposition, afin de renforcer les principes de protection dès la conception et de protection par défaut.

Une analyse des responsabilités est menée, portant sur le socle de l’OS, sur les briques fonctionnelles ajoutées à celui-ci ainsi que les traitements susceptibles d’être mise en œuvre par les applications et utilisés par les personnes.

Aucun traitement effectué pour le compte du fournisseur d’OS n’est effectué avant le recueil d’un consentement valide, y compris lors du premier lancement de celui-ci.

La création d’un compte n’est pas nécessaire pour utiliser l’OS et les applications préinstallées.

L’utilisation de serveurs de notifications tiers est possible. Leur utilisation est optimisée, notamment en termes d’exécution en tâche de fond et d’impact sur la batterie.

Des outils permettant le chiffrement du contenu des notifications est proposé, quel que soit le serveur de notification responsable de leur transmission. La mise à disposition de ces outils est accompagnée d’une documentation claire.

Un système de remontée de bogues et de gestion de terminaison inopinée conforme au principe de minimisation est proposé, incluant un consentement à la remontée du rapport de bogue.

Si un système de sauvegarde distant des paramètres et du contenu de l’OS est proposé, il n’est pas activé par défaut. Il fait l’objet d’un recueil de consentement et les données correspondantes sont transmises et stockées de manière chiffrée, au moyen d’une clé à laquelle le fournisseur de l’OS n’a pas lui-même accès.

La mise à disposition des données de localisation peut être limitée uniquement à l’utilisation du capteur GPS, sans mobiliser d’autres traitements.

La documentation à l’attention des développeurs tiers ainsi que celle à l’attention des utilisateurs finaux de l’OS sont à jour, facilement compréhensibles et exhaustives et comprennent des exemples pratiques.

Des éléments juridiques sont présents au sein de cette documentation et comprennent des exemples pratiques.

Les différentes documentations sont accessibles dans les langues des publics ciblés.

Les partenaires (développeurs tiers et éditeurs, magasins d’applications, constructeurs, etc.) sont en mesure de connaître, comprendre et documenter, conformément au principe de responsabilité (« accountability »), les traitements impliqués ou induits par l’utilisation de l’OS.

Les API proposées par l’OS permettent sont documentées pour permettre une décision éclairée quant à leur usage.

Une documentation spécifique est proposée aux développeurs et éditeurs pour les accompagner dans l’usage de nouvelles API ou nouvelles versions d’API dans la mesure où elles sont plus protectrices de la vie privée.

Les accès aux capteurs physiques, aux matériels d’accès au réseau et aux espaces de stockage des terminaux ne peuvent être effectués qu’après validation d’une permission par l’utilisateur final.

Les permissions permettant différents niveaux de précision laissent à l’utilisateur final, et non uniquement au développeur d’une application, le choix de ce niveau.

Les permissions peuvent être restreintes par l’utilisateur, sur une période temporelle et un nombre d’occurrences définis.

Les utilisateurs ont la possibilité de choisir le niveau d’information qu’ils souhaitent transmettre dans le cadre des permissions, notamment via une saisie manuelle de l’information à transmettre. Par exemple : transmettre une partie de son carnet de contact ou de sa médiathèque plutôt que l’intégralité (compartimentation de l’information).

Les permissions d’une application sont révoquées lorsqu’une application n’est pas utilisée depuis un certain temps. L’utilisateur est averti de cette révocation.

Les systèmes de permissions permettent à l’éditeur de fournir les informations pertinentes sur la portée de la permission demandée.

L’accès en cours aux capteurs physiques fait l’objet d’un signal visuel ou sonore au sein de l’interface de l’OS présentée à l’utilisateur final (pastille de couleur, sonnerie, vibration, etc.), permettant à l’utilisateur de déterminer quelle application est en train d’accéder à quel capteur.

L’utilisateur dispose d’un historique d’accès aux capteurs précités, horodaté et par application.

L’utilisateur dispose d’un moyen simple de définir si un rappel lui est proposé, concernant les permissions requises par les applications qu’il utilise, lui permettant de paramétrer une désactivation par défaut ou un rappel d’information des permissions requises après un certain temps de non-utilisation de ses applications.

Les permissions peuvent être facilement révoquées. L’accès aux menus permettant cette révocation est intuitif.

L’OS propose une portabilité des données, au sens du RGPD, permettant à l’utilisateur de migrer ses données et configurations vers un autre OS ou vers un même OS sur un autre terminal.

Des outils de contrôles parental sont mis à disposition des utilisateurs finaux.

Ces outils mettent un signal de minorité à disposition des développeurs, de sorte que l’utilisation de leurs applications puissent être restreinte ou bloquée en fonction des paramètres relatifs à un âge connu par l’OS.

Une compartimentation (« sandboxing ») est mise en œuvre, permettant de limiter et contrôler les interactions, l’accès à la mémoire et l’usage des permissions, entre l’OS et les applications.

Une compartimentation, à la fois technique et d’interface, est mise en œuvre dans l’OS, afin de pouvoir distinguer usages personnels et professionnels sur un même terminal physique.

Lorsque le matériel du terminal le permet, le stockage local de secret utilise le matériel dédié par défaut (enclave ou « SecureElement »).

Une contrainte technique et d’interface est appliquée sur la mise en œuvre des connexions réseaux (p. ex. : signalement de connexions non chiffrées, de certificat obsolète, forçage de TLS, etc.).

Des systèmes de partages locaux inter-applications, par exemple par API, sont mis à disposition par l’OS, de sorte qu’une application puisse communiquer des données de manière sécurisée à une autre application, sans que celles-ci ne nécessitent une transmission vers des serveurs extérieurs.

Les sauvegardes sont chiffrées par défaut, avec conservation de la clé de chiffrement exclusivement sous le contrôle de l’utilisateur.

Des bonnes pratiques de conception et de développement en matière de sécurité sont communiquées aux développeurs tiers.

Une documentation de ces outils et méthodologies d’audit est mise à disposition, de manière à faciliter le travail des acteurs amenés à les utiliser et à s’assurer de leur pleine compréhension des résultats observés.

Le support de chaque version de l’OS est assuré le plus longtemps possible.

Des mises à jour de sécurité sont proposées le plus longtemps possible, a minima 7 ans, indépendamment des mises à jour fonctionnelles.

Lorsque le support d’une version de l’OS s’achève, une information claire est délivrée aux développeurs et aux utilisateurs finaux.

Des éléments relatifs aux traitements, permissions demandées ou tiers accédants aux données sont demandés pour leur mise à disposition lors du processus de revue des applications.

Une politique de confidentialité et un point de contact sont définis et accessibles aux utilisateurs finaux, pour chaque éditeur d’application ayant au moins une application publiée dans le magasin.

Lorsqu’une application est destinée uniquement, majoritairement ou potentiellement à un public mineur, cette information est indiquée dans la page du magasin relative cette application.

Lors du processus de revue, les éditeurs sont invités à ne pas demander des permissions en bloc lors de l’installation et sont encouragés à avoir une gestion des permissions à l’exécution.

Le fournisseur de magasin d’applications peut inciter les éditeurs d’applications à ne pas utiliser d’API de l’OS qui seraient trop larges ou obsolètes

Les éditeurs sont invités à publier des notes de mises à jour informatives pour les utilisateurs afin qu’ils puissent évaluer la nécessité de la mise à jour.

Des analyses statiques sont effectuées sur chaque nouvelle application ou version d’application, avant toute publication dans le magasin.

Des analyses dynamiques sont effectuées sur les applications plus sensibles afin de détecter des comportements anormaux.

Dans le cas où l’application traite des données personnelles, est vérifié la présence des éléments suivants dans les informations aux usagers : • l'identité et les coordonnées du responsable du traitement • les finalités du traitement ainsi que sa base juridique • la durée de conservation des données personnelles • selon la base légale, l’existence d’un moyen d’expression des droits • le droit d’envoyer une plainte à l’autorité compétente

Les applications visant le marché européen qui ne sont pas en mesure de fournir ces éléments ne sont pas publiées dans le magasin d’application.

Les éditeurs d’applications sont correctement informés, notamment sur les éléments de conformité qui leur incombent selon les critères du magasin. La mise à jour de ces éléments, dans le temps, leur est communiquée.

Une gestion fine des accès aux comptes éditeurs du magasin d’applications est proposée, de sorte que plusieurs utilisateurs puissent avoir un usage distinct des dépôts, des signatures de versions, des notes de mises à jour.

Un canal clair de communication entre les entités publiant des applications mobiles et le magasin d’applications est affiché, en favorisant un canal intégré au magasin d’applications lui-même.

Les refus de publication et les correctifs à appliquer pour pallier ce refus ainsi que les éventuels recours sont indiqués clairement aux éditeurs et s’appuient sur les éléments de documentation dédiés.

L’ensemble des informations relatives à la vie privée, transmises par les éditeurs ou connue du magasin, sont accessibles à l’utilisateur final avant achat ou téléchargement.

L’ensemble des informations, requises ou utiles, à destination de l’utilisateur final sont affichées dans un format adapté au système dans lequel elles sont amenées à être consultées.

Des filtres relatifs à la vie privée sont proposés parmi les options de recherche.

Les utilisateurs finaux ont la possibilité de signaler des applications qui ne remplirait pas leurs obligations, directement depuis le magasin.

Un protocole est défini concernant les actions à mener lors de la détection, via une analyse statique ou dynamique, d’une vulnérabilité au sein d’une application mobile déjà publiée dans le magasin.

Un affichage spécifique est proposé aux utilisateurs finaux, intégré à la page de l’application dans le magasin, sur un potentiel risque pour la sécurité.