Persistent sessions et GDPR cookie consent

Soutien
1

Je mets en place un forum Discourse dans un environnement très soucieux de la confidentialité. Le problème actuel que je rencontre est le réglage persistent sessions (sessions persistantes), c’est-à-dire la fonction « se souvenir de moi » pour la connexion. Autant que je sache, le RGPD exige qu’un utilisateur donne son consentement explicite pour le stockage des cookies de fonctionnalité/préférence, ce qui inclut les sessions persistantes (car le cookie utilisé pour gérer une session persistante, ou plutôt sa durée de vie au-delà de la session du navigateur, n’est pas strictement nécessaire).

Cela conduit à deux choix peu attrayants :

  1. Désactiver les persistent sessions, obligeant chaque utilisateur soit à se connecter à chaque fois qu’il visite le forum, soit à leur suggérer/forcer d’utiliser le stockage de mots de passe du navigateur s’ils souhaitent éviter de se connecter manuellement à chaque fois. Cependant, comme nous utiliserons l’authentification unique (SSO) pour l’accès au forum, et qu’il existe de nombreux services différents accessibles via cette connexion SSO, obliger les utilisateurs à stocker leurs identifiants SSO juste pour accéder au forum n’est pas une bonne politique. Cela pourrait faire plus de mal que de bien.

  2. Activer les persistent sessions. Mais là, je ne vois pas de méthode réalisable pour intégrer une bannière de consentement aux cookies dans Discourse qui gère une valeur de configuration par utilisateur pour le drapeau des sessions persistantes. Ce dernier point est crucial car le consentement doit être donné par l’utilisateur, y compris la possibilité de rétracter ce consentement, ce qui nécessite une forme de bannière/solution de gestion des cookies.

Je suis actif sur un certain nombre de forums Discourse qui ont les persistent sessions activés mais ne fournissent pas d’option de consentement aux cookies (y compris ce méta-forum). Et il me semble qu’ils fonctionnent en violation du RGPD ?

Suis-je dans l’erreur dans ma lecture ci-dessus (car je ne suis pas avocat) ? Et existe-t-il vraiment des solutions viables qui intègrent une bannière de consentement aux cookies dans Discourse qui permette de configurer un réglage de cookie persistant par utilisateur ?

Edit : J’ai lu Cookie Consent, GDPR, and Discourse, et des publications comme Session Timeout - #56 by sam avant de poster, mais elles n’abordent pas vraiment le cœur du problème des sessions persistantes.

2

Voici maintenant deux choses différentes.

Légalement, selon le RGPD/la confidentialité des données, vous n’avez pas besoin du consentement pour une session persistante. Il s’agit d’un cookie technique pour un utilisateur et il n’est pas utilisé pour collecter des données personnelles. Bien sûr, vous devez indiquer qu’il est là, mais c’est à l’utilisateur de se déconnecter à chaque fois s’il veut éviter d’être mémorisé. Vous pouvez toujours l’offrir.

Et il y a ceci :

C’est un tout autre jeu et un tout autre terrain de jeu. Ici, dans les pays nordiques, tous les sites qui opèrent dans le secteur bancaire, les soins de santé de quelque manière que ce soit, les organismes gouvernementaux/locaux, etc., se déconnectent automatiquement après un certain temps ou après une période d’inactivité (espérons que ce soit vrai dans le monde entier) et les sessions persistantes sont alors impossibles. Il en va de même pour les sites qui sont, pour leurs propres raisons, très soucieux de la vie privée.

Si c’est le cas pour vous, je ne connais pas de solutions prêtes à l’emploi, mais voici de nombreux professionnels qui pourraient savoir.

Mais en général, vous n’avez pas besoin du consentement de l’utilisateur pour cela. Mais il peut y avoir des cas spéciaux où vous ne pouvez même pas l’offrir.

3

Le problème n’est pas qu’il ne collecte pas de données personnelles, le cookie _t vous identifie en tant que personne car il est directement lié à la session de votre compte utilisateur sur le serveur Discourse. Ainsi, avoir le cookie d’authentification défini dans votre navigateur signifie que vous êtes identifiable par le serveur chaque fois que vous utilisez votre navigateur pour visiter le site Web qui l’a défini (et donc vous n’êtes pas anonyme). D’après le Groupe de travail sur la protection des données de la Commission européenne Avis 04/2012 du WP 29 sur l’exemption du consentement aux cookies - 00879/12/EN WP 194 :

