Ritorno al Futuro: dalle BBS a Mastodon. Ma intanto il mondo è cambiato.

Ritorno al Futuro: dalle BBS a Mastodon. 

Ma intanto il mondo è cambiato. 

Dopo un tedioso balletto, finalmente i giochi sono fatti, les jeux sont faits: su Twitter inizia l’era di Re Elon.

Per quanto mi riguarda accolgo volentieri ogni cambiamento e mi sentirei un folle sia a lamentarmi sia a gioire. Si cambia, il futuro è tutto da scoprire. L’unica cosa che non cambierà sarà riconsiderare criticamente le mie scelte, giorno per giorno, come ho sempre fatto.

In realtà, una cosa da fare ci sarebbe: un bel backup dei dati. Twitter permette infatti di ESPORTARE i dati dell’utente. La procedura è molto semplice, si trova nelle impostazioni dell’account e, con pochi click, in alcune ore viene consegnato un file compresso contenente tutti i tweet, i like, la lista degli account bloccati, quelli silenziati, le impostazioni ecc.

Perchè esportare i dei dati? Semplicemente perché si può! Poterlo fare è una conquista, non è magnanimità di Elon o di Jack, è per loro un obbligo e per noi un diritto. 

È bene ricordarlo a se stessi per non dimenticarsi mai di avere dei diritti, ed è bene anche ricordarlo al nuovo padrone di casa, solo per richiamare il delicato concetto che LUI è padrone dei muri ma NOI siamo padroni dell’arredamento.

Mi piace immaginare quanto potrebbe essere eloquente il messaggio tra le righe se l'esportazione dei dati venisse fatta negli stessi giorni e da un numero significativo di utenti.

Comunque sia, a prescindere dal backup dei dati, c’è stato un cambiamento importante e in tanti hanno deciso di abbandonare twitter o, quanto meno, di predisporre un piano B. Mastodon, anzi, il Fediverso, è il piano B che la maggior parte degli utenti twitter ha preso in considerazione.

Lascio ad altri spiegare di cosa si tratta nel dettaglio. Darò per scontati un po ' di concetti e di termini tecnici.

Come DPO e come inguaribile smanettone, ho subito pensato di prendere uno dei miei Raspberry inutilizzati e montare una bella Istanza del fediverso, un piccolo regno da me creato dove stabilire le regole, giudicare ciò che accade, intervenire a mio piacimento come un Dio digitale nel proprio microcosmo binario fatto di bit.

Hei… ma io questo l’ho già fatto!  

Eh si, è un deja-vu: sono passati tanti anni, allora ero solo un ragazzo, ma ho ancora addosso il segno indelebile della mia BBS. Ancora ricordo i rumorino dell'hardware dai quali capivo cosa stesse succedendo anche senza guardare lo schermo. La BBS come scuola di vita. La BBS come microcosmo all’interno del quale io ero Dio.

Gli anni come Sysop (oggi diremmo Amministratore o Admin) mi hanno insegnato tanto, sia nel bene che nel male. Le competenze tecniche ne hanno certamente beneficiato ma gli insegnamenti maggiori appartengono a tutt’altro ambito e sono più vicini alla sociologia, alla psicologia e ho esplorato aspetti di me che non conoscevo: il lato oscuro di Christian.

Si dice che l’occasione faccia l’uomo ladro. Beh, probabilmente si può resistere al furto dell’auto lasciata aperta nel cortile del condominio… ma si può resistere anche all’occasione di essere Dio in un microcosmo? No, a questo nessuno può resistere.

Nei panni di un Sysop, ho scoperto quanto fosse potente uno sguardo dall’alto, capace di accedere a tutto, scoprire ogni segreto, cogliere ogni dettaglio, vedere l’invisibile e, soprattutto, vedere senza essere visto. 

Entusiasmante e terribile. 

