October 2018 - nexa - server-nexa.polito.it

New Standards for Multimedia Streaming Systems | 17 ottobre, Torino

by Francesco Ruggiero

Gentilissimi, mercoledì *17 ottobre 2018*, dalle ore 12.30 alle ore 13.30, avrà luogo il *7°* appuntamento del ciclo d'incontri "*i Dauin Lunch Seminar*" presso la Sala Conferenze “Luigi Ciminiera” del Dipartimento di Automatica e Informatica del Politecnico, in Corso Castelfidardo 34/D, Torino. Il seminario, dal titolo: *New Standards for Multimedia Streaming Systems*, sarà tenuto dal *Prof. Enrico Masala* (Dauin - Politecnico di Torino). Maggiori informazioni sono disponibili all'indirizzo: https://nexa.polito.it/dauin-lunch-seminars In allegato la locandina. Grazie per l’attenzione, Francesco -- Francesco Ruggiero Communication Manager Nexa Center for Internet & Society Politecnico di Torino - DAUIN Corso Duca degli Abruzzi, 24 - 10129 Torino web: http://nexa.polito.it mail: francesco.ruggiero(a)polito.it tel: 011 090 7219

Oct. 15, 2018

Re: [nexa] Tecnologie legali

by Giacomo Tesio

Il giorno sab 13 ott 2018 alle ore 18:36 Luca Cappelletti <luca.cappelletti(a)gmail.com> ha scritto: > > Il 13/10/18 00:57, Giacomo Tesio ha scritto: > ... > > I bug non sono l'eccezione che capita a programmatori > > normalmente infallibili. Sono la norma. > > Temo di non aver compreso bene, ma se fosse la norma dovremmo avere > centinaia di aerei, treni, automobili, satelliti, dispositivi medicali, > centrali atomiche "sfracellarsi" continuamente senza sosta.. Ciao Luca, poni una obbiezione molto interessante. Anzitutto ti confermo che i bug sono la norma. Qualsiasi programmatore con un minimo di esperienza te lo potrà confermare. Se non ricordo male, in "The Mythical Man-Month", Fred Brooks sosteneva che il numero di bug cresca in modo quadratico con la lunghezza del programma. In "Code Complete", Steve McConnell sostiene che la media dell'industria informatica si pone fra i 15 e i 50 bug ogni 1.000 righe di codice. Qui puoi dare un'occhiata ad una stima (molto ottimistica) dei bug del kernel Linux: https://scan.coverity.com/projects/linux Sul tuo cellulare Android vengono eseguite miliardi di righe di codice: solo il kernel, Linux, sono 14 milioni di righe, poi c'è la libreria C, le librerie crittografiche, la java virtual machine, tutte le applicazioni. Alcune di quelle righe di codice sono generate automaticamente da software a loro volta buggati. E i compilatori che producono gli eseguibili sono a loro volta buggati ed introducono talvolta bug nel software a causa di processi di ottimizzazione errati. La frequenza e la pesantezza degli aggiornamenti di Windows o di Android dovrebbe permetterti di intuire il problema. Il gigante ha piedi di argilla. L'intera informatica è ancora ad uno stato embrionale, primitivo. Se qualcuno ti dice il contrario, chiedigli di indicarti 1 software mainstream sopra le 20.000 righe di codice SENZA bug. La questione non è mai se un software abbia bug. Li ha. La questione è quanti, quanto gravi e quanto costosi da correggere. Vi è una forte variabilità fra un settore e l'altro, fra un progetto e l'altro, fra uno sviluppatore e l'altro, fra un linguaggio e l'altro. Ma siamo ancora molto, molto, molto lontani da produrre software complesso e corretto. Le tecniche che ci si avvicinano di più, come il Cleanroom di Mills, sono usate molto raramente, solo in sistemi critici (aereonautica, industria areospaziale) perché molto costose. E non sempre. > Ma non vedo questi effetti statistici, quindi o questi sistemi non usano > software o il software che usano considerano il programmatore un > criminale e quindi riducono il bug ad un evento raro e ben gestibile > (tranne qualcha rara volta) Semplicemente non sai dove guardare. E confronti il software per aerei con il software LegalTech descritto eccellentemente da Giuseppe. Sono due mondi totalmente diversi con livelli qualitativi assolutamente incomparabili. Prendiamo gli aerei, che sono i veicoli autonomi di livello due più avanzati del pianeta. Ogni singola riga di codice costa migliaia di euro. I bug ci sono comunque, ma sono nel ordine di 1 ogni 20.000 righe di codice. Se imponessi lo stesso livello qualitativo ad una Self Driving Car, che su una strata aperta al pubblico affronta una complessità di diversi ordini di grandezza maggiore di quella affrontata da un aereo durante un volo intercontinentale, otterresti due effetti: 1. l'istantanea rimozione di qualunque rete neurale nel simulatore alla guida 2. l'abbandono del progetto dalla maggioranza dei player Se non sai dire a quale specifica un software risponda (perché l'hai addestrato con un reinforcement learning, ad esempio), questo è "broken beyond repair". Può essere utile per giocare, o se ricadi nei casi per cui è stato provato. Ma nessun ingegnere con un minimo di buon senso lo metterebbe alla guida di un auto. D'altro canto se il software che controlla il sistema di entertainment sulla tua auto ha un baco, magari non senti la musica un giorno, ma l'auto continua a frenare. Se invece quello stesso baco è alla guida dell'auto hai un grosso problema. Ed infatti i treni e gli aerei dispongono di sistemi di sicurezza meccanici di emergenza proprio per i casi in cui il software fallisce in modo inatteso. Ora, tutte queste sono cose note, persino ovvie, che qualsiasi programmatore ti può confermare (mi scuso anzi per la lunghezza, ma volevo essere chiaro). Il fatto che molti non ne abbiano coscienza deve farci riflettere. Mancano totalmente gli strumenti culturali per interpretare la tecnologia. Per questo la gente va dietro alla blockchain, alle cryptovalute e alla singolarità nella IA. Per la stessa ragione per cui crede ai NOVAX e alle scie chimiche: in assenza di conoscenza, si adotta il pensiero magico, affidandosi al personaggio più carismatico. Non esistono software senza bug. Giacomo PS per gli amici geek all'ascolto: lo so, `true`, `yes`, `false` e `cat` forse non ne hanno... ma... gli script che li usano? ;-)

