Ringrazio di cuore Giacomo per la sua approfondita analisi di cui terrò sicuramente conto per il futuro.
Ci sono tanti interessanti spunti (alcuni anche leggermente fuori dal contesto di riferimento), ma ho apprezzato che sia stato compreso lo spirito "disruptive" del mio intervento.
A presto
Giuseppe
On [DATE], "[NAME]" <[ADDRESS]> wrote:
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-gli-algoritmi-sostituire-gli-esseri-umani ) 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
________________________________
Torino - Milano - Roma - Aosta - Busto Arsizio - Bergamo
R&P Legal studio associato
Le informazioni trasmesse sono destinate esclusivamente alla persona o alla società in indirizzo e sono da intendersi confidenziali e riservate. Ogni trasmissione, inoltro, diffusione o altro uso di queste informazioni a persone o società differenti dal destinatario è proibita. Se ricevete questa comunicazione per errore, contattate il mittente e cancellate le informazioni da ogni computer.
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Π Please consider the environment before printing this email.