Cancellazioni periodiche degli account

Cancellazioni periodiche degli account postato il 25/10/2013 02:57:40 nel forum leggi e legalità

Ho notato leggendo alcune comunicazioni "ultime dai giochi" che è pratica diffusa quella di effettuare periodicamente, in giorni specifici, le cancellazioni dei personaggi inattivi.

E' bene ricordare che tra i dispositivi di rispetto delle norme sul trattamento dei dati, c'è la specificazione chiara del tempo massimo di conservazione dei dati personali (tipicamente: email).

Questa pratica, di cancellare le utenze inutilizzate solo in date specifiche, può essere problematica perchè crea dei "buchi", tra una cancellazione e l'altra, durante i quali gli account inutilizzati restano nel database aldilà della scadenza dichiarata nell'informativa sul trattamento dei dati personali.

Ipotesi classica: nell'informativa viene dichiarato che i dati vengono comunque cancellati a 60 giorni dall'ultimo accesso.

Supponendo che la land abbia un tot di iscrizioni ogni giorno, questo significa che se l'abitudine é, ad esempio, di cancellare l'ultimo giorno del mese le utenze inutilizzate per più di 60 giorni, il rischio é che fino a quella data rimangano "illegalmente" nel database non solo le utenze inutilizzate oltre il termine di 60 giorni, ma anche tutte quelle registrate nei giorni successivi all'ultima cancellazione.

Situazione limite: account con dati personali che anzichè restare registrati massimo 60 giorni restano registrati 60 + 29/30 giorni, ossia sforando di un mese rispetto ai termini dichiarati nell'informativa sul trattamento dei dati personali.

L'ideale sarebbe la cancellazione quotidiana in modo da essere certi che i dati personali vengano effettivamente cancellati nei termini che vengono dichiarati all'utente.

Operazione che non va fatta necessariamente in modo manuale. Chi ha a disposizione i cronjobs/crontabs (da contratto col proprio hosting o perchè gestisce un VPS o un server semidedicato/dedicato e quindi può fare quelo che gli pare) ossia operazioni pianificate che possono essere lanciate automaticamente a scadenze prefissate o al verificarsi di certe condizioni, farebbe bene a sfruttarli per automatizzare ed eseguire quotidianamente queste operazioni di manutenzione.

In sostanza si crea una semplice pagina contenente una routine (in php/asp a seconda di quel che si usa) che seleziona gli account da cancellare per inattività e li cancella automaticamente. Ogni giorno e senza necessità di intervenire manualmente (ci si può dimenticare, una sera si può non aver voglia perchè si ha il mal di testa, ecc).

Il problema è che non tutti i servizi hosting offrono questa funzionalità. Ad esempio aruba, uno dei servizi hosting più usati, non la offre. E nemmeno altervista, mi risulta.

In questo caso posso suggerire un servizio gratuito al quale ci si può appoggiare per richiamare quotidianamente un cronjob. In pratica ci si registra, si inserisce il link della pagina contenente lo script da eseguire per le operazioni di manutenzione del database, e l'intervallo di tempo entro il quale deve girare (tipicamente: ogni 24 ore all'ora HH:mm). La menata è che essendo un servizio gratuito funziona a punti: te ne danno 30 e ad ogni esecuzione viene consumato un credito. Poi devi rinnovare, sempre gratuitamente, la sottoscrizione.

E' un'operaizone fastidiosa da farsi una volta al mese, ma se non si hanno soluzioni alternative (es. un'operazione pianificata dal proprio PC che richiama tramite browser lo script di manutenzione ogni giorno alla tal ora), é comunque un servizio sfruttabile per questo tipo di operazioni. Ovviamente la versione a pagamento (i prezzi sono modici, ma a quel punto uno potrebbe valutare il passaggio ad un hosting che ti fornisce i cronjobs da contratto) ha meno limitazioni.

Il servizio gratuito lo potete trovare qui:
http://www.setcronjob.com http://www.setcronjob.com

Se altri sono a conoscenza di altri servizi simili, sarebbe carino condividerli. :-)

---

quota

25/10/2013 08:03:29 e modificato da dreamofyougdr il 25/10/2013 08:03:58

Questo è uno dei tanti problemi di cui molti gestori non si curano, anche perchè magari sanno benissimo che i loro utenti non si lamentano minimamente di questa irregolarità (che magari è anche riscontrabile leggendo le condizioni generali dello stesso gioco).

Noi ogni tanto ci troviamo utenti che, al contrario, si lamentano se il loro personaggio viene cancellato dopo 60 giorni di mancato login nonostante hanno 15 giorni successivi per poterlo recuperare ed hanno la possibilità di "congelare" il personaggio nel caso in cui non possano loggare per più di 2 mesi.