Ogni Sysop, ogni Admin, si confronta con tentazioni troppo forti da vincere, con sentimenti non facili da gestire e, sicuramente, con il lato oscuro del proprio Io.

Per fortuna non ci sono più molti Sysop in circolazione, forse anche a causa di un fattore anagrafico, e gli Admin possono tutto, si, ma su sistemi informatici seri, ben configurati e rispettosi del GDPR, non possono fare poi molto. Di sicuro la curiosità e il potere divino vengono fortemente compressi rispetto a ciò che accade in una BBS.

Ma siamo all’alba di una nuova stagione: la stagione del ritorno dei Sysop.

Oggi, a causa della massiccia diffusione del Piano B, in tanti si stanno attrezzando per diventare i gestori dell'istanza, più o meno grande, più o meno strutturata, più o meno pubblica.

Mi sono paralizzato alla sola idea che questo percorso interiore, di fatto compiuto sacrificando la riservatezza degli utenti della mia bbs, possa essere replicato 10, 100, 1000 volte al giorno e diffondersi a macchia d’olio tra tutti quelli che smanettano con i raspberry o con i computer in generale. Oggi siamo in tanti, non è più una élite… o meglio, una piccola banda di disadattati.

Dopo la mia esperienza come sysop, dopo gli anni trascorsi a sfogliare i libri di Giurisprudenza, dopo i tanti anni come consulente privacy e, in ultimo, gli anni da DPO, non posso fare a meno di pormi una domanda:  ma questi ragazzi che mettono su istanze a cuor leggero lo sanno che cosa stanno facendo e quali rischi corrono?

E tutti quelli che utilizzeranno le istanze home-made del fediverso, di Mastodon, ecc., lo sanno che cosa stanno facendo e quali rischi corrono?

Andiamo con ordine.

Piccola premessa tecnica. 

Allo stato attuale, il protocollo alla base del fediverso, alla base di Mastodon e alla base di ogni singola istanza, non prevede alcuna cifratura. I messaggi viaggiano in chiaro, i messaggi diretti viaggiano in chiaro, gli allegati sono in chiaro e, in breve, tutti i dati che transitano sull’istanza sono completamente visibili ad ogni amministratore. 

Dire tutti i dati significa dire “tutti i dati personali” e questo non esclude affatto che tali dati abbiano natura sensibile. Informazioni, documenti, foto, foto private, confidenze, simpatie, amori… in un mondo in cui le persone pubblicano allegramente qualsiasi cosa, c’è da aspettarsi un bassissimo livello di selezione delle informazioni personali trasmesse.

Anzi, io mi aspetto un livello ancora più basso di selezione e una maggiore confidenza con l’uso del fediverso perché non c’è Mark o Elon che ci spiano. Si genera una sorta di fiducia, l'aspettativa di qualcosa di meglio e anche un certo affidamento su cui bisogna ragionare meglio. Ma è veramente così? 

Ovviamente no, oltre ai big della tecnologia, a cui non è pensabile di sottrarre l’accesso ai dati che circolano nel fediverso, si aggiungono al numero delle potenziali spie tutti gli amministratori delle singole istanze sulle quali i dati circolano. Quanti sono? Beh, magari è uno, se penso alla mini istanza su raspberry, ma potrebbero anche essere decine e decine per le istanze più grandi. Essere grandi, in questo caso, non significa essere strutturati o migliori né comporta maggiori competenze. Significa solo che saranno più numerose le persone con privilegi di amministratore in grado di sbirciare i contenuti, purtroppo. 

Molto male, direi… questa è una informazione importante della quale ogni utente deve essere ben consapevole e per la quale occorrono remind continui.

Un po come il beeper che ricorda di allacciare le cinture in macchina, così ogni client o ogni istanza dovrebbe ricordare ad ogni utente, in continuazione, che i messaggi non sono cifrati, li possono leggere in tanti e, quindi, è meglio controllarsi un pochino nell’uso.

La falsa sicurezza fa molti più danni dell'insicurezza palese.

