Podcast RSI - Story: Uno scandalo (informatico) molto britannico

5 de Maio de 2023, 5:54, por Il Disinformatico

È disponibile subito il podcast di oggi de Il Disinformatico della Radiotelevisione Svizzera, scritto, montato e condotto dal sottoscritto: lo trovate presso www.rsi.ch/ildisinformatico (link diretto) e qui sotto.

Le puntate del Disinformatico sono ascoltabili anche tramite feed RSS, iTunes, Google Podcasts e Spotify.

Buon ascolto, e se vi interessano il testo di accompagnamento e i link alle fonti di questa puntata, sono qui sotto.

---

[CLIP: Rumore ambientale di ufficio postale UK]

Questa storia inizia nel Regno Unito, nel 1999, anno di sofferenza e di insonnia per tanti informatici, ma non riguarda il famigerato Millennium Bug. 

È l’anno in cui le Poste britanniche iniziano ad installare un nuovo sistema di contabilità informatizzata, denominato Horizon, destinato a gestire i milioni di transazioni che hanno luogo ogni giorno nei numerosissimi uffici postali del paese, che sono un servizio fondamentale per la collettività: come avviene in tanti paesi, i cittadini li usano per fare pagamenti, riscuotere pensioni e fare piccoli acquisti, insomma per muovere quantità notevoli di denaro oltre che per ricevere e spedire corrispondenza.

Il signor Alan Bates è un cosiddetto sub-postmaster: dirige una delle tantissime succursali delle Poste britanniche, quella di Craig-y-Don, nel Galles. Un anno dopo l’introduzione del sistema Horizon, Alan Bates segnala formalmente alle Poste che il sistema ha dei problemi: crea degli ammanchi che in realtà non esistono. Nel frattempo ci sono già state sei condanne di altre persone per frodi registrate dal sistema, ma secondo Bates si tratta invece di errori del software, che è prodotto dalla Fujitsu. Le Poste britanniche negano e nel 2003 rescindono il loro contratto con Alan Bates.

Questo è l’inizio della storia di uno dei più gravi casi di errore giudiziario legato all’informatica di cui si abbia notizia. Durerà oltre vent’anni e porterà a centinaia di condanne ingiuste, con incarcerazioni, diffamazioni, divorzi e suicidi delle persone additate per errore, dal software e dalla giustizia, come ladri e truffatori, ed è un caso esemplare di eccessiva fiducia nell’infallibilità dei computer che va conosciuto per evitare che si ripeta altrove.

Benvenuti alla puntata del 5 maggio 2023 del Disinformatico, il podcast della Radiotelevisione Svizzera dedicato alle notizie e alle storie strane dell’informatica. Io sono Paolo Attivissimo.

[SIGLA di apertura]

Per un computer, fare calcoli con i numeri è una funzione basilare. Niente a che vedere con le complessità delle simulazioni di fisica o dell’intelligenza artificiale. Sembra quindi impossibile, a prima vista, che una grande azienda come Fujitsu e una grande organizzazione come il servizio postale di un paese possano realizzare e implementare un sistema informatico che sbaglia a fare i conti. Eppure è successo, e con un sistema costato un miliardo di sterline dell’epoca, ossia circa 2 miliardi e mezzo di franchi o euro di oggi.

Oltre 700 gestori di filiali delle poste britanniche hanno ricevuto condanne penali per frode contabile e furto, perché il software difettoso di Fujitsu faceva sembrare che togliessero soldi dalla cassa. Migliaia di altri gestori hanno dovuto pagare somme ingenti alle Poste britanniche per coprire gli ammanchi di cui erano accusati. Fra il 2000 e il 2014, le Poste britanniche hanno portato in tribunale 736 di questi gestori: in media un gestore a settimana. Alcuni sono finiti in carcere, addirittura durante la gravidanza, come è successo a Seema Misra, condannata per furto e messa in prigione nel 2010 quando aspettava il secondo figlio, additata dalla stampa locale come “la ladra incinta”, ma completamente scagionata dieci anni dopo. Altri sono finiti sul lastrico e hanno anche dovuto affrontare il disprezzo delle proprie comunità, che li vedevano come persone disoneste che avevano violato la loro fiducia in un ruolo così centrale. Qualcuno, tragicamente, si è tolto la vita.