quota

25/10/2013 08:58:01

Possibilissimo. Noi abbiamo adottato questa soluzione per diverse operazioni di manutenzione periodica, diverse dalle cancellazioni degli utenti (che sono piuttosto pesanti, coinvolgendo più tabelle, operazioni di backup, e altro), finchè siamo stati su aruba e non vendo quindi a disposizione i cronjobs.

Una volta passati su un host che li mette a disposizione abbiamo passato tutte queste attività su cronjobs scaricando il motore di gioco (e quindi gli utenti) da questo tipo di operazioni.

---

quota

25/10/2013 14:00:46

Ma il motivo che vi spinge a prevedere la cancellazione degli account inattivi qual'è? Liberare quei 2-3 nick usati? Questa pratica la vedo diffusa solo nei pbc, introdotta dal "colosso" e poi adottata da praticamente tutti

quota

25/10/2013 15:29:38

E' vero che lo script può essere reso molto leggero, al punto di poterlo utilizzare senza problemi anche nel modo in cui hai proposto, Verdux.

Questo però è resta vero finché si parla di una piccola utenza, inoltre se il tuo cron è programmato per girare anche solo una volta all'ora, quasi sicuramente sarà più performante la sua operazione che non la stessa implementata nell'altro modo proposto (se logga meno di una sola utenza l'ora.. sarebbe un sito molto triste), così come se invece fosse giornaliero o a scadenze più lunghe.

In ogni caso il cronjob permette di avere anche una certa sicurezza sul fatto che in assenza totale di utenti, le operazioni in background sul tuo sito continuano a funzionare, e questo da solo è un buon motivo per utilizzarli, sempre c'è la possibilità di sfruttarli.


Quanto ai fatidici 60 giorni, io ammetto di non essere un esperto di legalese, ma che io sappia i dati (relativi a log, ip, indirizzi email) possono essere trattenuti per anche 2 anni.
Qualcuno sarebbe ingrado di confermare/smentire ?


ps: altervista li ha, bisogna spenderci altercents.

quota

25/10/2013 15:33:03 e modificato da leoblacksoul il 25/10/2013 15:35:11

Io invece vorrei andare a discutere un po' di più sul presunto obbligo di legge che genera tutte queste considerazioni tecniche.

Più di una volta mi sono imbattuto nella frase del codice sulla privacy riguardo i tempi di conservazione dei dati, ma fatico a capire come nell'ambiente di un gioco questo comporti un'obbligo di cancellazione di un account.

Il codice dice più o meno questo

Ma gli scopi per cui i dati sono raccolti in un gioco (perchè il mio punto è proprio legato alla natura del sistema) non mi pare che abbiano un limite di tempo. La finalità per cui raccolgo i dati è dare possibilità all'utente di usufruire del gioco (specie l'email, che mi serve per il recupero password, che viene usualmente usato proprio dopo che l'utente sta via per molto tempo); io gestore non sono in grado di dire con certezza quando i dati non mi servono più; l'unico ad avere questa informazione è l'utente stesso. Io tutt'al più posso fare delle stime approssimative, ma non sono mai in grado di dire con certezza che l'utente non vuole più usufruire del sistema; dunque la condizione posta dalla legge per far scattare la cancellazione dei dati non diviene mai vera, a meno che non sia l'utente stesso a comunicarmi che non vuole più usufruire del sistema.

Quindi...fatico a vedere questo "obbligo" di cancellazione e tutto il conseguente ragionamento sulle pratiche di cancellazione automatiche etc

---

quota

25/10/2013 15:49:44 e modificato da ilgrandeinverno il 25/10/2013 15:50:32

Liberare dei nick può essere una buona idea se sulla tua land non permetti nick "fantasiosi" (diciamo così) come Pisellina14, D@rKScreamer89, BlackDominatrix ecc. Alla lunga a seconda delle nomenclature consentite il parco dei nomi disponibili si riduce ed è inutile tenerne diversi bloccati da giocatori inattivi.

In questo caso però parliamo dei tempi di conservazione dei dati personali all'interno del database intestato (solitamente) al/ai proprietario/i della land.

---

quota

25/10/2013 21:00:28

Aimè, si, a volte si danno le cose per scontate.

Comunque, tornando sull'argomento, io continuo a non vedere il problema. I dati sono trattenuti finché viene erogato il servizio.

Ed il proprietario ne può richiedere la cancellazione.

Sono cavoli suoi se entra una volta ogni 3 mesi o ogni 6 mesi: se vuole cancellare i dati, come in qualsiasi sito web, richiede la cancellazione. Perché il proprietario del sito deve porsi il problema di cancellare dei dati, supponendo che il giocatore non è più interessato? Mi pare un obbligo piuttosto illogico, e quoto Verdux :)

