PetitCalgonEt les données stockées dans Dropbox (enfin celles jusqu'au septembre 2018)?
Tu transmets donc à Dropbox la demande de Sysson de supprimer ses données utilisateurs?

Les backups ont tous été supprimés (vu qu'ils dataient de septembre 2018 ), et les nouveaux backups sont stockés chez moi. Vu qu'ils ne vont que jusque J-14, cela signifie que les données ne sont conservées que 14 jours. Donc si je supprime les données de la base "courante", ils ne mettront que 14 jours à disparaitre définitivement

Quant à Dropbox, je suppose qu'ils disposent d'un "historique" des fichiers transférés. Je ne sais pas dans quelle mesure "je" suis responsable de ces archives dès lors où je n'y ai plus accès moi-même. Aucune idée de ce que le RGPD dit à ce niveau ^^

SyssonUne question intéressante c'est quid des logs apache/nginx whatever, eux contiennent des adresses IP? Si quelqu'un sait ça m'intéresse^^

Excellente question, mais je pense que ça n'est pas couvert par le RGPD, car l'IP n'est pas associable à un utilisateur en particulier (il n'y a pas "d'identification" possible), et ces logs ont une finalité technique uniquement (et une durée de vie limitée). C'est donc une excellente question à poser à un expert RGPD

SyssonUn vrai casse tête cette rgpd, mais je suis bien content que ça force les boites à se poser les bonnes questions et ce quelle que soit leur taille. On a tous à y gagner.

Je pense qu'il est en effet illusoire d'espérer que les entreprises se conforment parfaitement au RGPD, tant les implications et difficultés techniques sont nombreuses. Par contre, ça "fixe la philosophie", et ça, c'est une bonne chose. Ca permet aussi d'attaquer assez "librement" n'importe quelle société qui ferait un usage "frauduleux" de ces données personnelles. J'imagine que si on attaque un site web/entreprise pour stockage des IP dans ses logs Apache/nginx, un juge sera vite saisi et tranchera en faveur de l'entreprise, à moins qu'on ne mette en évidence le fait que ces données sont exploitées, partagées ou revendues.

Au vu des amendes qui sont en train de tomber, je pense que ça fait plus que fixer la philosophie, et c'est une très bonne chose.

Pour ce qui est de la suppression, une anonymisation des données suffit, et c'est ce qui est souvent fait du coup, pour éviter de foutrez le boxon dans la Bdd.

yaugAu vu des amendes qui sont en train de tomber, je pense que ça fait plus que fixer la philosophie, et c'est une très bonne chose.

C'est le début, ça va se calmer d'ici quelques temps

Y a aussi des combats qui sont difficiles à gagner. Par exemple, ma boîte (une université) utilise énormément (honte à eux ) les services Microsoft (alors que tout était dev en interne jusqu'alors, mais y a un c.. d'informaticien-politicien qui a pris le contrôle de la partie informatique/infrastructure, et du coup il a poussé les solutions de ses potes de chez Microsoft, alors qu'on sait qu'il est consultant pour eux depuis 20 ans... conflit d'intérêt quand tu nous tiens !). Bref, récemment, ils ont décidé d'activer la fonction "SafeLinks" sur nos emails. En gros, pour tout email entrant, chaque lien est remplacé par un lien pointant chez Microsoft, soi-disant pour éviter le phishing.

1) On reçoit beaucoup de phishing ciblé sur notre université, et ils ne sont JAMAIS détectés comme tel par Microsoft;
2) Les liens sont illisibles dans le mail, à cause de l'encodage utilisé par MS comme suffixe à ses propres URL. Du coup, on ne sait pas vérifier "à priori" la véracité potentielle de l'adresse;
3) Les liens sont automatiquement visités par MS (mais alors pourquoi les masquer encore dans l'email ??), et ça déclenche des actions (genre se désinscrire d'une liste de diffusion, accepter/refuser les reviews de papiers, etc.). C'est SUPER pénible ! Par exemple, toutes mes notifications github/slack sont automatiquement considérées comme "lues" parce que le lien a été visité par MS au préalable !
4) L'adresse e-mail du destinataire (sic !!) est inclue dans l'URL générée par Microsoft. Ce qui veut dire que si je transfère un e-mail, mon adresse sera partie intégrante du contenu du mail transféré. Et si ce mail est transféré à son tour, c'est pareil. On se demande bien pourquoi MS a besoin de l'adresse du destinataire dans son "safelinks" !!
5) Ces incompétents du centre informatique ne permettent pas l'opt-out, se contentant de dire que le conseil d'administration leur a donné l'autorisation, il y a 10 ans environ, de faire appel à des services sur le cloud. Mais RIEN n'a été communiqué à ce sujet, et à aucun moment je n'ai donné mon consentement pour que mes données personnelles (incluant ma correspondance privée, ou les sites que je visite) soient transmises à une boîte américaine. Je suis même probablement l'un des seuls à refuser d'accepter le règlement sur la vie privée lors de la signature de mes contrats (car en gros, c'est un consentement pour "on peut faire tout ce qu'on veut avec vos données, allez vous faire foutre" ).

