le mode de traitement des auteurs SPIP qui consiste à le mettre à la poubelle pour le supprimer me semble contraire au Règlement Général de Protection des Données (personnelles).
En principe, si on supprime un utilisateur, c’est qu’on en veut plus, qu’on en a plus besoin. Et le RGPD interdit de garder sous le coude des données personnelles dont la finalité n’est pas justifiée.
Je propose que l’action de mise à la poubelle anonymise l’auteur (nom/prénom/email/clé/url remplacé par un hash par ex.).
Bien sûr c’est le type de traitement qu’il faudra adapter pour les plugins auteur étendu et champs extras (en ajoutant une case “donnée à caractère personnel” voire “donnée sensible”).
sur le plugin mailsubscribers on a une fonction d’anonymisation de ce type pour les gens qui se désinscrivent de tout, le but étant de conserver une trace pour ne pas risquer de les réinscrire par erreur sans pour antant avoir leurs infos en clair.
Ce n’est pas toujours compréhensible pour tout le monde, c’est un aspect user à traiter.
Mais surtout il ne faut surtout jamais le faire *immediatement* car une fois les infos hashées tu ne sais pas revenir en arrière.
Donc en cas de fausse manip ou de changement d’avis tu es vite très embêtés.
Il me semble que cela pourrait faire l’objet d’un plugin RGPD qui se charge d’anonymiser les informations nécessaires en tache cron, avec des délais adaptés ou configurables pour chaque type d’information et sa sensibilité…
Il y a potentiellement des implications techniques à réflechir, sur la réinscription, les collisions éventuelles sur l’unicité du login hashé vs pas hashé etc.
Donc traiter ça dans un plugin me parait à la fois plus souple et permet de tester sur des sites avant de généraliser un truc pas anodin.
Le #RGPD concerne tous les organismes qui manipulent des données identifiant de manière directe ou indirecte des personnes en Europe.
Même des adresses IP sont concernées.
Les cookies bar sont effectivement concernées car en principe il faudrait en vrai interdire toute collecte de cookie. Cela devrait déjà être le cas, mais en pratique c’est souvent un simple message avec quelques liens vers une page d’info. Mais le consentement préalable à toute collecte doit désormais se faire " de façon libre, spécifique, éclairée et univoque ". Cela renforce pas mal de trucs
Il y a d’autres plugin pour lesquels il faudra être vigilent car ils sont moyennement conformes au RGPD : je pense particulièrement au plugin Adminer. Avoir une action plus contraignante pour mieux vérifier les droits d’accès serait un plus pour respecter le “privacy by default”.
Dans le même goût, je pense qu’il faudrait aussi encrypter les sauvegardes (de toute manière, il sera illégal de copier des bases d’un site à un autre sans l’accord des individus concernés
Je ne connais pas précisément le fonctionnement des plugins de newsletter, mais il faudra mettre en place (si ce n’est pas le cas) un opt-in (voire un double opt-in) avec un message précis (et contextualisé) sur l’utilisation des données collectées.
Pas grand chose donc, juste quelques formulaires à nettoyer probablement
J’ai le sentiment que le plugin Formulaire et Tables n’est absolument pas conforme actuellement. Il faudrait que chaque colonne ait un flag “donnée à caractère personnel” pour un traitement (affichage, modification, anonymisation, export, …) spécifique.
Idéalement, il faudrait avoir un espace collaboratif pour communiquer sur le RGPD et aider les développeur à mettre à jour leurs devs. cela pourrait se faire sous la forme d’un mini-site rgpd.spip.net avec des infos explicatives et un forum dédié. Qu’en dites-vous ?
Pas sûr que cela ne concerne que l’Europe… Car il me semble qu’un pays hors EU s’il traite les données de ressortissants européens doit respecter les consignes du RGPD pour ces derniers.
cedric@yterium.com a écrit le 21/02/2018 à 18:04 :
Hello,
Il me semble que cela pourrait faire l’objet d’un plugin RGPD qui se charge d’anonymiser les informations nécessaires en tache cron, avec des délais adaptés ou configurables pour chaque type d’information et sa sensibilité…
Je viens de participer à 2 conférences sur le RGPD et j'ai retenu quelques aspects principaux :
- dans les formulaires, il faudrait systématiquement rajouter un champ qui décrit les traitements que l'on compte faire avec les données collectées, et y adjoindre une case à cocher de "consentement explicite" (avec l'idée qu'on ne doit pas enregistrer les données si la case n'est pas cochée).
- qu'il y a un problème difficilement soluble : en cas de crash et de restauration des données, il ne faudrait pas se retrouver avec des enregistrements de données personnelles effacées ou modifiées qui réapparaitraient...
- on doit pouvoir donner aux personnes un droit d'accès (consultation), modification et suppression de leurs données personnelles (dans le respect de la loi, par exemple, on ne peut pas supprimer une facture / Aparté : si c'est dans le dossier local que se trouve le PDF, il ne sera pas forcément conservé). Avec la difficulté si on a collecté des données sont créer un compte utilisateur de "prouver" son identité et donc son droit d'accès (en pratique, courrier papier avec photocopie de la carte d'identité).
- en indépendamment de tout ça, il faut tenir un registre des traitements. Modèle CNIL tableur ici : Cartographier vos traitements de données personnelles | CNIL
- dans les formulaires, il faudrait systématiquement rajouter un champ qui décrit les traitements que l'on compte faire avec les données collectées, et y adjoindre une case à cocher de "consentement explicite" (avec l'idée qu'on ne doit pas enregistrer les données si la case n'est pas cochée).
- qu'il y a un problème difficilement soluble : en cas de crash et de restauration des données, il ne faudrait pas se retrouver avec des enregistrements de données personnelles effacées ou modifiées qui réapparaitraient...
- on doit pouvoir donner aux personnes un droit d'accès (consultation), modification et suppression de leurs données personnelles (dans le respect de la loi, par exemple, on ne peut pas supprimer une facture / Aparté : si c'est dans le dossier local que se trouve le PDF, il ne sera pas forcément conservé). Avec la difficulté si on a collecté des données sont créer un compte utilisateur de "prouver" son identité et donc son droit d'accès (en pratique, courrier papier avec photocopie de la carte d'identité).
Je m'interroge sur la portée de ce RGPD :
quid de la version numérique d'informations publiées sur un magazine en papier ?
Le papier ne peut être effacé ou modifié.
Les scans ou publication web du contenu publié n'en sont qu'un reflet numérique.
même s'ils sont stockés en BDD.
Du coup dans quelle mesure ces données sont elles soumises à au RGPD ?
Sauf que ça veut rien dire "les formulaires". Le RGPD, tout comme les
trucs de la CNIL, ça ne s'est jamais appliqué à TOUS les formulaires du
monde. Ça s'applique seulement à certains formulaires qui gèrent des
*données personnels*. Donc c'est seulement ces formulaires-là qui
doivent être ok.
Parmi ceux là, il y en a dans le noyau car on récolte email et nom. Et
dans Formidable par exemple ça ne concernerait pas du tout l'ensemble
automatiquement, mais seulement ceux où on décide de demander email, nom
des gens etc. Et donc ça serait forcément une option "être ok avec le
RGPD" à activer explicitement pour tel ou tel formulaire, mais pas
l'ensemble.
Sauf que ça veut rien dire "les formulaires". Le RGPD, tout comme les
trucs de la CNIL, ça ne s'est jamais appliqué à TOUS les formulaires du
monde. Ça s'applique seulement à certains formulaires qui gèrent des
*données personnels*. Donc c'est seulement ces formulaires-là qui
doivent être ok.
Parmi ceux là, il y en a dans le noyau car on récolte email et nom. Et
dans Formidable par exemple ça ne concernerait pas du tout l'ensemble
automatiquement, mais seulement ceux où on décide de demander email, nom
des gens etc. Et donc ça serait forcément une option "être ok avec le
RGPD" à activer explicitement pour tel ou tel formulaire, mais pas
l'ensemble.
Certes.
Mais là où ça devient subtil, c'est que :
contact@societe.tld : pas une donnée personnelle
nom.prenom@societe.tld : donnée personnelle
Et quand on fait du BtoB (pardon), avec en face un auto-entrepreneur, c'est *forcément* une donnée personnelle (et pas une personne morale).
Bref, rien qu'un abonnement à une newsletter, avec *juste* l'adresse email et rien d'autre n'est pas conforme au RGPD au niveau du consentement (sauf à considérer que renseigner l'email est un consentement explicite suite à une explication des finalités du remplissage).
Je travaille aussi sur le sujet pour une collectivité (Région).
J'ai mis en place une version surchargée de cookiebar qui permet d'insérer un modèle dans une page avec un formulaire "J'accepte / Je refuse les cookies", pour que les visiteurs puissent modifier leurs choix à tout moment.
Je me suis intéressé aussi aux vidéos youtube insérées, les rédacteurs collent des iframes qui posent des cookies, on va passer à oembed surchargé là aussi, pour ne pas lire les vidéos tant qu'ils n'ont pas expressément accepté les cookies.
