Regolamento UE 2016/679 (privacy)

16/04/2018 16:29:46

Molto utile quartz complimenti! Quando pronto lo postiamo come articolo che magari è utile a tanti! 😎

quota

16/04/2018 18:41:54

Davvero utile e chiarissimo! Grazie!🧙

---

quota

16/04/2018 23:10:09 e modificato da ghennadi72 il 17/04/2018 08:41:41

Io questo discorso lo prenderei molto con le pinze, quanto a ricadute pratiche.

Nella peggiore delle ipotesi per portali come GdR online si tratterebbe di aggiungere una specifica che in caso di dichiarazione del personaggio utilizzato sulla land XYZ il portale è autorizzato a riportare il nome, o che per forum come il tuo se vuoi citare esplicitamente il mio nick dovresti chiedermi il permesso o convertirlo in qualcosa di meno esplicito come Ghenny 'a carogna.

Conoscendo le tendenze del Garante credo che ci saranno ulteriori specifiche su cosa è effettivamente da intendersi come "identificativo online", perchè a prescindere dall'immagine di moloch burocratico che l'autorità dà spesso di sè, a fronte di richieste specifiche i chiarimenti spesso tengono conto, a differenza di quanto accadeva in passato, delle ricadute pratiche.

Una interpretazione estensiva rischierebbe di paralizzare un diritto riconosciuto altrove, che è il diritto/dovere di citazione, che implica l'identificativo dell'autore, che a volte è un nome e cognome effettivo, altre volte (anzi spesso, in contesto di rete) solo un nickname.
La necessità di consenso della citazione del nome di un autore paralizzerebbe di conseguenza la possibilità (e il dovere nel caso di citazioni obbligatorie) di citare. Wikipedia temo collasserebbe in 5 nanosecondi e dovrebbe oscurare tutte le fonti in attesa di ricezione del consenso degli interessati tranne nel caso di informazioni "di pubblico dominio".

Oltre a rendere pressochè inefficaci tutte le licenze Creative Commons, che tranne la CC-Zero (public domain) prevedono espressamente la citazione dell'autore.

Ho quindi il vaghissimo sospetto che Gianluca non sarà costretto a chiedere quindi alcuna autorizzazione preventiva a chi dichiara i personaggi che ha usato, e che chi cita altri nick/account/identità online a loro insaputa possa stare tranquillo e continuare a farlo come ha sempre allegramente fatto strabattendosene del consenso o anche solo dell'informare i nominati in confessionale.

Ma in ogni caso vista la posizione del portale, che usa questi dati in modo "innocuo" un eccesso di prudenza non guasta, nè vedo possibilità che possa trovarsi danneggiato da un "rifiuto" dell'utente di dichiarare il dato, anche perchè è già ora un dato fornito spontaneamente e facoltativamente. Magari potrebbe essere più problematico per chi cita nickname e "identificativi online" regolarmente senza il consenso e all'insaputa dei diretti interessati, sempre che davvero venga adottata una interpretazione "estensiva" di cosa sia un identificativo online. Ma come ho detto dubito che il Garante possa adottare una linea che paralizzerebbe qualunque testata, forum e blog online, o la stessa Wikipedia.


Nulla di diverso da quanto già specificato in apertura del thread.


Sono specificate le condizioni alle quali i dati personali possono continuare ad essere trattati, come peraltro hai evidenziato anche in seguito.

Inoltre attenzione a non fare confusione fra trattamento e conservazione, che sono due cose ben distinte. Attenzione qui anche a specificare le politiche di conservazione e di sicurezza dei "backup", offline od online che siano.

Scusa se salto la parte successiva, ma oltre a non aggiungere nulla di nuovo a quanto già discusso, su questa materia c'è effettivamente ben poca differenza con la normativa precedente.

L'unica effettiva differenza sono la specifica dei tempi di risposta entro i quali il titolare del trattamento dei dati deve rispondere al richiedente (che sono più estesi rispetto alle disposizioni del vecchio D Lgs 196/2003) e una specificazione di cosa è effettivamente il diritto all'oblio, che non va confuso con il diritto alla rettifica/modifica dei propri dati personali.