quota

25/10/2013 23:06:28 e modificato da ghennadi72 il 25/10/2013 23:10:32

60 giorni
Ho detto 60 giorni perchè, un po' sulla scia della "tradizione" iniziata dal "colosso" di cui parlava Airon, un po' perchè é un limite abbastanza ragionevole per individuare un utente che ha smesso di giocare, é un limite che va molto di moda ma non é un obbligfo che siano 60 giorni. Possono essere 60, 30, 90 , 120 o 360 o 127.

Il punto é che quando fai prendere visione all'utente dell'informativa sui suoi dati personali devi dirgli:
- a) che uso ne farai
- b) per quanto tempo prevedi di trattenerli

Una volta dichiarato il limite all'utente, ti impegni a rispettarlo, che siano 30 o 90 o 120 giorni.

I motivi per cui chiedi all'utente i suoi dati (e la quantità e natura di dati) possono essere i più diversi, ma ce ne è uno che é fondamentale e sempre presente: il dato ti serve per poter erogare il servizio.

Un po' come al supermercato quando ti fanno firmare per la tessera punti: due crocette di consenso, quella sull'uso dei dati a fini promozionali interni e quella sulla trasmissione dei dati ad altre società commerciali non sei obbligato a metterle, ma la prima, quella che autorizza il supermercato a inserirti nel suo database, devi metterla per forza o il supermercato non può darti la tessera punti.

Se l'utente non accetta la "autorizzazione base" a usare i suoi dati per ricevere il servizio (in questo caso un gioco), non può usare il servizio (in pratica: non accetta di fornirti una email valida, non può ricevere i dati per il login, non li può recuperare in caso di smarrimento, non può essere contattato dal gestore in caso di problemi tecnici o di contestazioni sull'uso del servizio ecc.)

E dal momento che oltre alla richiesta volontaria di cancellazione dei dati c'è anche il caso dell'utente che smette di usare il servizio, quindi a quel punto a te gestore i suoi dati non servono più, devi anche dire quale è il tempo massimo oltre il quale cancellerai i suoi dati nel momento in cui l'utente smette di usare il servizio e quindi tacitamente rende inutili i dati che ti ha fornito.

60 giorni sono un limite come un altro, noi ad esempio abbiamo differenziato a seconda del tipo di dato da cancellare:
- missive e comunicazioni interne: 60 giorni
- stringhe inviate in chat: 30 giorni
- email: 90 giorni (cancellazione dell'account)

In realtà ci sono altri risvolti della questione, uno dei più rilevanti:

Ban dell'utente: quando banni un account a tempo indefinito, per rendere efficace in ban di solito devi conservare anche la sua mail in modo da impedire che venga riutilizzata per registrare altri account. Questo entra apparentemente in conflitto col limite di conservazione dei dati dopo la fine dell'uso del servizio, e dal momento che la questione sul "tempo massimo" è piuttosto aperta, una buona soluzione è dichiarara nell'informativa che in caso di ban i dati possono essere salvati in via indefinita, ma magari in forma crittata/hashata come si fa per le password: in questo modo la mail per te gestore diventa "illeggibile" ma hai comunque un sistema per confrontarlo con la mail dell'utente quando si registra e bloccare i tentativi di riutilizzo di una mail bannata.

@Leoblacksoul
Il fatto che i dati personali vengano concessi per la fruizione di un servizio ludico non fa differenza, Leo, perchè che sia un gioco, un forum di modellismo o un sito di scommesse sportive, resta il principio di base: c'è l'utente con i suoi dati personali e ci sei tu gestore/titolare di un database in cui dati personali che non sono tuoi vengono registrati. L'autorizzazione dell'utente è necessaria.

---

quota

26/10/2013 00:10:04 e modificato da ilgrandeinverno il 26/10/2013 00:12:49

In generale questo é uno dei motivi per cui una volta provato "hurrah" (ossia un host che mette a disposizione i cronjobs) non tornerei più su ***precedente_hosting*** manco con la pistola alla tempia.

Data la mole di automatismi e parametri del personaggio ad aggiornamento continuo che abbiamo, finchè non abbiamo avuto a disposizione i cronjobs ci siamo regolati esattamente come dice Verdux perchè a meno di non trovare un servizio gratuito che lancia i cronjob a scadenze più ravvicinate di 24 ore (o a meno di non tenerti un pc acceso in casa H24 che esegua i richiami degli script come operazioni pianificate, per la gioia della società elettrica) é l'unico modo di ovviare al problema: questo significa che ogni dannato utente :) collegato ad ogni refresh o ricaricamento manuale di determinate pagine innescava dei controlli (tot query al database) e in caso di necessità, eseguiva in modo "silente" anche le eventuali operazioni sul database.

I calcoli di convenienza tra evento innescato dall'utente e cronjob sono presto fatti:
- Solo per le query di controllo (5) con 20 utenti connessi e tempi medi di refresh di 3 minuti, significava: 20 utenti x 20 resfresh orari x 5 query di controllo = 2000 query / ora. Solo per quelle di controllo che sostanzialmente chiedono al database "devo eseguire queste operazioni?".
- Col cronjob: 5 query di controllo volendo anche ogni 5 minuti -> 60 query all'ora.

60 query col cronjob contro 2000 query con l'evento innescato dall'utente :-)
E oltre alle query al DB va considerato l'eventuale consumo di risorse (memoria e CPU) di 60 operazioni pianificate contro 2000.