Un pensiero dedicato a chi crea un’istanza.

Tecnicamente, “mettere su” un’istanza non è né difficile né costoso. Chiunque lo può fare e, anzi, facendolo si impara certamente qualcosa. Lo ritengo addirittura consigliabile.

Se tutto finisce lì, con la mera installazione, non ci sono particolari problemi: si tratta di un serverino configurato, pronto a fare un certo lavoro, pronto anche ad essere spento, formattato e riutilizzato per il prossimo esperimento nerd. Se gli va male, il serverino può essere cannibalizzato, ma per i nerd questo non è necessariamente un male.

Diverso è il caso di un serverino pronto, configurato e operativo, in uso. In questo caso cambia tutto.

Un pensiero dedicato a chi crea un’istanza con un solo utente.

I microserver con un solo utente saranno presto migliaia. È bellissimo poter avere il proprio server. Oltre al divertimento di farlo, ci sarà anche un concreto vantaggio per l’intero ecosistema fediverso, tuttavia ci saranno anche delle implicazioni di cui è bene tener conto.

Su ciascuno di quei serverini, ci saranno i dati del admin ma anche i dati di altre persone con le quali l'admin avrà interagito, con le quali avrà scambiato messaggi, testi, allegati. Sono dati personali altrui. Poco importa se quei dati sono stati spontaneamente inviati e noi li abbiamo solo ricevuti. Finché li abbiamo, li dobbiamo custodire in modo appropriato.

Questo implica che il gestore del server corra un rischio e ne deve essere consapevole.

Cosa succede se l’admin non è abbastanza bravo a gestire il suo server e i dati sono esposti su internet o oggetto di un data breach?

Il GDPR prevede una esenzione per i trattamenti personali, sono infatti esclusi dal campo di applicazione del GDPR i trattamenti …

“effettuati da una persona fisica per l'esercizio di attività a carattere esclusivamente personale o domestico”; (articolo2)

Questa esenzione ha dei limiti, per uscire dalla sua protezione basta infatti  essere un professionista o, in generale, un lavoratore che, per esempio, comunica con un cliente o con un altro professionista. In questi casi lo strumento di comunicazione (il fediverso e la sua istanza) richiede una serie di protezioni e di adempimenti per i quali, certamente,  non può più essere considerato un simpatico giocattolino.

Chi crea un'istanza aperta ad altri utenti…

In questo caso avviene una magia: ci stiamo trasformando in piccoli Mark o piccoli Elon.

Questo ce lo dice il GDPR:

“il presente regolamento si applica ai titolari del trattamento o ai responsabili del trattamento che forniscono i mezzi per trattare dati personali nell'ambito di tali attività a carattere personale o domestico.” (considerando 18)

Cosa significa? 

Lascio ad altri eventuali considerazioni di tipo amministrativo, autorizzativo e ogni considerazione sulla normativa di settore (AgiCom in primis) e mi limito alle considerazioni più immediate e dirette.

Significa che l’amministratore dell’istanza DEVE adempiere a tutto ciò che il GDPR prevede e risponde per tutto ciò che il GDPR mette sulle spalle di un titolare del trattamento. Non è una posizione semplice e, peraltro, si parte male a causa del fatto che i dati sulle istanze sono attualmente in chiaro. Dubito che l’amico nerd che ha messo su l’istanza per il proprio condominio sia in grado di adempiere o anche solo comprendere gli obblighi e le responsabilità a suo carico che questo comporta.

Dubito anche che si abbia la voglia, il tempo e il denaro per proteggere adeguatamente quel severino e per curare gli adempimenti sottostanti.

Dopo aver superato lo scoglio della adeguata protezione dei dati che si ha l’obbligo di custodire, infatti, ci si deve confrontare con una serie di adempimenti:

