Le site zestedesavoir.com et le RGPD

Salut les agrumes,

Je relance le sujet du RGPD pour zestedesavoir.com. Le site lui-même respecte le RGPD (en tous cas à ma connaissance !) et ne piste pas ses utilisateurs ; néanmoins il autorise l’accès à des éléments tiers qui, eux, peuvent poser problème. Je pense à ces catégories :

1. Les éléments de design du site (typiquement des choses hébergées sur dnjs.cloudflare.com), qui sont assez faciles à faire servir directement par notre serveur, et qui ne déposent pas de cookies ou de stockage local.
2. Les avatars des utilisateurs, qui sont par défaut (je crois ?) sur secure.gravatar.com et qui peuvent être littéralement n’importe quoi. Cela dit, je n’ai vu ni cookies ni stockage local associé à ces avatars, le problème ne me semble ni urgent, ni très important.
3. Le plus problématique : l’intégration des vidéos. Le simple fait d’afficher une page qui contient un intégration YouTube (la plus utilisée de loin) envoie un déluge de requêtes vers Google, et stocke au moins ce genre de chose dans le stockage de session :

(Non connecté, mode navigation privée, aucun clic sur une vidéo, uBlock Origin activé).

J’avoue ne pas être certain de la responsabilité de ZdS dans ce genre d’intégration, mais ça vaudrait le coup qu’on se renseigne et qu’on voie ce qu’il y a à faire.

Puisqu’on en parle, je pense que la base de données de localisation d’IP est trop précise au niveau de la ville (et pas à jour) pour les besoins de la modération, et tout le staff a accès à cette info sur tous les membres (pas que la modération).

Je réponds rapidement sur les différents points :

1. Les éléments de design du site (typiquement des choses hébergées sur dnjs.cloudflare.com), qui sont assez faciles à faire servir directement par notre serveur, et qui ne déposent pas de cookies ou de stockage local.

Il me semble qu’il y a des tickets ouverts qui traitent de ce sujet (là sur le coup je n’arrive pas à les retrouver), mais je suis pour ne plus dépendre de CDN.

2. Les avatars des utilisateurs, qui sont par défaut (je crois ?) sur secure.gravatar.com et qui peuvent être littéralement n’importe quoi. Cela dit, je n’ai vu ni cookies ni stockage local associé à ces avatars, le problème ne me semble ni urgent, ni très important.

Je suis d’accord : pas urgent, il me semble.

3. Le plus problématique : l’intégration des vidéos. Le simple fait d’afficher une page qui contient un intégration YouTube (la plus utilisée de loin) envoie un déluge de requêtes vers Google

Je ne sais pas ce qui est faisable techniquement, mais il me semble déjà avoir vu des sites où il faut d’abord cliquer sur un bouton de consentement avant d’afficher le contenu de la vidéo (peut-être que c’est directement géré par Youtube et qu’il faut adapter le morceau code HTML qu’on utilise pour afficher les vidéos).

Puisqu’on en parle, je pense que la base de données de localisation d’IP est trop précise au niveau de la ville (et pas à jour) pour les besoins de la modération, et tout le staff a accès à cette info sur tous les membres (pas que la modération).

Elle devrait être à jour (on récupère la nouvelle base une fois par semaine). Pour la question de la précision, si tout le monde est d’accord pour n’afficher que le pays, je suis OK pour le mettre en place. Et si on est d’accord que seule la modération doit pouvoir voir ces infos, ça se fait aussi facilement dans notre code.

En résumé : si on est d’accord sur ce qu’on veut, rien de compliqué techniquement, il nous fait seulement des bénévoles qui veulent bien le faire.

Sur les adresses ip, il manque surtout l’anonymisation quand la connexion date d’il y a plus de 1 an

Sur les adresses ip, il manque surtout l’anonymisation quand la connexion date d’il y a plus de 1 an

Tu parles uniquement du lien IP <> membre ? Il faudrait que si ça fait plus d’un an qu’un membre ne s’est pas connecté, alors on efface toutes les IPs liées à ce membre ?

Oui, il me semble que c’est ça la durée maximale de conservation.

Il y a aussi le log nginx, si j’ai bien compris, parce qu’on n’a qu’une expiration à la taille du fichier ? Mais on n’a probablement pas 1 an d’historique si c’est le cas.

Concernant les IP, il ne faut pas oublier non plus celles liées aux messages. Là encore, il s’agit d’une obligation légale d’un an si ma mémoire est bonne. Bref, il y a du pain sur la planche pour ce sujet !

Il y a aussi le log nginx, si j’ai bien compris, parce qu’on n’a qu’une expiration à la taille du fichier ? Mais on n’a probablement pas 1 an d’historique si c’est le cas.

Non, on devrait garder 1 an de log. (je viens de faire un tour dans les logs du serveur de prod, ça ne semble pas complètement clair, je me note qu’il faut que je vérifie ça)

En résumé, voici les tâches à faire :