Oct. 13, 2018

Re: [nexa] approvato il regolamento UE sulla libera circolazione dei dati non personali

by Andrea Glorioso

Caro Marco, ho riflettuto molto sul nostro scambio e sulle posizioni che hai condiviso, delle quali ti ringrazio. Sono utili per rimettere in discussione alcuni assunti che chi, come me, lavora oramai da molti anni per il Lato Oscuro^W^W^W la Commissione Europea, tende a dare per scontati. Credo siamo d'accordo che in ultima analisi dovrà essere la Corte di Giustizia dell'UE, nel caso, a dare un'interpretazione autentica delle norme di cui discutiamo. Per altro ho verificato la giurisprudenza in materia, che al momento si riferisce prevalentemente alla Direttiva del 1995, ma dato che la GDPR non cambia granché dell'impianto generale di quest'ultima - specialmente per quanto riguarda i temi oggetto del nostro scambio - posso confermare che la Corte non sembra essersi espressa specificamente sull'argomento. Ci sono tuttavia un paio di punti che vorrei precisare. On Thu, Oct 11, 2018 at 11:00 AM Marco Ciurcina <ciurcina(a)studiolegale.it> wrote: > Più precisamente (come recita l'art. 1(3)), no, nella misura in cui la > libera > circolazione è limitata o vietata "per motivi attinenti alla protezione > delle > persone fisiche con riguardo al trattamento dei dati personali". > Sarei d'accordo con te se l'art. 1(3) recitasse "La libera circolazione > dei > dati personali nell'Unione non può essere limitata né vietata.". > Ma, invece, hanno aggiunto le parole "per motivi attinenti alla protezione > delle persone fisiche con riguardo al trattamento dei dati personali" che > circoscrivono la portata della norma. > IMHO assumi che "per motivi attinenti alla protezione delle persone > fisiche > con riguardo al trattamento dei dati personali" coincida con "nella misura > in > cui la GDPR è applicabile" (è quanto meno opinabile). > Dal mio punto di vista, qualsiasi "motivo attinente alla protezione delle persone fisiche con riguardo al trattamento dei dati personali" è normato dalla GDPR, laddove la GDPR si applica, e tenendo conto delle eccezioni. Non ripeto quanto ho già scritto. Possono naturalmente esservi altri motivi che uno Stato Membro usa per giustificare una restrizione alla libera circolazione dei dati personali (all'interno dell'UE/EEA) come gli esempi che hai proposto tu ("sovranità digitale" e altri) e che non sono normati dalla GDPR. Se vi fossero norme, a livello UE o degli Stati Membri, che in qualche modo impedissero la libera circolazione di dati personali al di fuori dei casi normati (anche in via di eccezione) dalla GDPR, ci troveremmo di fronte ad una necessità abbastanza classica di contemperare / bilanciare tali norme. Per altro assumo che tali norme siano di rango equivalente, il che è un punto importante visto il principio di supremazia del diritto UE sugli ordinamenti nazionali, così come stabilito dalla giurisprudenza della CGEU. Sono a conoscenza di casi di alcuni Stati Membri (si dice il peccato ma non il peccatore) che hanno introdotto p.e. circolari ministeriali o direttive regionali volte a limitare la libera circolazione dei dati personali per i motivi più disparati (tra gli altri: "efficienza della pubblica amministrazione", "protezione dell'onorabilità", "cyber-security" e un mai dimenticato, almeno tra noi eurocrati, "tutela della salute psicologica di dipendenti pubblici" - si legge di tutto a Bruxelles). In tutti tali casi, tali "regole" sono state prontamente ritirate senza nemmeno bisogno del suggerimento di una procedura di infrazione, perché ovviamente di rango inferiore al diritto UE e potenzialmente in grado di limitare la libera circolazione dei dati personali, al di là che esse facessero implicito o esplicito riferimento al trattamento di dati personali. > > e fatte salve le eccezioni previste > > dalla GDPR, che devono essere interpretate in maniera specifica e > > funzionalmente agli obbiettivi della GDPR e più generalmente del diritto > > UE, che sono di promuovere e non di restringere il flusso di dati > personali > > all’interno dell’UE”. > Proponi una ragionevole interpretazione "ampia" dell'art. 1(3) GDPR. > Sono possibili ragionevoli interpretazioni più restrittive (per esempio, > quella che proponevo nell'email precedente). > Per essere sincero, con tutto il rispetto faccio fatica a considerare la tua interpretazione (o quanto meno gli esempi che hai portato) come "ragionevoli", non solo perché a mio parere difficilmente giustificabili da un punto di vista logico (se dici "non voglio trasferire dati personali per ragioni di sovranità digitale", sempre di dati personali stiamo parlando) ma soprattutto perché mi sembrano di fatto incompatibili proprio con la logica di base delle regole UE, in particolare quelle relativa al mercato interno e all'area di sicurezza, libertà e giustizia, la cui logica è di condivisione e scambio sulla base di regole comuni che si assumono siano correttamente applicate. Poi ovviamente esistono le eccezioni a tutto, ma la CGUE ha sempre e in maniera consistente interpretato il diritto UE secondo tale logica. Se poi vogliamo allargare la discussione, una domanda secondo me interessante è in che misura le recenti discussioni con alcuni Stati Membri circa l'indipendenza del loro ordine giudiziario e/o rispetto dei principi di base dell'UE, ivi compresi i diritti fondamentali dei cittadini europei, potrebbero portare ad una situazione in cui uno Stato Membro potrebbe ragionevolmente rifiutarsi di trasferire dati personali ad un altro Stato Membro in quanto mancherebbero le garanzie che quest'ultimo stia applicando correttamente e in buona fede la GDPR, ivi comprese le relative garanzie che dipendono tra gli altri fattori dall'avere delle Autorità per la Protezione dei Dati Personali e un ordine giudiziario davvero indipendenti. Non sono ahimè casi ipotetici: non molto tempo fa, la Commissione propose (e vinse) una procedura di infrazione nei confronti della Germania, in quanto le relative Autorità per la Protezione dei Dati Personali (quella federale e quelle sub-federali) erano almeno da un punto di vista formale "troppo" dipendenti dal potere legislativo (la legge nazionale è stata cambiata). E in senso più ampio, mi pare rilevante anche il caso C-216/18, in cui alla CGEU fu richiesto dalla "High Court" irlandese di pronunciarsi in merito all'esecuzione di una mandato di arresto europeo da parte delle autorità polacche, su cui la corte irlandese nutriva dei dubbi proprio per una supposta incapacità della Polonia di applicare correttamente l'acquis dell'UE in seguito alle riforme giudiziarie lì avvenute. > Quale sia l'interpretazione corretta ce lo dirà la CGUE se e quando sarà > investita della questione. > :-) > Certamente. Però possiamo lanciarci in ragionevoli ipotesi. :) Ciao, grazie, Andrea

