Ciao a tutti, ho appena visto la registrazione del 112° Mercoledì di Nexa incontro di mercoledì ( https://nexa.polito.it/mercoledi-112 ) e vorrei offrirvi un paio di piccoli contributi tecnici. Anzitutto una nota importante, per la sicurezza vostra e dei vostri clienti. Chi amministra il vostro sistema informatico può accedere a qualsiasi contenuto su di esso. Se dispone di accesso fisico alle vostre macchine, non c'è crittografia che tenga. Dunque, se la vostra sicurezza informatica è in qualche modo rilevante e non siete in grado di amministrare personalmente il vostro sistema avete solo due opzioni disponibili: 1. stabilire un serio rapporto di fiducia e rispetto reciproco con uno o più sistemisti competenti 2. smettere di usare i computer per lavoro Immaginare che dei log possano svelare o provare un'attacco da parte di un sistemista competente con conoscenza della sistema e accesso fisico alle macchine è una pia illusione. Davvero, non sto esagerando. Nel merito: ho ascoltato con attenzione il discorso di Giuseppe che ho trovato molto interessante. In diversi passaggi ha (credo inconsapevolmente) descritto tensioni importanti ed ancora irrisolte nell'ingegneria del software. Per esempio, l'"approccio agricolo" che propone ricorda per molti aspetti lo stile architetturale di Unix, la scuola del New Jersey: l'idea di sviluppare piccoli programmi specializzati che "fanno UNA cosa (abbastanza) BENE" invece che sviluppare piattaforme potenti, complesse ed estendibili che "fanno anche il caffé". Io sono un fautore della semplicità nell'informatica (che considero condizione necessaria per la sicurezza), ma è bene notare che lo svantaggio dello stile Unix è il carico cognitivo sull'utente, che dispone di strumenti diversi e disomogenei che deve imparare ad usare separatamente. Conoscere tanti strumenti significa poter usare sempre quello appropriato, ma molti preferiscono conoscerne bene due o tre e fare tutto con quelli. Se posso poi permettermi un suggerimento, consiglierei di leggere "Domain Driven Design: Tackling Complexity in the Heart of Software" di Eric Evans (vedi http://dddcommunity.org/book/evans_2003/ ) agli avvocati che volessero imitare l'esempio "agricolo" di Giuseppe partecipando alla realizzazione di software che facilitino il lavoro dell'avvocato su ambiti specifici. Si tratta ormai di un classico dell'informatica, un libro tecnico ma accessibile, e credo possa essere particolarmente utile a voi avvocati perché il DDD consiste sostanzialmente nel processo di apprendimento da parte di un programmatore del linguaggio e delle logiche di un dominio (ad esempio una normativa) spiegata da un esperto (ad esempio un avvocato). Il compito del programmatore è cristallizzare in codice eseguibile quanto appreso, utilizzando lo stesso linguaggio dell'esperto in modo che tutti, dal codice, ai programmatori, agli esperti di dominio fino agli utenti, parlino la stessa lingua. Si tratta di una tecnica che ho applicato personalmente con successo in diversi progetti bancari, in cui la normativa di riferimento è piuttosto complessa (la Mifid), ogni banca ha i suoi esperti e gli esperti spesso non concordano, talvolta litigano e devono persino fermarsi per approfondire prima di rispondere alle domande. Questo perché dal codice che deve descrivere e governare il sistema emergono naturalmente contraddizioni, lacune e fraintendimenti. Un'altra considerazione che condivido profondamente (per quel poco che ho avuto a che fare con i tribunali) è che una seria informatizzazione della giustizia aumenterebbe l'efficienza di diversi ordini di grandezza. Efficienza da cui risulterebbe una riduzione dei costi (e delle tariffe? :-P) tale da coprire abbondantemente l'investimento iniziale. E non stiamo parlando di introdurre IA, ma di semplici accorgimenti come comunicare con il tribunale SOLO attraverso email crittografate e firmate elettronicamente. Giuseppe sembra pensare anzitutto al mercato, ma in realtà alcuni servizi dovrebbero essere infrastruttura fornita e garantita dallo Stato. Per esempio un sistema di trusted timestamping serio (aka NON la PEC e NON la blockchain). O un web of trust cui partecipassero anche i comuni, firmando la mia chiave pubblica dopo avermi identificato (magari a fronte del pagamento di una piccola imposta). Un aspetto importante di digital forensics è stato citato relativamente alla stampa di pagine web come prove. L'idea che basti la presenza di un avvocato a garantire l'autenticità di un documento (le pagine Facebook di cui parlavate) si basa su due principi: - la deontologia professionale dell'avvocato - la sua competenza tecnologica Non dubito della prima, ma non sono certo che tutti gli avvocati siano in grado di riconoscere un phishing ben fatto. E comunque, tecnicamente, la pagina potrebbe essere modificata prima della stampa, dunque chi dovesse dubitare della assoluta rettitudine degli avvocati in questione, dubiterebbe anche della stampa stessa. Sia chiaro: non esiste alcuna tecnologia che possa garantire matematicamente l'autenticità di una copia, fisica o digitale, di un contenuto digitale. E' sempre necessario basarsi su una terza parte fidata. Ma tale terza parte fidata non dovrebbe essere il giudice stesso? O il tribunale? Di nuovo un problema di infrastruttura che, secondo me, il mercato non può risolvere. Un'altra questione importante che è stata trattata durante l'incontro è l'impatto delle analisi statistiche sui giudici che, come giustamente detto, "perdono la toga" nel momento che il loro operato diventa prevedibile. A me preoccupa molto, in questo caso, l'interazione fra il paradosso dell'automazione (la tendenza dell'uomo a perdere la capacita critica nei confronti della macchina quando questa funziona correttamente per un certo periodo) e i limiti di queste macchine. Per esempio sono stati citati COMPAS ed il caso Loomis, di cui aveva parlato sabato scorso Amedeo (vedi https://www.radioradicale.it/scheda/553800?p=0&s=7486&t=7736&f=0), ed oltre ai problemi del bias (correttamente descritti durante l'incontro) dobbiamo sempre tenere presente il fatto che il software, in quanto artefatto umano, è sempre soggetto ad errori di programmazione. I bug non sono l'eccezione che capita a programmatori normalmente infallibili. Sono la norma. Dobbiamo chiederci cosa succederebbe se questi bug venissero scoperti DOPO la sentenza, perché accadrà. Al momento, la triplice blackbox (come definita da Guido in http://www.dimt.it/index.php/it/notizie/16903-guido-noto-la-diega-possono-gl... ) impedisce al condannato, danneggiato dal bug, di sapere del bug e chiedere un annullamento o un risarcimento. In questo modo un bug nel software diventa causa di ingiustizia. Mi scuso davvero per la lunghezza, ma non riesco a tagliare di più. Spero almeno di avervi fornito materiale utile per le vostre riflessioni giuridiche. A presto! Giacomo