Sessioni persistenti e consenso cookie GDPR

Sto configurando un forum Discourse in un ambiente molto attento alla privacy. L’ostacolo attuale che sto incontrando è l’impostazione persistent sessions (sessioni persistenti), ovvero il “ricordami” per l’accesso. Per quanto ne so, il GDPR richiede all’utente di dare un consenso esplicito per la memorizzazione di cookie funzionali/di preferenza, che include le sessioni persistenti (poiché il cookie utilizzato per gestire una sessione persistente, o meglio la sua durata oltre la sessione del browser, non è strettamente necessario).

Ciò porta a due scelte poco attraenti:

  1. Disabilitare persistent sessions, costringendo ogni utente ad accedere ogni volta che visita il forum, o a suggerire/forzare l’uso dell’archiviazione delle credenziali basata sul browser se si desidera evitare di accedere manualmente ogni volta. Tuttavia, poiché utilizzeremo l’SSO per l’accesso al forum, e ci sono molti servizi diversi accessibili tramite quell’accesso SSO, far memorizzare agli utenti le credenziali SSO solo per accedere al forum non è una buona politica. Potrebbe fare più danni che benefici.

  2. Abilitare persistent sessions. Ma qui non vedo un metodo praticabile per avere un banner di cookie integrato in Discourse che gestisca un valore di configurazione per utente dell’impostazione delle sessioni persistenti. Quest’ultimo è cruciale poiché il consenso deve essere dato dall’utente, inclusa la possibilità di ritirare tale consenso, il che richiede una qualche forma di banner/soluzione di gestione dei cookie.

Frequento diversi forum Discourse che hanno persistent sessions abilitato ma non forniscono un’opzione di consenso ai cookie (incluso questo meta forum). E mi sembra che stiano operando in violazione del GDPR?

Sto interpretando male quanto sopra (dato che non sono un avvocato)? E ci sono davvero soluzioni valide che integrano un banner di consenso ai cookie in Discourse che consente di configurare un’impostazione di cookie persistente per utente?

Modifica: Ho letto Cookie Consent, GDPR, and Discourse, e post come Session Timeout - #56 by sam prima di pubblicare, ma non arrivano davvero al nocciolo della questione delle sessioni persistenti.

Ecco ora due cose diverse.

Legalmente, secondo il GDPR/privacy dei dati, non è necessario il consenso per una sessione persistente. Si tratta di un cookie tecnico per un utente e non viene utilizzato per raccogliere dati personali. Certo, devi dire che c’è, ma è compito dell’utente disconnettersi ogni volta se vuole evitare di essere ricordato. Puoi ancora offrirlo.

E poi c’è questo:

Quello è un gioco e un campo da gioco totalmente diverso. Qui nei paesi nordici tutti i siti che operano nel settore bancario, sanitario in qualsiasi modo, enti governativi/locali ecc. si disconnettono automaticamente dopo un certo periodo di tempo o dopo un periodo di inattività (si spera che sia vero in tutto il mondo) e quindi quelli persistenti sono impossibili. E lo stesso vale per i siti che, per le loro ragioni, sono molto attenti alla privacy.

Se questo è vero nel tuo caso, non conosco soluzioni pronte all’uso, ma qui ci sono molti professionisti che potrebbero/sapranno.

Ma in generale non è necessario il consenso dell’utente per questo. Ma ci possono essere casi speciali in cui non puoi nemmeno offrirlo.

Il punto non è che non raccolga dati personali, il cookie _t ti identifica come persona poiché è direttamente collegato alla sessione del tuo account utente sul server Discourse. Pertanto, avere il cookie di autenticazione impostato nel tuo browser significa che sei identificabile per il server ogni volta che utilizzi il tuo browser per visitare il sito web che lo ha impostato (e quindi non sei anonimo). Dalla Task Force per la protezione dei dati della Commissione europea Opinione WP 29 04/2012 sul consenso ai cookie - 00879/12/EN WP 194:

I cookie di accesso persistente che memorizzano un token di autenticazione tra le sessioni del browser non sono esentati ai sensi del CRITERIO B. Questa è una distinzione importante perché l’utente potrebbe non essere immediatamente consapevole del fatto che la chiusura del browser non cancellerà le sue impostazioni di autenticazione. Potrebbe tornare sul sito web presumendo di essere anonimo, mentre in realtà è ancora connesso al servizio. Il metodo comunemente osservato di utilizzare una casella di controllo e una semplice nota informativa come “ricordami (utilizza cookie)” accanto al modulo di invio sarebbe un mezzo appropriato per ottenere il consenso, negando così la necessità di applicare un’esenzione in questo caso.

Nota che suggeriscono una semplice soluzione che i siti web possono implementare, una casella di controllo “Ricordami” nel modulo di accesso, che ovviamente è disponibile quasi ovunque in questi giorni (ma non in Discourse). Questa è stata una decisione del 2012, quindi prima che il GDPR entrasse in vigore, ma non vedo alcuna informazione che sia stata superata (ad esempio, Cookie Consent Exemptions: Strictly Necessary Cookies - CookieYes aggiornato nell’agosto 2023 menziona ancora che i cookie di autenticazione persistente richiedono il consenso). Ma potrebbero esserci sviluppi legali di cui non sono a conoscenza.

Sbagliato. È l’unico punto.

Questa non è la raccolta e l’archiviazione di dati personali che possono o saranno utilizzati per identificare un utente. Un forum sa comunque chi sei.

Come farà un forum a sapere chi sei se lo visiti con un browser in cui quel cookie non è impostato? E dovresti essere in grado di usare un forum senza essere tracciato implicitamente, a meno che tu non abbia dato il consenso esplicito per questo, in questo caso permetti al cookie _t di persistere dopo la sessione del browser.

Per la cronaca, le informazioni di cui sopra sono errate.

@paulmelis Penso che tu abbia ragione e che questa sia un’ottima osservazione.

Un cookie persistente richiede un permesso esplicito anche se fornisce una funzionalità specifica all’utente: l’utente deve aver richiesto esplicitamente la funzionalità.

A peggiorare le cose, le varie soluzioni esistenti per il “banner di consenso ai cookie” attualmente disponibili per Discourse, incluso il componente tematico ufficiale, non sono conformi al GDPR. Informeranno solo l’utente di questi cookie che vengono impostati, ma se l’utente non fa clic sul pulsante “Ho capito”, Discourse imposterà comunque felicemente quei cookie. In altre parole, queste soluzioni non chiedono il permesso che accada qualcosa, informano l’utente che sta accadendo qualcosa (o peggio: è già successo).

Quindi, anche se avessi un banner di consenso ai cookie sul tuo forum, se hai abilitato le sessioni persistenti, sei comunque in violazione del GDPR.

Detto tutto questo, dubito che questo sarà un grosso problema in pratica, ma per quelli di noi che cercano la conformità al 100% questo è effettivamente un problema.

Per ora, la tua unica opzione sarà disabilitare l’impostazione persistent sessions.

A prima vista, questo sembra molto fattibile in un plugin, anche se sarebbe molto meglio se fosse nel core di Discourse.

1 Mi Piace

No, non lo è. Questo è stato applicato tramite avvocati UE in grandi imprese così tante volte e non è mai cambiato.

Devo ancora ricordare qual è lo scopo e gli obiettivi del GDPR e dei suoi successori. E perché possiamo avere cookie tecnici senza bisogno di ottenere il consenso.

@paulmelis ha fornito citazioni da documenti ufficiali dell’UE che affermano esplicitamente che non sono consentiti dal GDPR.

Se hai informazioni diverse, sono tutt’orecchi, ma cita le tue fonti e fornisci link ai documenti originali.

Non dice questo.

Senza offesa, ma è difficile e in un certo senso inutile offrire la legislazione pubblica come fonte, così come è inutile guidarmi verso i segreti dello swap offrendo man swapon. C’è una richiesta di conoscenza e posso leggere quelle man page, ma non capisco quello che leggo.

