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
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@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-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 _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Il Sab 13 Ott 2018 08:21 Vincenzo Mario Bruno Giorgino <vincenzo.giorgino@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
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-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 ________________________________ 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.
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@unipv.it http://www.unipv-lawtech.eu/ Tel. + 39 0254334204 Fax +39 0254334048 Mobile +39 3385053317 a.santosuosso@unipv.it
Il giorno 13 ott 2018, alle ore 12:18, Vaciago, Giuseppe <Giuseppe.Vaciago@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-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
________________________________
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.
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
Il giorno sab 13 ott 2018 alle ore 18:36 Luca Cappelletti <luca.cappelletti@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? ;-)
Il 13/10/18 23:34, Giacomo Tesio ha scritto:
Il giorno sab 13 ott 2018 alle ore 18:36 Luca Cappelletti <luca.cappelletti@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.
nella magna somma di tutte le linee di codice nello spazio e nel tempo è vero, ma considero un LegalTech all stregua di un software in ambienti critici ad alta integrita e blahblah vari e li il rapporto segnale rumore cambia di molto nel prodotto finito e testato
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.
Intuisco la questione ma non ne ho un'idea ben precisa in quanto uso OpenBSD che di mestiere elimina codice (che quindi in futuro non puo rompersi in quanto non c'è) e sullo smartphone ho SailfishOS che a parita di bug con Android ho meno features utili che mi servirebbero (..!!..) a parte gli scherzi aggiungo una vecchia lettura sempre valida: http://static1.1.sqspcdn.com/static/f/702523/9277880/1288929538453/200512-Cr... ...
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.
Si ho volutamente "infuso" i due software per via degli effetti drastici sull'uomo in caso di fallimento Se consideriamo i possibili effetti negativi di un errore allora penso che l'approccio dovrebbe essere asintoticamente verso un firmware di un sistema critico per la salute umana. Come ad esempio i software scritti in Spark per i pacemaker. ...
Ora, tutte queste sono cose note, persino ovvie, che qualsiasi programmatore ti può confermare (mi scuso anzi per la lunghezza, ma volevo essere chiaro).
Forse intendi qualche buon programmatore perche ne conosco di diversi rispettabilissimi nel loro specifico linguaggio che non sanno cosa sia un'analisi formale e sono gli stessi che potrebbero ritrovarsi a programmare un "LegalTech" e che stanno programmando i firmware delle lavastoviglie!!
Il fatto che molti non ne abbiano coscienza deve farci riflettere. Mancano totalmente gli strumenti culturali per interpretare la tecnologia.
Se il bootstrap del compilatore che poi ricompila se stesso cominciasse seriamente a considerare il programmatore un potenziale criminale sicuramente i bugs verrebbero come minimo decimati
Per questo la gente va dietro alla blockchain, alle cryptovalute e alla singolarità nella IA.
Non mi sento di concludere in modo affrettato in quanto è la prima volta che possiamo testare sul campo l'idea della blockchain, non è sempre facile trovare banchi di test di queste dimensioni e con questi numeri, non che sia ecologicamente economica ed immagino che prima o poi il consenso chiedera il conto ...
Non esistono software senza bug.
Ma si puo aspirare a ridurli al minimo ma oggi come hai ben chiarito ci troviamo con gli estremismi, cattedrali intere di software buggato nella nostra vita e nessuno che risponde di questo scempio come se fosse dovuto e scontato, ma non è affatto cosi. La mia lavatrice me lo ricorda ogni giorno e l'ho pagata taaanto!!! Luca p.s. e se gia dal liceo si insegnasse agli studenti a programmare software affidabile per ambienti critici invece che pagine web e app per l'iphone?
Il giorno mer 17 ott 2018 alle ore 22:38 Luca Cappelletti <luca.cappelletti@gmail.com> ha scritto:
Il 13/10/18 23:34, Giacomo Tesio ha scritto:
Il giorno sab 13 ott 2018 alle ore 18:36 Luca Cappelletti <luca.cappelletti@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.
considero un LegalTech all stregua di un software in ambienti critici ad alta integrita
Ok, in teoria sono d'accordo. Ma stiamo parlando di software LegalTech immaginari. I software LegalTech reali sono software enterprise. 1.000 euro a riga quando viene? Con il nostro PIL quanti ne riusciamo a scrivere/aggiornare? Arriviamo al 1% del codice civile? :-D
Intuisco la questione ma non ne ho un'idea ben precisa in quanto uso OpenBSD che di mestiere elimina codice (che quindi in futuro non puo rompersi in quanto non c'è)
Parli con uno che ha rimosso oltre un milione di venerabili righe di codice da Plan 9... :-D E per quanto apprezzi il lavoro di OpenBSD anche il loro codice ha bug. La differenza con organizzazioni come Mozilla è l'onestà intellettuale di risolverli senza cercare scuse.
a parte gli scherzi aggiungo una vecchia lettura sempre valida: http://static1.1.sqspcdn.com/static/f/702523/9277880/1288929538453/200512-Cr...
Rilancio: http://quotes.cat-v.org/programming/ :-)
Se consideriamo i possibili effetti negativi di un errore allora penso che l'approccio dovrebbe essere asintoticamente verso un firmware di un sistema critico per la salute umana. Come ad esempio i software scritti in Spark per i pacemaker.
Anche se sviluppassimo tutto il software rilevante legalmente in Spark (tipo Facebook, il browser, il mail server e il sistema operativo) ci sarebbero comunque bug. Pochi, ma ci sarebbero comunque. E probabilmente più gravi e meno riproducibili. Perché la cosa divertente dei bug è che a contarli, come fanno molti profani, si prendono delle cantonate enormi. Non ricordo chi osservava tempo fa che i programmatori più esperti introducono più bug. Questo perché di solito lavorano su progetti nettamente più complessi. Io però (in condizioni di lavoro normali) introduco relativamente pochi bug nel mio software. Ma un mio bug in media costa settimane per essere riprodotto ed identificato (e spesso minuti per essere corretto...). Quando calcoli la probabilità di un bug non dici nulla sulla sua gravità. Il problema non può essere risolto tecnologicamente, quanto meno con gli strumenti attuali. Per cui siamo costretti a riflettere su come gestire i bug (che ripeto sono inevitabili) a livello legale.
Il fatto che molti non ne abbiano coscienza deve farci riflettere. Mancano totalmente gli strumenti culturali per interpretare la tecnologia.
Se il bootstrap del compilatore che poi ricompila se stesso cominciasse seriamente a considerare il programmatore un potenziale criminale sicuramente i bugs verrebbero come minimo decimati
Forse. Eliminati no. E poi si porrebbe un problema interessante: in un libero mercato quale compilatore verrebbe usato di più? Quello che fa quello che il programmatore vuole o quello che fa quello che il programmatore del compilatore ritiene che sia appropriato per il programmatore volere? La risposta la abbiamo già, bella lampante: Haskell/Rust/Idris vs JavaScript.
Per questo la gente va dietro alla blockchain, alle cryptovalute e alla singolarità nella IA.
Non mi sento di concludere in modo affrettato...
Conosco la blockchain dal 2009. Il mio non è un giudizio affrettato. ;-)
Non esistono software senza bug.
Ma si puo aspirare a ridurli al minimo ma oggi come hai ben chiarito ci troviamo con gli estremismi, cattedrali intere di software buggato nella nostra vita e nessuno che risponde di questo scempio come se fosse dovuto e scontato, ma non è affatto cosi. La mia lavatrice me lo ricorda ogni giorno e l'ho pagata taaanto!!!
Assolutamente d'accordo. Purtroppo le persone sono abituate a dare questi mal funzionamenti per scontati. Quello che intendevo far notare ai giuristi / politici all'ascolto è che anche se sono fortemente condizionati a non vederli, devono tenerne in conto. Visto che qualunque software che un giudice utilizzi a supporto della propria decisione HA bachi di varia gravità che nessuno conosce, come garantiamo agli imputati che ne vengano danneggiati il diritto ad un "giusto processo"? Il bug è un errore oggettivo, osservabile e correggibile. Ma può invalidare una condanna in terzo grado? Se la risposta è sì, bisogna stabilire come e come risarcire il condannato e chi debba risarcirlo (lo stato o l'azienda produttrice del software?). Se la risposta è no, bisogna eliminare dal processo tale software.
p.s. e se gia dal liceo si insegnasse agli studenti a programmare software affidabile per ambienti critici invece che pagine web e app per l'iphone?
Io non avrei obbiezioni. Ma... e se alle elementari si insegnassero concetti e tecniche come la cryptografia e le reti? Io spero quest'anno di avere la possibilità di fare qualche esperimento in proposito con la classe di mia figlia (5° elementare). Il mio piano è insegnargli in modo giocoso - crittografia seria: one time pad - reti: topologie, protocolli, routing, firewall etc.. - sistemi: filesystem (e forse db relazionali, ma per quanto sia facile da insegnare ad un bimbo temo sia un po' noioso) processi, parallelismo e concorrenza - algoritmi Il tutto senza toccare un computer, ma dando loro i riferimenti per approfondire. Purtroppo aspetto la benedizione della scuola... e ho un po' paura che emerga qualche odiosa sciocchezza burocratica. Giacomo
participants (5)
-
Amedeo Santosuosso -
Giacomo Tesio -
Luca Cappelletti -
Vaciago, Giuseppe -
Vincenzo Mario Bruno Giorgino