Les cookies de connexion persistants qui stockent un jeton d’authentification entre les sessions du navigateur ne sont pas exemptés en vertu du CRITÈRE B. C’est une distinction importante car l’utilisateur peut ne pas être immédiatement conscient du fait que la fermeture du navigateur n’effacera pas ses paramètres d’authentification. Il peut revenir sur le site Web en supposant qu’il est anonyme alors qu’en fait il est toujours connecté au service. La méthode couramment observée consistant à utiliser une case à cocher et une simple note d’information telle que « se souvenir de moi (utilise des cookies) » à côté du formulaire de soumission serait un moyen approprié d’obtenir le consentement, évitant ainsi la nécessité d’appliquer une exemption dans ce cas.

Notez qu’ils suggèrent une solution simple que les sites Web peuvent mettre en œuvre, une case à cocher « Se souvenir de moi » dans le formulaire de connexion, qui est bien sûr disponible presque partout de nos jours (mais pas dans Discourse). C’était une décision de 2012, donc avant l’entrée en vigueur du RGPD, mais je ne vois aucune information selon laquelle elle aurait été remplacée (par exemple, Cookie Consent Exemptions: Strictly Necessary Cookies - CookieYes mis à jour en août 2023 mentionne toujours que les cookies d’authentification persistants nécessitent un consentement). Mais il pourrait y avoir des développements ou des suivis juridiques que j’ignore.

4

Faux. C’est le seul point.

Ce n’est pas une collecte et un stockage de données personnelles qui peuvent ou seront utilisées pour identifier un utilisateur. Un forum sait de toute façon qui vous êtes.

5

Comment un forum sait-il qui vous êtes si vous le visitez avec un navigateur dans lequel ce cookie n’est pas défini ? Et vous devriez pouvoir utiliser un forum sans être suivi implicitement, à moins que vous n’ayez donné votre consentement explicite, dans ce cas, vous autorisez le cookie _t à persister après la fin de la session du navigateur.

6

Pour information, les informations ci-dessus sont incorrectes.

@paulmelis Je pense que vous avez raison et que c’est une bonne remarque.

Un cookie persistant nécessite une permission explicite, même s’il fournit une fonctionnalité spécifique à l’utilisateur : l’utilisateur doit avoir explicitement demandé la fonctionnalité.

Pour aggraver les choses, les diverses solutions existantes de « bannière de consentement aux cookies » actuellement disponibles pour Discourse, y compris le composant de thème officiel, ne sont pas conformes au RGPD. Elles informeront seulement l’utilisateur de la mise en place de ces cookies, mais si l’utilisateur ne clique pas sur le bouton « Je comprends », Discourse placera quand même ces cookies. En d’autres termes, ces solutions ne demandent pas la permission pour que quelque chose se produise, elles informent l’utilisateur que quelque chose se passe (ou pire : s’est déjà produit).

Ainsi, même si vous aviez une bannière de consentement aux cookies sur votre forum, si vous avez activé les sessions persistantes, vous êtes toujours en violation du RGPD.

Cela dit, je doute que ce soit un problème majeur en pratique, mais pour ceux d’entre nous qui recherchent une conformité à 100 %, c’est effectivement un problème.

Pour l’instant, votre seule option sera de désactiver le paramètre persistent sessions.

À première vue, cela semble tout à fait réalisable dans un plugin, bien qu’il serait beaucoup mieux si cela faisait partie du cœur de Discourse.

1 « J'aime »
8

Non, ce n’est pas le cas. Cela a été appliqué à maintes reprises par des juristes européens dans de grandes entreprises et cela n’a jamais changé.

Il faut encore se souvenir de la finalité et des objectifs du RGPD et de ses successeurs. Et pourquoi nous pouvons avoir des cookies techniques sans avoir besoin d’obtenir le consentement.

9

@paulmelis a fourni des citations de documents officiels de l’UE qui indiquent explicitement qu’ils ne sont pas autorisés par le RGPD.

Si vous avez des informations différentes, je suis tout ouïe, mais veuillez citer vos sources et fournir des liens vers les documents originaux.

10

Cela ne dit pas cela.