Differenza non sostanziale ma solo tecnica e di definizione: Non usiamo più l'espressione "dati sensibili" perchè il regolamento li considera comunque tutti dati personali, limitandosi a dividerli in due tipologie: quelli utili alla identificazione (i D.P. della vecchia normativa italica) e quelli che riguardano la storia, lo status medico, le informazioni familiari, gli orientamenti e le opinioni del soggetto (i vecchi "dati sensibili").

Il diritto all'oblio non ha assolutamente nulla a che fare con la cancellazione dell'account (vedi sotto).


Esattamente come con la vecchia normativa. Perlomeno ai fini delle ricadute pratiche per un gestore o admin di db in cui vengono salvati dati personali degli utenti di un servizio online.


Ma neanche per idea! 😳

La richiesta di cancellazione, per i motivi già elencati, può essere efficacemente sostituita dall'anonimizzazione e, in certi casi, dalla limitazione del trattamento, senza alcuna cancellazione dell'account in quanto tale.

L'importante è che l'utente sia informato con trasparenza di questa differenza, pienamente efficace ai fini della "perdita di dati", ma al tempo stesso pienamente efficace nel tutelare il legittimo interesse del servizio e/o del titolare del trattamento dei dati.

Puoi "anonimizzarlo" in diversi modi, inclusa una modifica anche solo parziale dell'identificativo (es "quartz" diventa "era_quartz" o "quartz_was_here" e quell'indentificativo online non è più il tuo), inclusa la possibilità di hashing dell'indirizzo email (possibilità che qualcuno saggiamente già usava anche prima del regolamento UE in questi casi), ossia la sostanziale perdita del dato identificativo di per sè, che quindi sopperisce tranquillamente alla richiesta di cancellazione senza inibire le necessarie funzionalità di moderazione e controllo sugli account bannati.


Infatti non è così. L'identificabilità e reperibilità del titolare del trattamento dei dati (e dei responsabili delegati, dove previsti) è proprio uno dei capisaldi del regolamento UE.
Deve essere fornito almeno un nominativo ed un indirizzo email valido. L'obbligo di indicazione dei dati anagrafici e di un contatto "fisico" (nome e cognome, indirizzo fisico di reperibilità, ecc) invece resta solo per le PA e le grandi aziende.



Attenzione, questo è estremamente pericoloso, Quartz. Puoi scaricarti della sicurezza dei dati per quanto di competenza del servizio a cui ti appoggi, ma non puoi assolutamente scaricarti della sicurezza che devi garantire ai dati di cui fai uso tu direttamente con le applicazioni che gestisci.

Se crei od usi una applicazione web vulnerabile e per effetto di quella vulnerabilità si verifica una violazione di sicurezza dei dati, sai cosa ti risponde l'hosting se provi a scaricare su di loro la responsabilità della violazione di sicurezza? "Puppa!"

Non è l'hosting a proteggerti ma il fatto di non essere una PA nè una grande impresa, per le quali l'adozione di specifici protocolli di sicurezza (codice di condotta), con relative certificazioni, è obbligatoria.

Puoi anche avere non stare in regime di hosting, avere il server fisicamente in cantina e avere una connessione diretta alla backbone italiana, ma se su quel server ci tieni solo il tuo blog o un'installazione di gdrcd su cui giocate in 5 perchè hai soldi da buttare, non hai comunque alcun obbligo di certificazione dei protocolli.