• l’elencazione precisa e completa dei trattamenti effettuati
• l’individuazione di una base di legittimazione per i trattamenti sottostanti al serverino
• la definizione di una politica di retention dei dati e la sua attuazione
• la scrittura dell’informativa da mettere a disposizione degli utenti (auguri per questo!)
• probabilmente, l’acquisizione e la documentazione del loro consenso
• la redazione del registro dei trattamenti
• l’individuazione e la nomina dei responsabili del trattamento (auguroni per questo!)
• l’individuazione degli addetti incaricati del trattamento (tanti tanti auguri per questo!)
• una procedura da seguire in caso di data breach
• fino alla nomina di un DPO, qualora il trattamento assuma un rilievo tale da comportare anche questo adempimento.

Con riferimento all’informativa vale la pena ricordare che si tratta di un adempimento molto delicato. Non si possono dire cose sbagliate, non si possono omettere informazioni rilevanti, bisogna essere esaustivi, chiari, sintetici, comprensibili ad ogni nostro utente e, immagino, non tutti gli utenti sono cintura nera di data protection. L’informativa che una istanza deve scrivere deve tenere conto di tutto ciò che è scomodo dire e deve dirlo in modo palese.

Magari un giorno mi metterò a scrivere una bozza di informativa per un’istanza tipo, intanto ne anticipo la versione sintetica che dovrebbe campeggiare in ogni dove e comparire come un popup ovunque ed in continuazione:

“Barrisci responsabilmente!

Attenzione, ogni toot sarà visibile pubblicamente, anche i messaggi diretti. Nel fediverso non c’è riservatezza dei contenuti. Tutto ciò che invii, inclusi i metadati (utenti seguiti, like, data ed ora degli invii, destinatari, mittenti, indirizzo IP da cui ti colleghi, ecc.), sarà visibile pubblicamente, sarà conservato per sempre. Tutto quello che dirai o farai potrà essere usato, da chiunque, contro di te o contro i tuoi contatti.” 

Beh, forse messa in questi termini potrebbe suonare più come una minaccia, ma non penso che i contenuti siano lontani dalla verità.

Dulcis in fundo, è necessario strutturare una procedura e un flusso informativo per la gestione delle richieste di accesso ai dati e l'esercizio dei diritti da parte di ogni possibile interessato, cioè da parte degli utenti di una certa istanza o di ogni utente che ha mandato un messaggio verso quella istanza. 

Porcavacca, sono tanti. Vuoi che non ci sia tra loro un DPO piantagrane?

Questo significa organizzare un apparato di ricezione, valutazione, elaborazione delle risposte che sia di alto adeguato, con tempi di risposta adeguati e, in ogni caso, inferiori ad un mese e che sia, per quanto possibile, in grado di disinnescare le querelle che potrebbero nascere a causa di domande imbarazzanti o richieste sgradite. Non si può bannare gli utenti piantagrane, non si può rispondere “è gratis, di cosa ti lamenti”, non si può buttare giù tutto e scomparire se le cose vanno male. Stacca Stacca Stacca… in questo caso non funziona.

Se vuoi questa bicicletta, poi, devi pedalare! Devi sapere quello che fai e non puoi esimerti dai doveri e non puoi dimenticarti delle responsabilità che assumi. Anche perchè loro, le responsabilità, non si dimenticheranno di te.

È noto che, nel recentissimo passato, importanti istanze (non farò nomi: mastodon.uno) abbiano criminalizzato gli utenti colpevoli di aver ipotizzato che vi fossero dei problemi nella conservazione degli allegati e chiesto informazioni a riguardo. Drammatico! Utenti competenti e consapevoli, attenti alla propria riservatezza, che hanno solo fatto domande lecite, sono stati bannati ed estromessi. Una epurazione, in pratica.

Questo caso mi ha colpito perché dimostra un dilettantismo fuori scala, una approssimazione pericolosa per sé e per gli altri.

Se trattano così un utente fastidioso, con quale garbo tratteranno i dati personali di migliaia di utenti, così divertenti da sbirciare, così succulenti da monetizzare, così facili da carpire.