Nel 2014, a distanza di quindici anni dall’introduzione del software Horizon e cinque anni dopo che un gruppo di questi sub-postmaster che avevano subìto gli errori di Horizon aveva costituito un’associazione per chiedere giustizia, arrivando poi all’attenzione dei media [in particolare ComputerWeekly] e in tribunale, finalmente una perizia tecnica indipendente ha dimostrato che il software sbagliava davvero, e creava davvero ammanchi di cassa inesistenti.

Le Poste britanniche hanno risposto subito che “non esiste assolutamente alcuna prova di problemi sistematici con il sistema informatico” e si sono autoassolte. Il governo britannico, unico azionista delle Poste, si è rifiutato di pagare qualunque risarcimento o indennizzo. Ci sono voluti altri anni, e altre azioni legali costosissime per gli accusati, per arrivare a un risarcimento e all’annullamento di centinaia di condanne infondate.

Nel 2019 la High Court of Justice, l’Alta corte di giustizia britannica, ha confermato che il software era difettoso ed era rimasto tale per ben dieci anni e che questi difetti potevano creare gravi errori contabili. Questa conferma è emersa grazie alla tenace azione legale collettiva condotta contro le Poste britanniche da Alan Bates: la stessa persona che quasi vent’anni prima aveva cercato inutilmente di avvisare del problema. Ma la vicenda, ancora oggi, non si è ancora conclusa.

Con i computer non si discute

La situazione dei gestori accusati di frode era disastrosa. Loro, comuni cittadini, contro una grande e famosa azienda informatica, e soprattutto contro il mito dell’infallibilità dei computer nel fare i conti, che in alcuni paesi è anche un assunto legale:* i tribunali danno per scontato che un computer funzioni perfettamente fino a prova contraria.

* Fonte: Briefing Note: The legal rule that computers are presumed to be operating correctly – unforeseen and unjust consequences in Digital Evidence and Electronic Signature Law Review, Volume 19, pagg. 123–127, ISSN 1756-4611, 2022. DOI 10.14296/deeslr.v19i0.5476.

Era più facile pensare che i singoli gestori avessero prelevato soldi dalla contabilità della loro succursale che immaginare che il costosissimo software contenesse errori di calcolo madornali e strutturali. Le prove informatiche degli ammanchi sembravano talmente schiaccianti che molti consulenti legali consigliavano ai gestori incriminati di dichiararsi colpevoli di frode contabile; in cambio le Poste britanniche avrebbero ritirato l’accusa, ben più grave, di furto.

[CLIP: voce di Steven Murdoch]

Steven Murdoch, professore di Security Engineering e ricercatore presso lo University College London, ha pubblicato un articolo e un video nei quali spiega come è stato possibile questo errore informatico catastrofico, citando esempi tratti dal disastro di Horizon e presentando alcuni concetti che valgono per qualunque grande sistema computerizzato.

Quando un sistema informatico molto grande e distribuito sul territorio deve gestire in modo affidabile tantissimi spostamenti di denaro e poi comunicarli a un archivio generale, questi spostamenti non sono più semplici calcoli del tipo "questa succursale ha venduto sette cartoline e dodici francobolli, quindi in cassa deve essere entrato un importo equivalente". Gli spostamenti diventano transazioni, e queste transazioni devono rispettare quattro criteri, che si chiamano atomicità, coerenza, isolamento e durabilità.

[CLIP: voce di Steven Murdoch che cita l’acronimo di questi criteri, ossia ACID]

Atomicità significa che una transazione non può essere fatta a metà: o viene fatta completamente, oppure no, e deve avvenire una sola volta. Ma il software Horizon spesso creava transazioni duplicate, per cui i soldi risultavano entrati in cassa due volte ma in realtà erano materialmente presenti una volta sola. Alcuni gestori, non riuscendo a capire la causa degli ammanchi in cassa, li ripianavano di tasca propria per evitare guai, ma le grandi cifre in gioco a volte erano incolmabili. Alcuni hanno addirittura ipotecato la casa, e l’hanno persa.