Viceversa devi comunque specificare a chi ti presta i suoi dati personali quali procedure adotti (non a caso il regolamento è intitolato anche alla sicurezza dei dati) per tutelare la sicurezza dei dati che raccogli e che vengono elaborati dalle applicazioni che usi, e come intendi regolarti in caso di violazioni della sicurezza dei dati (c'è una procedura da seguire, che comprende l'allertare obbligatoriamente l'autorità garante entro termini temporali ben precisi - 72 ore - e poco "trattabili" anche in caso di giustificato ritardo).

Tradotto, se ti sei installato una vecchia versione di GDRCD 3.0 e qualcuno ti si acchiappa tutto il database utenti, puoi stare in hosting, in VPS, in housing o avere il server in cantina, puoi essere un privato cittadino, il gestore di "Liguria Coast to Coast GDR", l'admin del sito dell'INPS o la Bocciofila Amatoriale di Poggibonsi, ma gli obblighi di dichiarare in che modo ti comporti di fronte al furto o a qualunque compromissione della sicurezza dei dati ce li hai eccome.

Quindi anche qui stiamo attenti a non consigliare ai gestori di prendere alla leggera le dichiarazioni che sono tenuti a fare sulle loro policy di sicurezza, anche se non sono tenuti ad adottare protocolli certificati.


--- EDIT
Ok, ho controllato. Lascia perdere la questione della differenza tra diritto all'oblio e diritto di rettifica/cancellazione su quello mi sono confuso io ;-)

cancellazione e oblio sono trattati dallo stesso articolo (17). L'articolo a cui facevo riferimento in merito alle risposte in caso di richiesta di cancellazione (oltre a quelle già elencate come motivazioni legittime di rifiuto della cancellazione per tutela del legittimno interesse legale del titolare) è il 18, che parla della Limitazione del trattamento, che offre ulteriori possibilità su cui dirottare l'eventuale richiesta di cancellazione tout cour (che comunque, ricordiamo, non riguarda l'account di per sè, ma i soli dati personali, tipicamente l'indirizzo email e lo username scelto).

Oltre a restare comunque in efficacia le soluzioni tecniche basate sulla perdita di identificabilità dell'account, tramite hashing o anche semplice editing dello username, e hashing dell'indirizzo email.

---

quota

16/04/2018 23:53:38

E' una questione delicata, che ad esempio noi stiamo affrontando avendo un gioco accessibile ai minori, dai 16 anni in su.

Chi specifica che il gioco è 18+ ha meno grattacapi. Considera che nel momento in cui fai il passo di richiedere un documento di identità, pevi anche specificare in che modo lo tratterai/conserverai e per quali finalità.

Aldilà delle eventuali implicazioni etiche del "lavarsene le mani" accettando per buona la dichiarazione d'età dell'utente, da un punto di vista di efficacia io eviterei di chiedere documenti agli utenti, ma questa è una scelta personale.

Il problema se mai ce l'ha chi autorizza l'accesso al gioco ai minorenni. Perchè ci sono due soglie: sotto i 14 anni la legge italiana (13 negli USA e ad esempio Facciabuco e altri social si adattano alla limitazione statunitense anche quando raccolgono dati di cittadini UE) non riconosce l'autonomia decisionale necessaria a sottoscrivere alcun tipo di accordo, inclusa l'espressione del consenso al trattamento dei dati.

Il problema sono le due fasce intermedie:
14,15 anni: è richiesto che il consenso sia fornito dai genitori a prescindere dalla natura del servizio (gratuito, freeemium, a pagamento)

16,17 anni: è richiesto che il consenso sia espresso dai genitori solo per servizi di natura commerciale (sarebbe interessante approfondire la questione per chi usa formule freemium, in cui il gioco di per sè è gratuito, ma dà la possibilità di acquistare questo o quel "pack" che conferisce dei bonus dietro pagamento di denaro).

---

quota

17/04/2018 00:50:22

@Ghennadi

Mi riprometto di rispondere meglio alle tue osservazioni negative in un altro momento. Per ora ti dico telegraficamente che:

- Ho colto l’ironia dove c’era, ma non possiamo fare riferimenti incrociati a cose che conosciamo bene solo io e te

- Una delle cause legittime del trattamento è l’espressione del pensiero e dell’informazione, quindi non c’è pericolo sulla paralisi di Wikipedia (o sulle altre pratiche da te citate)

- ... e in ogni caso la tutela del nickname ricordo vagamente che fosse citata in un “considerando” che andrò a ripescare appena possibile.

- L’art 17 che parla di rettifica e cancellazione è rubricato come “diritto all’oblio”. Non è il massimo della chiarezza, ma è una definizione e ci dobbiamo attenere

- L’anonimizzazione mi interessa molto, perché penso sia un buon sistema per ovviare al problema della cancellazione. L’unico problema è che devi assicurarti che il dato sia inaccessibile sempre e a tutti e non so se sia possibile (nel senso che proprio non lo so). Inoltre, a quel punto bisognerebbe spiegare come funziona l’algoritmo quindi mi interessa capire come eventualmente mettere giù la cosa.

- Il discorso sull’hosting va rivisto, si. Probabilmente è anche il caso di parlare della responsabilità nella programmazione (e magari anche rendere indisponibili al download versioni del GDRCD che sono notoriamente poco sicure). L’ultima parte va sicuramente rivista che manca qualcosa.

- Sulle 72 ore, il termine è indicativo e commisurato al tipo di attività. Su questo sono molto ottimista: l’impianto del regolamento è incentrato su quanto adeguato al tipo di attività ed al rischio. In più il Garante morirebbe sepolto di segnalazioni se spingesse sul “tutti segnalateci tutto”.

Ho scritto subito per far continuare il discorso anche argomentando a sprazzi: così da mollare le strade senza uscita e pensare alle situazioni più delicate

---

quota

17/04/2018 01:53:12 e modificato da ghennadi72 il 17/04/2018 02:01:38

Stavo giusto editando la parte relativa all'oblio: su quello ho fatto casino io (leggi intergrazione) :-D

Per quanto riguarda le procedure di sicurezza, non è che si tratti di un ostacolo insormontabile. Noi ce la siamo cavata con poche righe, anche perchè l'informativa non può ovviamente trasformarsi in un trattato tecnico.

L'importante é che il gestore (e più in generale chi raccoglie dati, fosse anche con il proprio blog wordpress) sappia che non può scaricare tutto sull'hosting, anzi in genere può scaricare una minima parte: un conto è se qualcuno viola effettivamente la sicurezza del servizio hosting e, che so, si scarica tutti i database contenuti, oppure entra nottetempo nella server farm e si porta via fisicamente i gli hard disk e tutti i dati contenuti all'interno.

Diverso è se viene violata la sicurezza di una specifica applicazione da te istallata/creata/usata, si tratti di una vecchia versione di gdrcd o di una estensione per wordpress che hai scaricato e installato sul tuo blog. Lì non puoi chiamare in causa le misure di sicurezza dell'hosting.

La questione dell'avvisare o no il garante è "relativa", anche alla portata della violazione. Il punto però è che in qualche parte dell'informativa la devi specificare, cosa fai (o dovresti fare) nel momento in cui ti accorgi di una violazione della sicurezza dei dati, ossia avvisare il garante e i diretti interessati.

Sull'anonimizzazione in realtà la cosa è piuttosto semplice: critti, o meglio fai l'hashing dell'indirizzo email, esattamente come nel caso della password. La stringa che ne risulta è irriversibilmente "crittata" e di conseguenza tu non sei più in possesso dell'email del soggetto.
Al tempo stesso se quel soggetto tenta di riutilizzare la stessa email per registrarsi di nuovo, il sistema di iscrizione effettua al volo la stessa operazione sull'email appena fornita e la confronta con quelle salvate; se trova una stringa identica, impedisce la registrazione con quella stessa email, senza neanche bisogno che la mail venga nuovamente inserita nel database. E tutti sono contenti, incluso il "ritornante" che 5 minuti dopo tornerà con un indirizzo email diverso.

Più sensibile è la questione della limitazione del trattamento. Uno dei "consideranda" stessi menziona la possibilità di trasferire e conservare il dato personale su altro supporto, differente da quello oggetto di normale trattamento. Aldilà di questo i nostri tanto amati backup di sicurezza raramente vengono presi in considerazione nelle informative.

ps: l'altro argomento che manca è la responsabilizzazione dell'interessato che il regolamento chiede venga coinvolto come parte attiva nella protezione e sicurezza dei propri dati. Aspetto che si può facilmente affrontare dando al registrante qualche utile consiglio su pratiche da evitare quando si registra a un qualunque servizio online e sulle informazioni personali che a volte sono gli utenti stessi a fornire un po' troppo allegramente anche se non richiesti, salvo poi gridare al "diritto all'oblio" quando un'informazione che si voleva riservata e personale è ormai diventata di pubblico dominio o quasi. Però è interessante che il regolamento lo abbia evidenziato, perchè pone in luce anche le responsabilità dellutente interessato, nel processo di tutela della propria privacy.
Perchè diciamocelo pure, spesso i primi a fare danni e a causare violazioni della propria privacy sono gli utenti stessi.

---

quota

17/04/2018 09:36:35

Su alcuni punti c'è sicuramente da fare maggiore chiarezza o limare. L'intervento di Ghennadi è sicuramente interessante al fine di arriva ad un quadra della faccenda :-)