Anche senza voler considerare gli evidenti inadempimenti al gdpr, anche il solo fatto di aver liquidato in questo modo una DSAR* configura una pesante responsabilità e, come una valanga, può allargarsi su un fronte immenso, ingestibile per una cricca di nerd che hanno messo su un simpatico giochino.

*(Data Subject Access Request)

Anche volendo ammettere che il caso citato rappresenti un'anomalia e che gli amministratori siano tutti ben disposti a ricevere segnalazioni, consigli e critiche costruttive, restano i limiti tecnici che rendono impossibile accogliere integralmente le DSAR, le richieste di accesso ai dati personali, se corredate dalla richiesta di cancellazione.

La gestione degli allegati è, infatti, piuttosto complessa e scorporata dalla gestione del testo dei messaggi o dai metadati gestiti dal server. Spesso si appoggia a provider esterni che, ovviamente, rientrano nella filiera del trattamento del dato in veste di responsabile del trattamento.

Accogliere una richiesta di cancellazione diventa impossibile nell’immediato, difficile nel medio termine e concretamente impossibile in molti casi. 

Non è tutto qui ma direi che questo è già sufficiente per capire che tutto ciò  non si fa in due minuti e non si fa con il copia-incolla da un file trovato su internet cambiando XXXXX con il nome della propria istanza.

A questo scenario, focalizzato sul GDPR, si deve aggiungere ciò che prevede il codice penale e che, salvo sorprese, si applica anche a questo specifico caso:

l’amministratore, come anche a suo tempo il sysop, può tutto e può certamente vedere i messaggi, inclusi quelli privati. Vede i messaggi dei suoi amici, ai quali ha “graduidamente” fornito credenziali di accesso individuali e un account personale, ma vede anche i messaggi e i dati personali di ogni loro contatto o utente del fediverso con il quale gli amici abbiano intrattenuto amene e “riservate” conversazioni. Che una conversazione sia tecnicamente accessibile non significa sia lecito sbirciarla.

Resisterà il nostro eroe a cotanta tentazione? Non resisterebbe nemmeno Ulisse legato all’albero della sua nave.