Il secondo criterio, coerenza, significa che i dati della succursale devono essere coerenti con quelli dell’archivio centrale, ma il software Horizon sbagliava creando contraddizioni e incoerenze che facevano sembrare che i gestori avessero commesso delle irregolarità.

E poi c’è l’isolamento: vuol dire che se una transazione fallisce questo non deve avere effetto su altre transazioni e che se due transazioni avvengono contemporaneamente non devono interferire tra loro. Ma se una transazione locale avveniva mentre veniva generato il resoconto periodico della succursale, Horizon “dimenticava” quella transazione, creando errori di cassa.

E infine durabilità, o persistenza, che vuol dire che una volta che una transazione è stata avviata causando un cambiamento di stato, quel cambiamento non deve mai andare perso in nessun caso, neanche con un blackout o un crash del computer locale. Ma Horizon, specialmente quando era sovraccarico, perdeva dati. Per esempio, un cliente veniva autorizzato dal software a prelevare denaro ma poi il prelievo effettuato non veniva registrato. E così in cassa mancavano senza giustificazione i soldi dati al cliente.

In altre parole, realizzare un sistema contabile distribuito con decine di migliaia di succursali non è semplice, ma gli errori che venivano commessi da Horizon erano davvero elementari. Nonostante questo, i tribunali e le Poste britanniche hanno preferito pensare a lungo che si trattasse di un problema di gestori disonesti. Eppure c’era un dato concreto che avrebbe dovuto insospettire i responsabili del software: subito dopo la sua installazione, il numero delle anomalie di cassa era aumentato enormemente. Era improbabile che così tanti gestori fossero diventati di colpo ladri tutti insieme, ma si è preferito dare la colpa a lungo a loro invece che sospettare un errore del computer e del software di Fujitsu.

I log fanno fede, ma non troppo

Il problema di queste situazioni, infatti, è che per il singolo gestore, o per il singolo utente, risulta incredibilmente difficile dimostrare che il software sbaglia: fanno fede infatti i cosiddetti log, ossia i registri delle attività generati dal software stesso.

Gli atti dei vari processi per la vicenda Horizon documentano casi come quello della signora Burke, un’addetta di una succursale postale, che si è accorta un giorno che il prelievo di denaro fatto da un cliente, di cui lei si ricordava, non risultava nei log. La signora è riuscita a rintracciare il cliente, è andata a casa sua e gli ha spiegato l’accaduto. Il cliente per fortuna aveva ancora la ricevuta rilasciatagli dal software al momento del prelievo. Quel prelievo che secondo il software non era mai avvenuto. Se non ci fosse stata quella ricevuta cartacea, i log avrebbero inchiodato la signora, accusandola di aver rubato dalla cassa i soldi prelevati dal cliente.

A dicembre 2019, dopo una lunga serie di azioni legali civili, le Poste britanniche hanno deciso di ammettere i propri errori e di indennizzare ben 555 persone per un totale di 58 milioni di sterline (circa 66 milioni di franchi o euro). Ma i tre quarti di questa cifra non finiranno nei conti delle vittime: serviranno a pagare le loro spese legali. E Fujitsu, intanto, continua a essere fornitore delle Poste britanniche [e anche del governo britannico, addirittura per un servizio d’emergenza].

[Se volete approfondire questa vicenda, la BBC ha una serie di podcast che la raccontano in dettaglio e e moltissimi articoli con testimonianze; qui sotto c’è anche un servizio del Times]

Sarà stata imparata la lezione? Speriamo di sì. Ma nel frattempo stiamo andando sempre più verso sistemi paperless, senza carta, senza scontrini fisici e senza bollette stampate. Viene da chiedersi come finirebbe, oggi, la signora Burke che si è scagionata grazie allo scontrino provvidenzialmente tenuto dal cliente.

E mentre chiudo questo podcast ho davanti a me, sullo schermo, uno screenshot della mia banca, che mi dice che sul mio conto c’è un bonifico uscente di circa 15.000 euro* che avevo ordinato diciassette anni fa**, e che all’epoca era stato eseguito ma che adesso, dopo un cambio del software gestionale della banca, è magicamente ricomparso e ogni giorno, altrettanto magicamente, viene rimandato di un giorno senza che io faccia nulla.