Oct. 13, 2018

Re: [nexa] Tecnologie legali

by Luca Cappelletti

Il 13/10/18 00:57, Giacomo Tesio ha scritto: ... > 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à. Temo di non aver compreso bene, ma se fosse la norma dovremmo avere centinaia di aerei, treni, automobili, satelliti, dispositivi medicali, centrali atomiche "sfracellarsi" continuamente senza sosta.. Ma non vedo questi effetti statistici, quindi o questi sistemi non usano software o il software che usano considerano il programmatore un criminale e quindi riducono il bug ad un evento raro e ben gestibile (tranne qualcha rara volta) saluti Luca

Oct. 13, 2018

Re: [nexa] Tecnologie legali

by Amedeo Santosuosso

grazie a tutti per avermi tenuto nel giro di questa interessantissima discussione! A Amedeo Santosuosso President of First Chamber, Court of Appeal of Milan (Italy) Professor of Law, Science, New Technologies at the University of Pavia, Department of Law Professor of law, Science and emerging technologies at Institute of Advanced Studies (IUSS), Pavia (I) Interdepartmental Research Center ECLT, University of Pavia (I), Scientific Director World Commission on the Ethics of Scientific Knowledge and Technology (COMEST -UNESCO), Member a.santosuosso(a)unipv.it http://www.unipv-lawtech.eu/ Tel. + 39 0254334204 Fax +39 0254334048 Mobile +39 3385053317 a.santosuosso(a)unipv.it > Il giorno 13 ott 2018, alle ore 12:18, Vaciago, Giuseppe <Giuseppe.Vaciago(a)replegal.it> ha scritto: > > 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-g… > ) 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. >