Esattamente. Questo é l'altro enorme vantaggio dei cronjob. L'evento innescato dall'utente non è comunque da scartare in assoluto, ad esempio se riguarda operazioni che coinvolgono solo il suo account. Ma in termini generali se ci sono funzioni che prevedono effetti globali (es le query di recupero dell'energia fisica, piuttosto che della salute del pg, il calo di tasso alcolico nel sangue, ecc.) il confronto di efficacia tra cronjob e evento innescato dall'utente ha un solo possibile verdetto. E il cronjob garantisce che le operazioni siano eseguite anche se l'account incaricato (esempio di Verdux) quel giorno non si connette o se (es tipico sotto le feste o in estate inoltrata) accade che in una determinata giornata non si connette nessuno.


Se ricordi ne discutemmo proprio qualche tempo fa a proposito di cosa succede quando banni un utente e per rendere efficace il ban devi comunque conservare la sua mail ben oltre i termini normali che dichiari nell'informativa.

Credo che il punto chiave di principio sia la cessazione dell'utilizzo del servizio da parte dell'utente e, di conseguenza, che tu gestore non sei più giustificato a trattenere i miei dati. Casistiche possibili:
- richiesta volontaria di cancellazione: l'utente esprime di sua iniziativa la volontà di cancellazione dei suoi dati (NB: è suo diritto richiedere la cancellazione dei dati personali, es. email, data di nascita, nome e cognome, ecc, ma non ha alcun diritto a chiederti la rimozione dell'account di per sè una volta che hai tolto i dati personali) -> effetto immediato
- cessato utilizzo implicito (l'utente non si collega più): non c'è una dimostrazione esplicita di volontà di non usare più il servizio quindi qui è il gestore a dover dichiarare dopo quanto tempo considera la mancata connessione come una espressione di volontà di non giocare più. -> effetto nei termini dichiarati sull'informativa (i famosi 60/90/127/xxx giorni dall'ultimo login)
- ban dell'utente: argomento delicato, appunto. Risolvi eliminando la mail (e gli altri dati personali) salvati in chiaro e al limite ne trattieni una copia hashata in modo che sia illeggibile ed utilizzabile solo per prevenire ulteriori utilizzi per ri-registrarsi. Ovviamente anche di questo dovresti informare l'utente quando si registra, ossia che in caso di ban ti riservi di trattenere in forma crittata la sua email a tempo indeterminato.


Gemini mi pare disse che il termine massimo in caso di inutilizzo era 2 anni, ma su questo chiederei conferma a lui :-)



Questo é interessante, anche se ormai ho smesso di usarlo se non come appoggio per immagini e quant'altro. Il funzionamento del guadagno di altercents funziona sempre solo tramite partecipazione alle attività della community (scambio banne, click, ecc) o è cambiato qualcosa? :-)

---

quota

26/10/2013 01:21:21

Ho capito il tuo discorso, ma mettendola cosìì il tutto si riduce ad un gusto personale di gestione, e qui andiamo forse un po' fuori da ciò che volevo in realtà andare a parare.

Ovvero: c'è una legge che mi dice che non posso tenere i dati dell'utente iscritto nel mio database per inattività? (posto che abbia accettato tutti i termini del caso, consapevole che i suoi dati vengono utilizzati solo per il servizio erogato)

quota

Fabio Zanoli

Intervista al papà del primo GDR online a pagamento... GeArcani!

Riverstone

Intervista alla gestrice del play by chat storico ambientato negli anni 20: Riverstone!

Morsmordrecurse GDR

Intervista alle gestrici di Morsmordrecurse GDR.. il gioco di ruolo Potteriano!

Statistiche Tecniche 2020

Gdr-online.com pubblica i dati tecnici dei suoi visitatori per l'anno 2020. Spulcia i dati disponibili!