* Il bonifico è espresso in franchi; qui parlo di “circa 15.000 euro” per facilità di comprensione dell’importo da parte del pubblico non svizzero.

** Me lo ricordo perché non faccio molti bonifici di questa entità e soprattutto ricordo il destinatario.

Ho ovviamente già allertato la banca, ma nel frattempo quella transazione fantasma è ancora lì che aleggia. Sto provando a esorcizzarla recitando ripetutamente i mantra atomicità, coerenza, isolamento, durabilità. Speriamo che basti.

(AGG 2023/04/30) Starship, meravigliosi video al rallentatore del primo test di volo; ipotesi esperte su cosa è andato storto e come rimediare

30 de Abril de 2023, 15:50, por Il Disinformatico

Le riprese del fotografo Trevor Mahlmann e della squadra di Everyday Astronaut mostrano con un dettaglio stupefacente le fasi del volo di collaudo della Starship di SpaceX. Il rallentatore consente di notare che le onde di pressione sono talmente intense da diventare visibili nella nube di fiamme e polvere, e le irregolarità e disuniformità della combustione durante l’arrampicata verso il cielo sono chiaramente visibili.

Le posizioni di ripresa consentono anche di apprezzare con grande chiarezza le brusche variazioni di assetto che hanno caratterizzato le fasi finali del volo.

Finora la spiegazione più plausibile del grande numero di motori malfunzionanti è che la mancanza di un sistema di assorbimento delle onde di pressione abbia divelto la superficie in cemento armato sotto il piedistallo di lancio e parte dei detriti risultanti siano stati proiettati lateralmente, come si vede nei video, e abbiano colpito alcuni degli ugelli perimetrali.

Nel frattempo le autorità hanno revocato la licenza di lancio di Starship, come è prassi dopo un lancio terminato con conseguenze inattese non solo per il veicolo ma anche per l’ambiente (la pioggia di detriti).

Starship liftoff in slow motion pic.twitter.com/KqHjqwP88Z

— Elon Musk (@elonmusk) April 22, 2023

Elon Musk ha tweetato che tre mesi fa era iniziata la costruzione di una grande lastra in acciaio raffreddata ad acqua da piazzare sotto il piedistallo di lancio, ma non era pronta in tempo e sulla base dei test di accensione dei motori fatti prima del lancio, a metà potenza, si riteneva che la zona di lancio sarebbe sopravvissuta per almeno una partenza. Non è andata così.

La costruzione di una trincea di deviazione delle fiamme e di assorbimento delle onde di pressione sembra impossibile perché la falda acquifera è vicinissima alla superficie e l’area in cui sorge la base di SpaceX è zona protetta dal punto di vista ambientale (perlomeno secondo i singolari criteri statunitensi che permettono di installare in zona protetta un apparato industriale complesso e incline alle dispersioni incontrollate di materiale come una rampa di lancio di razzi spaziali).

Phil Metzger racconta un caso analogo di rampa di lancio priva di trincea: quella del piccolo veicolo spaziale sperimentale Morpheus, al cui progetto partecipò anni fa. Anche lì furono usate lastre in acciaio, e le analisi indicarono che il calore si sarebbe disperso abbastanza in fretta da evitare la fusione superficiale delle lastre. Secondo lui l’idea di Musk potrebbe funzionare. Metzger scrive anche molti altri dettagli interessanti, anche a proposito del disastro sfiorato del primo volo Shuttle a causa delle onde di pressione. Trascrivo qui le sue parole ma non ho tempo di tradurle al volo: dai commenti mi dicono che ci ha già pensato Marco Zambianchi su Forumastronautico.it.

We used steel plates for some of the Morpheus launch locations so we weren’t tied down to places with concrete. I analyzed the heating of the sheet and showed that the heat would redistribute fast enough that it would not locally melt on the surface, and that the steel plate was large enough to take the heat of the entire launch event without melting. To be conservative (because that’s what nasa does 😉) we also put paint-on ablative on the top of the steel. An ablative erodes under heat and thus uses up some of the heat keeping what was under the ablative cooler. (Partly we were just testing the use of ablative. It wasn’t just conservatism that motivated this.) So compare to Elon’s tweet about Starship. They plan to make their giant steel plate water-cooled. That way it doesn’t have to be large enough to take all the heat of the plume without melting, the way we designed the Morpheus steel plates. For such a large rocket that much steel would be excessive. And ablative would not be enough to solve this, either. Would the ablative need to be 3 feet thick?!!