In questo caso si rischia l’applicazione dell’articolo 616 del codice penale che punisce la violazione, la sottrazione e la soppressione di corrispondenza. Se la guardi, sei un criminale. Se la tocchi, sei un criminale, se spegni il server perchè la bolletta ti devasta e la corrispondenza non viene più recapitata, sei un criminale. (per dettagli, si veda qui https://www.brocardi.it/codice-penale/libro-secondo/titolo-xii/capo-iii/sezione-v/art616.htm)

Magari a nessuno verrebbe in mente di aprire la casella di posta del vicino e curiosare gli estratti conto della banca aprendo le lettere che ha ricevuto. Purtroppo sembra molto meno compromettente curiosare sul serverino su cui gira una nostra istanza, specialmente quando si possono cancellare le proprie impronte… ma questa è solo una pia illusione.

Dopodiché vale la pena di ricordare l’esistenza dell’articolo 615 ter: accesso abusivo ad un sistema informatico o telematico che prevede una responsabilità specifica per l’abuso del ruolo di operatore di sistema. 

“Ma come, vostro onore… ma il computer era il mio!”

Mi immagino già le risate in aula. Purtroppo questo dettaglio sarà irrilevante poichè viene punita la condotta del soggetto che, anche se abilitato ad accedere al sistema, lo faccia per raccogliere dati protetti per fini diversi dalle ragioni per cui possiede le chiavi di accesso. Questo configura un uso del sistema sistema per finalità diverse da quelle consentite.

… qui tutti i dettagli

https://www.brocardi.it/codice-penale/libro-secondo/titolo-xii/capo-iii/sezione-iv/art615ter.html 

Sarà molto interessante leggere i Term&Conditions delle varie istanze, con matita rossa e blu, alla ricerca di tutti i punti problematici, sia sotto il profilo penale, sia sotto il profilo civilistico, con il pensiero ai risarcimenti che gli utenti potranno chiedere ai nerd gestori di istanze compromesse, buggate, spente, crashate, ecc.

Una sola parola a riguardo: clausole vessatorie. Quanto ci rimarrà male l’admin sentendosi dire che la metà dei T&C, ovviamente scopiazzati dall’istanza blasonata, sono inutili perché non sono state gestite correttamente le clausole vessatorie?

Chi diventerà utente di una istanza piccina picciò, del proprio amico, condomino, collega, compagno di merende che sia…

Le implicazioni appena descritte sono chiaramente più gestibili ma aumenta a dismisura un rischio: il fatto che i dati siano per significativi ed interessanti per l’admin. I dati che gireranno sul serverino saranno tutti riferiti a persone ben note all’Admin, conosciute, per le quali può si può sviluppare probabilmente una normalissima e sana curiosità. E l’occasione fa l’uomo ladro.

La vicina di casa carina, il compagno di calcetto che rimorchia un sacco, il compagno di banco che ha sempre roba buona, quella schifezza umana del mio vicino che mi rompe le scatole se sento la mia musica, ecc.

Provengo da un paesino e ho sperimentato che nei paesini tutti sanno tutto di tutti. Vivo in una grande città e quando la cameriera mi inizia a chiamare per nome, cambio bar e torno ad essere invisibile.

In ogni piccolo mondo la riservatezza è inversamente proporzionale al rumore di fondo, alla confusione, alle dimensioni del mucchio.

Pensando ad una istanza elefantiaca con migliaia di utenti…

Le implicazioni diventano più serie, gli adempimenti più rigorosi e complessi e cresce il rischio di venire coinvolto in vicende scomode ed antipatiche per colpa di altri. Se nell’istanza si spacciano figurine dei Pokemon, potresti essere torchiato dalla STASI per spaccio di figurine, ma certamente tutto si risolverà bene e potrai uscire con le tue gambe dalla stanza degli interrogatori. Forse. 

Per fortuna ci sono però dei risvolti positivi: si offusca l’interesse e la significatività del dato del singolo. Probabilmente per l’admin sarà più facile avere il giusto distacco dai dati che circolano sul serverino… a meno che non si identifichino persone interessanti, per le quali si finirà per sviluppare fissazioni e, di nuovo, invasione della vita privata. 

Certo, se l’admin non è un bravo ragazzo, con molti utenti potrebbe anche divertirsi un sacco… ma sono certo che questa sia una ipotesi irrealistica. Siamo tutti brave persone e chi pensa male è un lestofante.

Intanto… auguri.

Tutto questo, il GDPR, il codice penale, la responsabilità civile, sembra incongruo e incomprensibile se si pensa che il serverino gira spinto dalla passione, per hobby, che nessuno ci guadagna e che lo si fa quasi per gioco.

Tuttavia un giovane nerd, prima di montare la sua istanza, dovrebbe familiarizzare con un concetto: l’affidamento!

MAI CREARE L’AFFIDAMENTO.  

Se qualcuno, chiamiamolo euGenio, è stato portato a pensare che sul tuo serverino sia possibile mandare messaggi diretti ad una sola persona e tu lo ospiti come utente, poco importa se euGenio non sia un genio dell’informatica, poco importa che nessuno ti paghi per un servizio e che lo fai per diletto. Poco importa che tutti sappiano che euGenio sta sbagliando!

Quando euGenio si sveglierà dal suo torpore, magari perchè, in seguito un uso malandrino dei messaggi visibili all'admin, il suo capo lo licenzierà, la fidanzata lo pianterà, il condomino lo prenderà a cazzotti perchè euGenio parla male di lui...  tutto ti sarà chiaro e ti pentirai di aver acceso quel maledetto Raspberry e di averlo collegato al fediverso.