Oct. 13, 2018

AI ethics and human rights: where we need to go

by Masera Anna

https://medium.com/@sherifea/ai-ethics-and-human-rights-where-we-need-to-go… Inviato da iPhone ________________________________ Il presente messaggio (inclusi gli allegati) contiene informazioni riservate esclusivamente al destinatario/ai destinatari indicato/i nel messaggio, ed è protetto dalla legge. La diffusione, distribuzione e/o la copia del contenuto del presente messaggio da parte di qualsiasi soggetto diverso dal destinatario è severamente vietata ai sensi dell’art. 616 c.p. e delle vigenti normative in materia di protezione dei dati personali. Se non siete i destinatari del presente messaggio, vi preghiamo di distruggerlo e di darcene immediata comunicazione inviando un messaggio di ritorno all’indirizzo e-mail del mittente. This message (including any attachments) contains confidential information intended only for the recipient(s) named above, and is protected by law. Any disclosure, distribution and/or copying of this message by any subject different from the named recipient(s) is strictly prohibited according to art. 616 c.p. and to the applicable data protection laws. If you are not the intended recipient, please delete this message and inform us immediately about the deletion by sending a message to the sender’s e-mail address. ________________________________

Oct. 13, 2018

Re: [nexa] Tecnologie legali

by Vaciago, Giuseppe

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-g… ) 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.

Oct. 13, 2018

Re: [nexa] Tecnologie legali

by Giacomo Tesio