Ci lavoro quotidianamente e nessuna di queste domande è nuova per me. Ecco perché do due raccomandazioni:

  • acquista il software necessario e chiedi quale consenso è richiesto per tutto (non aiuta perché, dopo tutto, è importante come vengono utilizzati i dati, non il consenso in sé)
  • se un’azienda è abbastanza grande (come CDCK, ad esempio) da rischiare effettivamente multe, allora deve utilizzare la divisione legale dell’azienda o un professionista di terze parti di livello 3

Giusto, è quello che sto facendo (purtroppo) ora.

Sono davvero curioso di sapere come hai letto quel documento. Voglio dire, 3.2 Cookie di autenticazione lo spiega abbastanza chiaramente:

I cookie di autenticazione vengono utilizzati per identificare l’utente una volta che ha effettuato l’accesso (ad esempio: su un sito web di online banking). Questi cookie sono necessari per consentire agli utenti di autenticarsi nelle visite successive al sito web e ottenere l’accesso a contenuti autorizzati, come la visualizzazione del saldo del proprio conto, delle transazioni, ecc. I cookie di autenticazione sono solitamente cookie di sessione. È anche possibile l’uso di cookie persistenti, ma non devono essere considerati identici, come discusso di seguito.

Riconosce la necessità di cookie di autenticazione (notare, non cookie tecnici denominati). Afferma esplicitamente che la durata di questi cookie, cioè sessione vs persistente, implica che debbano essere trattati in modo diverso.

Quando un utente accede, richiede esplicitamente l’accesso al contenuto o alla funzionalità a cui è autorizzato. Senza l’uso di un token di autenticazione memorizzato in un cookie, l’utente dovrebbe fornire nome utente/password ad ogni richiesta di pagina. Pertanto, questa funzionalità di autenticazione è una parte essenziale del servizio della società dell’informazione che sta esplicitamente richiedendo. Come tali, questi cookie sono esentati ai sensi del CRITERIO B.

Tuttavia, è importante notare che l’utente ha richiesto solo l’accesso al sito e a funzionalità specifiche per eseguire il compito richiesto. L’atto di autenticazione non deve essere preso come un’opportunità per utilizzare il cookie per altri scopi secondari come il monitoraggio comportamentale o la pubblicità senza consenso.

Accedere significa che l’utente ha dato il consenso per essere loggato, non per altri tipi di utilizzo dei dati tramite eventuali cookie di autenticazione impostati.

I cookie di accesso persistenti che memorizzano un token di autenticazione tra le sessioni del browser non sono esentati ai sensi del CRITERIO B. Questa è una distinzione importante perché l’utente potrebbe non essere immediatamente consapevole del fatto che la chiusura del browser non cancellerà le sue impostazioni di autenticazione. Potrebbe tornare sul sito web presumendo di essere anonimo, mentre in realtà è ancora loggato al servizio. Il metodo comunemente visto di utilizzare una casella di controllo e una semplice nota informativa come “ricordami (utilizza cookie)” accanto al modulo di invio sarebbe un mezzo appropriato per ottenere il consenso, negando così la necessità di applicare un’esenzione in questo caso.

Il CRITERIO B è:

il cookie è “strettamente necessario affinché il fornitore di un servizio della società dell’informazione esplicitamente richiesto dall’abbonato o dall’utente fornisca il servizio”.

Quindi l’utente deve fornire il consenso prima che i cookie di autenticazione persistenti possano essere impostati. Motivo: non ci si può aspettare che un utente conosca le implicazioni dell’autenticazione persistente per impostazione predefinita.

Sì, la legislazione è diffusa e complessa, con molti aggiornamenti diversi nel corso di quasi due decenni. E anche i siti ufficiali dell’UE che ho consultato sembrano molto disordinati per quanto riguarda la gestione dei cookie e le loro politiche dichiarate.

3 Mi Piace