da quanto ho letto in giro si attendono con ansia una serie di chiarimenti da parte del Garante su alcune questioni un pò fumose sull'applicazione pratica

quota

17/04/2018 11:27:20

Ok, letto. La materia è complicata, quindi è normale che ci sia qualche aggiustatina in corsa. ;-)
Se sei d'accordo, io terrei la generalizzazione che ho fatto in proposito, perché altrimenti dover ri-specificare il tutto rischia di appesantire il testo ed ai fini dell'utente medio di GDR potrebbe bastare



No, in effetti questo è un problema potenzialmente pericoloso, anche perché il gestore medio di solito non capisce di programmazione.
Questo sarebbe un ambito nel quale ce la si potrebbe cavare con un disclaimer sulla bassa sicurezza media dei dati, perché prodotto amatoriale. Sarebbe nello spirito del Regolamento, ma resta un po' rischioso soprattutto perché...



Su questo sicuramente. E sull'avvisare il garante secondo me se ne può fare a meno, quantomeno per questioni piccole come le nostre. A tutt'oggi, quando manca un mese all'entrata in vigore del Regolamento, il sito del Garante prevede la comunicazione del Data Breach solo per imprese di servizi di telecomunicazione e di chi gestisce dati sensibili http://194.242.234.211/documents/10160/0/Violazioni+di+dati+personali+-+Gli+adempimenti+previsti+(infografica).pdf ↗
Se oggi volessi fare una segnalazione al Garante, quindi, neppure saprei come fare.
L'avvisare i diretti interessati, invece, è una cosa che andrebbe di regola fatta.