Il Sab 13 Ott 2018 08:21 Vincenzo Mario Bruno Giorgino <vincenzo.giorgino(a)unito.it> ha scritto: > > un sistema serio di trusted timestamping aggiungendo senza spiegazioni "Non la blockchain". Ciao Vincenzo, l'assenza di spiegazioni sulla blockchain era dovuta alla necessità di contenere un intervento già molto lungo. Ti allego di seguito il contenuto di una mail che ho scritto a giugno per Daniele Bettini e che tratta il tema da un punto di vista più vasto. Nel caso specifico del trusted timestamping la blockchain non può funzionare per le stesse ragioni di consistenza ivi descritte. A tali ragioni si aggiunge il fatto che a fronte di un accentramento del mining, o a fronte di barriere all'ingresso che permettano di conoscere l'insieme dei minatori in anticipo e fermare il sistema in caso di partizioni, tutto si riduce ad un enorme spreco di energia: se possiamo determinare a priori chi garantisce la consistenza, allora ci stiamo fidando di lui e a questo punto possiamo progettare molti sistemi più efficienti per offrire lo stesso servizio. Di seguito la mail che scrissi a Daniele > il mio parere sulla blockchain e sulle cryptocurrency nate dal successo di Bitcoin è principalmente tecnico. > > Nel 2002 è stato dimostrata la congettura di Brewer (https://it.wikipedia.org/wiki/Teorema_CAP) è matematicamente impossibile avere un sistema distribuito in cui le informazioni disponibili a tutti i nodi siano conteporaneamente disponibili e coerenti. > Ovvero, è stato matematicamente dimostrato che, o si ferma la computazione complessiva nel momento in cui anche un solo nodo viene disconnesso dalla rete (rinunciando alla disponibilità della computazione su scala globale), o si rinuncia alla coerenza delle informazioni. > Quindi, il mining (che è una computazione distribuita) semplicemente non funziona per garantire un consenso (che implica coerenza) perché quando togliamo un nodo, non fermiamo tutto. > Usarlo come moneta è dunque impossibile, perché intrinsecamente ed inevitabilmente il sistema apre a truffe (che in effetti avvengono periodicamente). > > Questo dal punto di vista matematico (ma nota, io sono un programmatore, non un matematico... :-D). > > > Dal punto di vista ingegneristico invece, il sistema non può funzionare nel lungo periodo a causa del consumo energetico delle PoW. E no, nessuna delle alternative alla PoW di cui si fantastica fin ora sono credibili. > > > Dal punto di vista economico si pone poi il problema se sia fuffa o una truffa. Definire le cryptomonete schemi ponzi distribuiti non è sbagliato. > In sostanza chi compra token immette denaro sistema e riceve...promesse. Chi vende token prende denaro e offre una promessa. Fin tanto che le persone CREDONO in queste promesse e continuano ad acquistarle, chi le vende può sottrarre loro denaro. Quando queste persone smettono di credere a tali promesse, devono venderle in cambio di denaro e sono di fatto costrette a convincere altre persone ad acquistarle. Uno schema Ponzi distribuito appunto. > > > Dal punto di vista legale, il parziale anonimato inoltre, unito alla liquidità del sistema, permette trasferimenti a basso rischio fra organizzazioni criminali con perdite minime. > > > Se tutto questo non ti sembrasse convincente, considera questo: perché Google, Amazon e Microsoft continuano a sbattersi su problemi complessi come la AI se potesser utilizzare la propria potenza di calcolo per minare cryptovalute? > La risposta è semplicissima: dispongono di ingegneri competenti. > > > Una nota etica però: di tutte le cryptovalute, Bitcoin è l'unica che avesse in origine un vero intento etico: era un esperimento o più propriamente un hack, un atto creativo di curiosità. > Un hack di successo direi: permette di identificare chiaramente ingegneri incompetenti e/o disonesti. > > Tutte le altre cryptovalute non sono espressioni della curiosità di un hacker, solo tentativi più o meno maldestri di trasformare capitali altrui in calore. A presto! Giacomo

Oct. 13, 2018

Re: [nexa] Tecnologie legali

by Vincenzo Mario Bruno Giorgino

Caro Giacomo, ho letto il tuo commento con interesse ed ho un solo punto su cui sarei lieto di avere una spiegazione o rinvio ad altre fonti. Mi riferisco al brano in cui auspichi un sistema serio di trusted timestamping aggiungendo senza spiegazioni "Non la blockchain". Per inciso credo che usando il singolare ti riferisca alla bitcoin blockchain con il suo algoritmo di consenso delle transazioni basato sulla proof of work, raggiunta con la competizione tra minatori. Grazie. Un saluto, Vincenzo Il Sab 13 Ott 2018, 00:57 Giacomo Tesio <giacomo(a)tesio.it> ha scritto: > 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-g… > ) 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 > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >

Oct. 13, 2018

Tecnologie legali

by Giacomo Tesio

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-g… ) 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

Oct. 12, 2018