Et à coté de ça, l'idiot qui sert de recteur à l'unif va nommer docteur honoris causa une ado nordique qui se bat pour le climat, mais qui n'a rien prouvé du tout de sa vie jusqu'à présent. Et ouais, politique, quand tu nous tiens....

Coup de gueule fini

GuybrushExcellente question, mais je pense que ça n'est pas couvert par le RGPD, car l'IP n'est pas associable à un utilisateur en particulier (il n'y a pas "d'identification" possible), et ces logs ont une finalité technique uniquement (et une durée de vie limitée). C'est donc une excellente question à poser à un expert RGPD

Non, là, je ne suis pas d'accord, l'IP _est_ une donnée personnelle. En tant que telle, elle ne l'est pas, mais dans un log, elle est couplée à une date, une heure, une ligne de requête particulière, et une ligne d'identification du navigateur, incluant l'OS cible, la langue configurée, etc etc. Si à 12h32 l'IP 2.4.6.8 qui est un firefox sous BeOS en langue catalane a demandé l'affichage de la page /user/guybrush_tripouille/edit et que le serveur a correctement renvoyé un code 200 en lieu d'un 403, je peux également lier ce profil à une identité, au moins sur ce site.

....et en même temps, une partie du RGPD, c'est également les responsabilités face à une fuite de données. Or, là il y a contradiction, pour découvrir la fuite et comprendre le modus operendi et donc savoir s'il y a eu juste une tentative ou s'il y a eu fuite massive, il faut lire les logs et les analyser.

En lieu et place d'un logrotate d'un an (les logs sont stockés un an sur le serveur, 52 logs d'une semaine), je suis désormais plus partisan avec le RGPD de stocker uniquement 15 jours de logs, mais cela risque de poser soucis si une faille est découverte avec du retard.

J'ai eu une fois à répondre à une demande de renseignement sur les data stockées par un demandeur. Ça m'a pris une demi-journée complète, pour ne presque rien trouver, et écrire le rapport à destination de cette personne. J'apprécie le RGPD comme philosophie et comme cap ("arrêtez de faire de la merde avec nos datas"), mais répondre honnêtement à une demande de renseignement sur les traitements, c'est méga-chronophage !

TchouEn lieu et place d'un logrotate d'un an (les logs sont stockés un an sur le serveur, 52 logs d'une semaine), je suis désormais plus partisan avec le RGPD de stocker uniquement 15 jours de logs, mais cela risque de poser soucis si une faille est découverte avec du retard.

Rien n'empêche de garder ces logs plus longtemps, mais en retirant ou hashant l'IP. Il n'est pas clair non plus avec le RGPD ce qu'on doit faire avec les données (1) partiellement anonymisées (par exemple, retirer l'IP mais garder la trace de navigation : avec du recoupement, on peut retrouver l'identité !) et (2) les données agrégées (par exemple, des profils utilisateurs pour du marketing, où on retient juste "x% des habitants de cette ville sont intéressés par..."). Je suis assez exposé avec ce second cas, car je fais pas mal d'analyses empiriques pour le boulot, et à chaque fois on agrège les données, et on publie les résultats (y compris le dataset). Dans quelle mesure cela peut-il être assimilé à une violation du RGPD ? Ca pose aussi la question du "data lineage" puisqu'il faudrait garder, idéalement, une traçabilité complète pour chaque donnée ("quelles sont les données ''brutes'' ayant servi à calculer cette donnée agrégée?").

TchouJ'ai eu une fois à répondre à une demande de renseignement sur les data stockées par un demandeur. Ça m'a pris une demi-journée complète, pour ne presque rien trouver, et écrire le rapport à destination de cette personne. J'apprécie le RGPD comme philosophie et comme cap ("arrêtez de faire de la merde avec nos datas"), mais répondre honnêtement à une demande de renseignement sur les traitements, c'est méga-chronophage !

Je veux bien le croire, mais j'imagine qu'assez rapidement, vous allez avoir des procédures semi-automatiques pour générer de tels rapports, non ? Je sais que Lexpage n'est pas DU TOUT comparable à ce qu'une entreprise ou administration peut faire avec des données, mais dans le cas du Lexpage, il devrait m'être assez simple de sortir toutes les données en lien avec un utilisateur, sur base de la clé primaire. Evidemment, il reste la question de la "complétude" de ces informations (mais que dit le RGPD à cet égard, surtout quand c'est involontaire et, à priori, sans conséquence ?). Par exemple, si je génère un rapport avec toutes les données en db Lexpage pour un utilisateur, est-ce que je risque quelque chose si j'oublie d'y joindre les logs serveurs ? Les logs Matomo ?