Perfetto. Trovo il modo di inserire questo dettaglio tecnico in modo coerente. Certo, però, poi bisognerebbe dare la possibilità alla gestione di cancellare la voce o di "rimuovere il ban" (per capirci), perché sarebbe una decisione presa da un algoritmo, che secondo il nuovo Regolamento il titolare dei dati ha la possibilità di contestare.



:-D





Quasi sempre vero. Una delle ragioni per la quale è necessario il GDPR è che stiamo regalando pezzi sempre maggiori della nostra vita ad organismi privi di controllo, con un entusiasmo spaventoso.
Però dal punto di vista del "che deve fare il gestore per pararsi il c..." non mi sembrava indispensabile.
Siccome mi sembra una cosa più sulle tue corde, se hai voglia, tempo e volontà, potresti scriverla tu. Non so, magari fare una Seconda Puntata o qualcosa del genere



Assolutamente si, c'è un grosso pezzo di expertise tecnica che a me manca completamente.



Su questo ho più di qualche dubbio: intanto perché ci sarà un Garante Europeo con compiti di coordinamento e controllo, e quindi prima di avere una risposta certa ci sarà bisogno anche della "benedizione dall'alto"; inoltre, il vecchio testo unico privacy avrebbe bisogno di essere coordinato e rimesso a nuovo rispetto al regolamento anche solo per far funzionare il Garante e questo richiederebbe un governo nella pienezza dei poteri. Senza buttarla in politica, che non è questo il luogo, non sembra un'ipotesi imminente. In più, ad occhio, il Garante si occuperà prima dei problemi più spinosi.
In sintesi: se aspettiamo i chiarimenti del Garante rischiamo di aspettare tre anni.



Non mi ero dimenticato!