Sans offense, mais c’est aussi difficile, et un peu inutile, d’offrir la législation publique comme source, tout comme il est inutile de me guider vers les secrets de l’offre d’échange en proposant man swapon. Il y a une demande de connaissances et je peux lire ces pages de manuel, mais je ne comprends pas ce que je lis.

Je travaille avec cela quotidiennement et aucune de ces questions n’est nouvelle pour moi. C’est pourquoi je donne deux recommandations :

  • acheter le logiciel nécessaire et demander quel consentement est requis pour tout (cela n’aide pas car, après tout, c’est l’utilisation des données qui est importante, pas le consentement en soi)
  • si une entreprise est suffisamment grande (comme CDCK par exemple) qu’il y a un risque réel d’amendes, alors il faut utiliser la division juridique de l’entreprise ou un tiers de niveau professionnel.
11

C’est exact, c’est (malheureusement) ce que je fais maintenant.

Je suis vraiment curieux de savoir comment vous avez lu ce document alors. Je veux dire, 3.2 Cookies d’authentification l’explique assez clairement :

Les cookies d’authentification sont utilisés pour identifier l’utilisateur une fois qu’il s’est connecté (exemple : sur un site web bancaire en ligne). Ces cookies sont nécessaires pour permettre aux utilisateurs de s’authentifier lors de visites successives sur le site web et d’accéder à du contenu autorisé, tel que la consultation du solde de leur compte, des transactions, etc. Les cookies d’authentification sont généralement des cookies de session. L’utilisation de cookies persistants est également possible mais ils ne doivent pas être considérés comme identiques, comme discuté ci-dessous.

Reconnaît la nécessité des cookies d’authentification (notez, pas des cookies techniques nommés). Indique explicitement que la durée de vie de ces cookies, c’est-à-dire session vs persistants, implique qu’ils doivent être traités différemment.

Lorsqu’un utilisateur se connecte, il demande explicitement l’accès au contenu ou à la fonctionnalité à laquelle il est autorisé. Sans l’utilisation d’un jeton d’authentification stocké dans un cookie, l’utilisateur devrait fournir un nom d’utilisateur/mot de passe à chaque requête de page. Par conséquent, cette fonctionnalité d’authentification est une partie essentielle du service de la société de l’information qu’il demande explicitement. À ce titre, ces cookies sont exemptés en vertu du CRITÈRE B.

Cependant, il est important de noter que l’utilisateur n’a demandé que l’accès au site et à des fonctionnalités spécifiques pour effectuer la tâche requise. L’acte d’authentification ne doit pas être considéré comme une opportunité d’utiliser le cookie à d’autres fins secondaires telles que la surveillance comportementale ou la publicité sans consentement.

Se connecter signifie que l’utilisateur a donné son consentement pour être connecté, et non pour d’autres types d’utilisation de données via des cookies d’authentification définis.

Les cookies de connexion persistants qui stockent un jeton d’authentification entre les sessions du navigateur ne sont pas exemptés en vertu du CRITÈRE B. C’est une distinction importante car l’utilisateur peut ne pas être immédiatement conscient du fait que la fermeture du navigateur n’effacera pas ses paramètres d’authentification. Il peut revenir sur le site web en supposant qu’il est anonyme alors qu’en fait, il est toujours connecté au service. La méthode couramment observée consistant à utiliser une case à cocher et une simple note d’information telle que « se souvenir de moi (utilise des cookies) » à côté du formulaire de soumission serait un moyen approprié d’obtenir le consentement, annulant ainsi la nécessité d’appliquer une exemption dans ce cas.

Le CRITÈRE B étant :

le cookie est « strictement nécessaire pour que le fournisseur d’un service de la société de l’information explicitement demandé par l’abonné ou l’utilisateur fournisse le service ».

Ainsi, l’utilisateur doit donner son consentement avant que les cookies d’authentification persistants puissent être définis. Raison : vous ne pouvez pas vous attendre à ce qu’un utilisateur connaisse les implications de l’authentification persistante par défaut.

Oui, la législation est diffuse et complexe, avec de nombreuses mises à jour différentes sur près de deux décennies. Et même les sites officiels de l’UE que j’ai consultés semblent très désordonnés en ce qui concerne la manière dont ils gèrent les cookies et leurs politiques déclarées.

3 « J'aime »