• Ne plus utiliser le CDN de CloudFlare pour FontAwesome (PR fusionnée)
• Ne plus utiliser le CDN de CloudFlare pour MathJax (PR fusionnée)
• Ne plus utiliser Gravatar pour les avatars par défaut (utiliser pydenticon5 à la place, qui génère des images dans le même style qu’actuellement comme cette image utiliser Jdenticon, PR en développement)
• Ne plus utiliser Google Fonts pour les polices de caractère (PR fusionnée)
• Ajouter des boutons de consentement avant de charger des vidéos ou autres intégrations externes (je n’ai pas trouvé d’autres projets que celui-ci que l’on pourrait réutiliser mais je n’ai peut-être pas trouvé les bons mots-clés, utiliser IframeManager, PR en développement)
• Ajouter un script pour supprimer les adresses IP stockées plus d’un an (dans les profils utilisateurs ainsi que dans les messages du forum, les commentaires et les messages privés, PR en développement)
• Réduire la précision de la géolocalisation, de la date d’inscription et de la date de dernière connexion des membres (respectivement, seulement le pays et seulement la date, avec éventuellement l’exception des modérateurs ?)

Attention, pydenticon5 et youtube-embedding-consent semblent abandonnés depuis des années (mais c’est peut-être facile à reprendre).

Pour pydenticon5, le code utilise Pillow et fait 150 lignes donc on devrait pouvoir aisément le reprendre un jour si besoin. Il est d’ailleurs utilisé par libravatar et c’est comme ça que je l’ai trouvé.

Pour youtube-embedding-consent, je suis étonné de ne pas avoir trouvé de projet maintenu et populaire étant donné que c’est un besoin qui touche en théorie beaucoup de sites web, mais en pratique très peu doivent s’y intéresser.

J’ai une question, si on héberge les libs et qu’on les distribue nous-mêmes, est-ce que ça ne fait pas des téléchargements en plus pour les gens qui les auraient déjà en cache en navigant sur d’autres sites ? Est-ce que ça aurait un impact sur les nouveaux visiteurs qui arriveraient avec une mauvaise connexion ?

Techniquement si ; en pratique vue la taille des fichiers on s’en fiche, on parle de quelques dizaines de Ko.

Ça peut avoir l’effet inverse : grâce à HTTP/2, tout transite sur une seule connexion TCP, après un seul handshake TLS, après une seule résolution DNS.

On peut aussi mettre du cache infini (si l’asset a un nom unique).

En remplacement de Gravatar, on pourrait utiliser Jdenticon pour générer les avatars par défaut à partir du pseudo (au lieu du hash de l’adresse de courriel) directement dans le navigateur (réduction des requêtes) et en SVG (donc léger car image à motifs).

Pour ce qui est des intégrations vidéos et autres contenus externes, je viens de tomber sur IframeManager qui fait exactement ça, semble bien maintenu et est configurable (donc on devrait pouvoir l’utiliser pour toutes nos intégrations avec un peu de chance). Par contre, ça demandera de modifier la sortie de zmarkdow en conséquence, mais je pense que peu importe la bibliothèque utilisée ce sera nécessaire dans tous les cas.

Je suis en train de lire la PR sur le remplacement de Gravatar et j’ai une question : quel est le problème de Gravatar vis-à-vis du RGPD ? Est-ce que c’est :

• le navigateur d’un internaute visitant zds ne doit pas faire de requêtes à Gravatar ?

ou bien :

• zds ne doit pas tenter par défaut de chercher un avatar chez Gravatar puisque ça communique l’adresse mail à Gravatar

Je pense que c’est plutôt le deuxième point, mais je préfère en être sûr (mais pourquoi on autoriserait des requêtes à Gravatar mais pas aux CDN ? question exprès un peu naïve)

Et ma question confirme le besoin d’un page dans notre documentation qui préciserait ce qu’on fait vis-à-vis du RGPD).

Personnellement, c’est l’utilisation par défaut de Gravatar que je trouve problématique car ça génère une requête par avatar, vers un service externe et avec un hash de l’adresse de courriel du membre.

Ensuite, le fait d’autoriser les avatars externes (qu’ils proviennent de Gravatar ou d’ailleurs) peut aussi être considéré comme problématique car on ne contrôle pas le contenu affiché ni les cookies éventuellement déposés ni un éventuel suivi des requêtes réceptionnées. Après, c’est à nous de voir quel niveau de paranoïa on souhaite appliquer ici.

Enfin, vis à vis du RGPD, je ne saurais pas vraiment dire si notre utilisation actuelle de Gravatar est problématique ou non.

À noter que Gravatar permet de définir un vrai avatar personnalisé en réponse à la requête, au lieu du motif géométrique automatique. À voir si ça vaut le coup de prévenir les membres que le cas échéant ils devront utiliser le système interne à ZdS s’ils veulent garder cette personnalisation.

Je ne sais pas si la fonctionnalité est beaucoup utilisée.

Les IP sont des données à caractères personnelles, donc on ne devrait pas les transmettre sans le consentement de l’utilisateur. Je dirai que le premier nécessiterai un bandeau qu’on a pas (ce n’est pas que pour les cookies).

Après, si on veut une vraie analyse RGPD, j’ai vu que @deuchnord avait le contact d’Aeris, qui connait très bien le sujet.

Après, si on veut une vraie analyse RGPD, j’ai vu que @deuchnord avait le contact d’Aeris, qui connait très bien le sujet.

Aeris a une interprétation très personnelle et extrême du RGPD ; en particulier en tant qu’association je me méfierais de ses positions sur le sujet, car il a l’habitude de traiter le cas des (grosses) entreprises. Or il y a des règles qui changent selon le volume de données traitées. Exemple.

PS : pour le cas particulier des associations, la CNIL a publié un guide.