La distinzione tra disattivazione e cancellazione è una cosa che, per come ho capito io, serve soprattutto a tutelare i colossi. Per dire, siccome Facebook rivendica la proprietà delle mie foto delle vacanze, se cancellassi l'account potrebbe venire meno il rapporto contrattuale che consente a Facebook di rivendicare la proprietà delle foto delle mie vacanze. Quindi loro disattivano l'account per questo.
Insomma, a pelle ho impressione che disattivazione / cancellazione sia una differenza che ha ragioni commerciali più che tecniche e che quindi ne potremmo fare a meno.

---

quota

17/04/2018 13:54:00 e modificato da dyrr il 07/05/2018 00:22:27

Per l'anonimizzazione dei dati è possibile se usi una Funzione crittografica di hash che è unidirezionale.

Il che significa che puoi fare questo percorso:

stringa di partenza -> finzione di hash = hash univoco

ma non puoi fare il processo inverso se non attraverso il tentare il processo sopra indicato secondo schemi precisi ripetute volte fino a quando non ottieni lo stesso hash e allora sai che la stringa è quella giusta.

Riprendo un intervento che ho gia fatto credo non mi ricordo se qui o in un altro topic:

Prendiamo il caso tipico di un gdr, dove l'unico dato salvato che può interessare è la mail:

Il tipo di dato che rappresenta una mail può variare in base alla mail:

il_truzzo_ssjbb@gmail.com non è un dato identificativo di alcun tipo

mario.rossi@gmail.com dato personale

mario.rossi@cgil.it dato sensibile

ma salvare la mail in hash tramite SHA512 come:

AEA35AC51FEDDE8B2ED87CFC9E05B6A63D547391C06CE1E 0F45F98595621E661194157B4F441B98ACC9911ABDDE54D63C68D095E9E5A49F83BFD7BF78209A7CF

trasforma il dato in un dato anonimo.


Basterebbe indicare nel disclaimer sulla privacy quando determinati dati forniti dall'utente vengono conservati in dato anonimo, un po' come quando si specifica che la password fornita dall'utente viene salvata crittografata e che quindi nessuno ne è a conoscenza direttamente.

L'angolo del tecnicismo XD:

Domanda: Ma se la mail viene salvata in quel modo come fa a poter essere utilizzata per il recupero pass o per impedire che un utente bannato si reiscriva con la stessa mail?.

Risposta: Nelle procedure di recupero pass all'utente viene chiesto di inserire la mail di iscrizione del pg e il nome del pg, la mail fornita viene anche essa crittografata e i due hash confrontati, se sono uguali, vuol dire che la mail è quella giusta e viene usata quella indicata al momento del recupero pass per inviare la nuova pass. per controllare che una mail non venga usata per reiscriversi viene sempre usato il confronto tra gli hash.

quota

17/04/2018 19:48:09 e modificato da ghennadi72 il 17/04/2018 19:50:30

Mi viene in mente che, a livello puramente di privacy, se crittassi da subito l'indirizzo email, non avrei alcun problema di "dato personale" conservato e trattato.

Recupero password o anche recupero dello username per chi se lo scorda possono essere appunto fatti al volo, senza necessità di salvare l'indirizzo email nel database, dal momento che l'indirizzo email viene passati "in chiaro" solo alla pagina che lato server la hasha, la confronta con una stringa già hashata e in caso di corrispondenza, invia una mail all'indirizzo passato, senza alcuna necessità di salvarlo in chiaro da nessuna parte.

Naturalmente a prezzo della rinuncia della possibilità di contattare autonomamente l'utente attraverso l'indirizzo di posta elettronica fornito, che a quel punto per me gestore/dbadmin sarebbe del tutto inutilizzabile.

Per chi è sicuro che non avrà mai alcun bisogno, neanche ipotizzabile come remota possibilità, di dover contattare autonomamente i giocatori potrebbe essere una soluzione di cui tenere conto.

---

quota

Tim Burton

Tesi di Laurea dal titolo "La morte malinconica di Tim Burton"

Creare Linguaggi

Come creare linguaggi per live e giochi di ruolo online...Tà ghén Mordor!

Kick

I segreti del successo: come rendere popolare il tuo canale gaming su Kick

Puerto Dorado

Intervista ai gestori del gdr storico Puerto Dorado