But he said it will be water-cooled, which is an awesome idea. The water will be taking heat out of the steel in realtime so it won’t melt. Simple, and it should be effective. We still had two concerns. One was that the vaporized ablative was hazardous to breathe, but the rocket exhaust would dilute it into the air so no problem. (I still had to show this with math to convince the team.) The second was that the plate might be too hot to walk on so you had to wait for it to cool before going onto the pad. We handled that with operational procedures.

So we had the steel plates, the steel drop-in flame trench, instrumentation like cameras to record the launch, and lighting. We called this system “Launch Pad in a Box”. This concept was inspired in part when I was driving to Maine and passed a carnival ride folded up on a truck going down the highway. I had a vision of an entire launch complex folded up on a truck for transport so we could launch anywhere, anytime.

We got a picture of the truck and I showed it to the Swamp Works team. I think Rob Mueller was already having the same idea. He and I started fighting to get the idea funded. Meetings, meetings, meetings. And we got the funds. We were already working on these technologies when we applied them to Morpheus. The two projects were synergistic. We also talked about portable lighting arrestor towers but never developed that part of the kit. So all that was just to say that I like the idea SpaceX is pursuing. I think it will work great to solve the plume erosion problem.

It will *not* mitigate launch acoustics. The flat plat will reflect the sound back up along the sides of the vehicle, shaking the structure. There very first “sound” that happens on launch is the shockwave from engine ignition. It bounces off the pad then runs up the sides of the vehicle, stressing everything. At nasa it is called the “Initial OverPressure” or IOP. The IOP almost ruined the 1st Shuttle launch.

The reason there is a shockwave is because a converging-diverging rocket nozzle tricks the gas flow into going supersonic. The fuel burns in the combustion chamber and creates high pressure. The restriction at the throat causes the gas to “choke” at the speed of sound.

On the first Space Shuttle launch the IOP deflected the elevons— the control surfaces on the wings — so far the engineers were worried they could have snapped. So they added the water deluge system to absorb and break up the IOP shockwave.

After the IOP, the rocket exhaust continues to produce acoustic noise. It does this through turbulence. The noise is random — not like a coherent shockwave — but it is still a lot of energy that reflects off the pad and vibrates the rocket.

We do not have great models of acoustic noise production in rocket plumes. NASA’s models are conservative, predicting more noise than there really is. Therefore we build rocket structures stiffer than they really need to be. This wastes the mass margin, reducing payload mass.

So it is important to keep researching rocket plume acoustics to make rockets more efficient. But also, it is important to design launch pads to reduce acoustics so we can save more payload margin.

In the previous thread I told how we designed the portable flame trench for Morpheus to duct the acoustic energy away from the vehicle, because we think that acoustic energy is what destroyed the first Morpheus.

So I have no idea of the acoustics experienced by Starship or it’s structural beefiness. It may not be a problem at all, for all I know. I’m just saying that a flat steel plate does not do anything to reduce acoustic energy from coupling into the vehicle. If the rocket doesn’t mind the shaking, then fine. But it is easy to design systems that reduce launch acoustics and give more margin back to the vehicle, so if SpaceX decided to do so then it could be done.

---

2023/04/30. Astrospace.it riferisce che Elon Musk ha tenuto un intervento riservato agli abbonati al suo profilo su Twitter, nel quale ha detto varie cose (leggete l’articolo di Astrospace per i dettagli e per molte altre informazioni):

• non ci sono conferme che i danni ai motori siano stati causati dall’impatto con detriti;
• la base della rampa verrà rinforzata in acciaio al posto del cemento armato;
• il sistema di autodistruzione (FTS o Flight Termination System) è intervenuto troppo lentamente e andrà ricertificato;
• tre dei 33 motori del primo stadio non sono stati accesi da SpaceX intenzionalmente perché “non erano pronti”;
• l’allontanamento laterale dalla rampa non era voluto ma è stato causato dalla mancanza di tre motori;
• il costo del progetto Starship nel 2023 sarà intorno ai 2 miliardi di dollari.