August 2020 - nexa - server-nexa.polito.it

Who’s been editing the Ripple CEO’s Wikipedia page?

by Giacomo Tesio

Ripple is a cutting-edge Silicon Valley tech start-up with ambitions to one day be “to payments as Amazon was to books”. [...] Spanish bank Santander, a Ripple investor and what the company calls “one of our largest and most important customers”, recently chose not to use Ripple’s XRP currency for its new international payment network. [...] ..it’s come to FT Alphaville’s attention recently that some Wikipedia users — two in particular — have been repeatedly editing Ripple CEO Brad Garlinghouse’s Wikipedia page to remove some less positive aspects of the entry. Specifically, these two users have been removing text under the “Controversies” section of the page, and one of them in fact removed the whole section entirely, before it was reinstated by a different Wikipedia editor. The Controversies section includes the fact that Garlinghouse had claimed multiple times that the published error rate for SWIFT messaging was at least six per cent (a claim that has been proven to be false in a great piece by Martin Walker published by the London School of Economics Business Review); the fact that he’d been personally named in a group of class actions against Ripple that claim the company has breached various securities laws; and the fact he’d admitted that, without sales of the XRP cryptocurrency, Ripple would be lossmaking [...] # Crypto propaganda wars So there’s been something of an “edit war” on the page, with multiple removals and reinstatements of text since May. [...] Continua su https://ftalphaville.ft.com/2020/08/20/1597909956000/Who-s-been-editing-the… o su https://technocodex.com/whos-been-editing-the-ripple-ceos-wikipedia-page/ La questione è interessante non tanto per le manomissioni di Wikipedia a fini propagandistici (piuttosto consueti nel mondo politico in prossimità delle elezioni) ma perché Ripple è spesso citato come esempio di blockchain "enterprise", addirittura uno strumento b2b per banche, un esempio "virtuoso" a riprova della serietà della fuffa blockchain. Giacomo

Aug. 24, 2020

Re: [nexa] ARM

by Giacomo Tesio

Davvero molto interessante e condivisibile, Giuseppe. Ho solo un dubbio: la soluzione che auspicavi precedentemente (una cordata di imprenditori europei che acquistassero ARM) mi sembra molto più stabile, per gli interessi degli europei ed in termini geopolitici di affidarla al governo UK. E d'altro canto... sarebbe tanto scandaloso se la ARM diventasse un'agenzia pubblica europea? So che si tratta di tutt'altra faccenda (e di persone di tutt'altro calibro), ma dopo Alitalia, le cordate di "capitani coraggiosi" mi lasciano sempre un po'... scettico. Non ho idea l'Unione Europea disponga degli degli strumenti giuridici per acquistare e "unionizzare" ("nazionalizzare" non sarebbe termine appropriato in questo caso) un'azienda tanto strategica, ma di solito una volontà politica chiara crea gli strumenti per attuarsi. Cosa ne pensi? Giacomo

Aug. 24, 2020

Re: [nexa] sulla falsificazione di identità digitale (was Re: Sulla sicurezza del voto elettronico: Come sono riuscito a votare due volte su Rousseau)

by Giovanni Biscuolo

Stefano Zacchiroli <zack(a)upsilon.cc> writes: [...] >> Non voglio sminuire la portata di questo problema, tuttavia voglio >> sottolineare che si tratta di problemi tecnici (non architetturali) >> *seri* dovuti sostanzialmente al fatto che il software SKS è abandonware >> da tempo [1]. > > Non capisco perché tu dica questo. Perché è quello che ho capito studiando il probelma, ma potrei aver capito male ovviamente [...] > Ma l'origine del problema qui non è in SKS, ma nel protocollo OpenPGP. > La situazione contestuale di SKS ha impedito di applicare a quella rete > un workaround. Che è stato invece implementato su *un* (altro) > keyserver, che è diventato un nuovo single point of failure della > distribuzione delle chiavi GPG. Questo per me è un altro sintomo del > fallimento del sogno di avere una PKI completamente decentralizzata. Diciamo che si tratta di stabilire se fallisce peggio una PKI completamente centralizzata rispetto a una decentralizzata con sistema di distribuzione chiavi federato > Ma capisco il tuo punto più sotto che: > >> Ma intendi creazione delle coppie o distribuzione? >> >> Se intendi creazione, non è certo quello che succede con il sistema >> semi-centralizzato di distribuzione delle chiavi pubbliche dei propri >> membri che effettua Debian, ma probabilmente non ho capito io quello >> che intendi dire. > > Giusto. Nel messaggio precedente non avevo fatto questa distinzione, ma > pensavo principalmente alla distribuzione delle chiavi. OK chiaro. > Concordo che la *creazione* distribuita delle chiavi abbia vantaggi > importanti su quella centralizzata. Ma porta anche problemi di trust > nelle diverse versioni del software che crea le chiavi (immagina una > riedizione del famoso bug di OpenSSL in Debian applicato a GPG). Le > puoi mitigare con approcci a-la reproducible-builds, ma aumenti molto la > complessità diciamo "sociale" di adottare la tecnologia. Diciamo che a livello sociale il problema del trust dei binari va affrontato alrimenti non potremo mai avere confidenza che i nostri sistemi facciano quello che dichiarano, ma per tornare a bimba al problema del trist io direi che con un sistema WoT è tecnicamente fattibile mentre con un sistema di CA è **solo** un atto di fede :-) > Con la creazione centralizzata statale aggiungi un altro single point of > failure (male!), ma potresti ottenere in cambio più scrutiny, > investimenti, migliore manutenzione del software, etc. Anche con un WoT cove le istuzioni partecipino attivamente a sviluppare, gestire e migliorare la tecnilogia che lo implementa; la differenza è che rispetto alla CA chi riceve la coppia certificato/chiave. ovvero il cittadino, non può far altro che fidarsi. > Se stiamo parlando di identità digitali poi opponibili dai cittadino > allo stato e vice-versa è un trade-off che non mi sembrerebbe campato > in aria. (Ovviamente sto pensando qui ad uno Stato competente in > tecnologie digitali...) Io auspico un sistema in cui l'identità digitale sia gestita dai cittadini e "certificata" da un sistema in cui il trust è tecnologicamente (scientificamente?) dimostrabile e non fondato principalmente sulla fiducia in una authority centrale. -- Giovanni Biscuolo

Aug. 24, 2020

Re: [nexa] sulla falsificazione di identità digitale (was Re: Sulla sicurezza del voto elettronico: Come sono riuscito a votare due volte su Rousseau)

by Giacomo Tesio

On August 24, 2020 12:23:45 PM UTC, Stefano Zacchiroli <zack(a)upsilon.cc> wrote: >Ma l'origine del problema qui non è in SKS, ma nel protocollo OpenPGP. Scusa la mia ignoranza, ma pur riguardando la documentazione su https://www.openpgp.org/about/standard/ non mi è chiaro cosa intendi. >Con la creazione centralizzata statale aggiungi un altro single point >of failure Non mi è chiaro cosa intendi. "Lo Stato" è un organizzazione estremamente complessa ed articolata. Se distribuisci identità e chiavi su base geografica, con un HKS per comune (e magari per circoscrizione, nelle città metropolitane) non hai single point of failure. Soprattutto se tali server sono federati e ridondati. Non mi è proprio chiaro cosa intendi. D'altro canto, i key server servono solo per reperire la chiave pubblica (con la firma del comune) la prima volta: chiavi e firme così ottenute possono essere scambiate (quasi) liberamente dai cittadini successivamente, un po' come numeri di telefono fra amici. Dunque anche localmente, il point of failure non implicherebbe un interruzione delle comunicazioni. > ma potresti ottenere in cambio più scrutiny, >investimenti, migliore manutenzione del software, etc. Se stiamo >parlando di identità digitali poi opponibili dai cittadino allo stato e >vice-versa è un trade-off che non mi sembrerebbe campato in aria. >(Ovviamente sto pensando qui ad uno Stato competente in tecnologie >digitali...) Ovviamente. C'è molto lavoro da fare, ma chi ben comincia... ;-) Giacomo

Aug. 24, 2020

Re: [nexa] sulla falsificazione di identità digitale (was Re: Sulla sicurezza del voto elettronico: Come sono riuscito a votare due volte su Rousseau)

by Stefano Zacchiroli

On Mon, Aug 24, 2020 at 01:14:16PM +0200, Giovanni Biscuolo wrote: > Non sono d'accordo nel considerare i server di ricerca e distribuzione > delle chiavi infrastruttura cardine, però è certo un servizio molto > importante. Fair enough. > Da quello che ho letto in giro mi sento di dire che la miglior analisi > (e sunto) di quello che è successo con gli attacchi di "poisoning" dei > certificati OpenPGP è quella di Robert J. Hansen > https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f > > Non voglio sminuire la portata di questo problema, tuttavia voglio > sottolineare che si tratta di problemi tecnici (non architetturali) > *seri* dovuti sostanzialmente al fatto che il software SKS è abandonware > da tempo [1]. Non capisco perché tu dica questo. Certo, SKS è software non mantenuto che era diventato (suo malgrado) infrastruttura importante del WoT. E certamente più funding (e scelte di implementazione diverse) avrebbe aiutato. Ma l'origine del problema qui non è in SKS, ma nel protocollo OpenPGP. La situazione contestuale di SKS ha impedito di applicare a quella rete un workaround. Che è stato invece implementato su *un* (altro) keyserver, che è diventato un nuovo single point of failure della distribuzione delle chiavi GPG. Questo per me è un altro sintomo del fallimento del sogno di avere una PKI completamente decentralizzata. Ma capisco il tuo punto più sotto che: > Ma intendi creazione delle coppie o distribuzione? > > Se intendi creazione, non è certo quello che succede con il sistema > semi-centralizzato di distribuzione delle chiavi pubbliche dei propri > membri che effettua Debian, ma probabilmente non ho capito io quello > che intendi dire. Giusto. Nel messaggio precedente non avevo fatto questa distinzione, ma pensavo principalmente alla distribuzione delle chiavi. Concordo che la *creazione* distribuita delle chiavi abbia vantaggi importanti su quella centralizzata. Ma porta anche problemi di trust nelle diverse versioni del software che crea le chiavi (immagina una riedizione del famoso bug di OpenSSL in Debian applicato a GPG). Le puoi mitigare con approcci a-la reproducible-builds, ma aumenti molto la complessità diciamo "sociale" di adottare la tecnologia. Con la creazione centralizzata statale aggiungi un altro single point of failure (male!), ma potresti ottenere in cambio più scrutiny, investimenti, migliore manutenzione del software, etc. Se stiamo parlando di identità digitali poi opponibili dai cittadino allo stato e vice-versa è un trade-off che non mi sembrerebbe campato in aria. (Ovviamente sto pensando qui ad uno Stato competente in tecnologie digitali...) Ciao -- Stefano Zacchiroli . zack(a)upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »

Aug. 24, 2020

Re: [nexa] sulla falsificazione di identità digitale (was Re: Sulla sicurezza del voto elettronico: Come sono riuscito a votare due volte su Rousseau)

by Giacomo Tesio

On August 24, 2020 11:14:16 AM UTC, Giovanni Biscuolo <giovanni(a)biscuolo.net> wrote: > >1. chiarisco che non era mia intenzione sostenere che OpenPGP è esente >da problemi tecnici Tuttavia, affidando la verifica dell'identità e la firma delle chiavi pubbliche all'anagrafe, tutti i problemi classici dei keyserver SKS (bug a parte) spariscono. Per esempio cancellazione ed aggiornamento delle chiavi potrebbe essere gestita in modo molto semplice. >2. ritengo (concordando con altri più bravi di me) che i problemi >architetturali delle PKI basate su CA siano insanabili Ma infatti non credo che Stefano Zacchiroli, suggerisse l'introduzione di una CA di Stato (come invece ipotizzava Stefano Quintarelli). Semplicemente, se ho capito bene (Stefano, correggimi pure se ho frainteso), ritiene che lo Stato non debba occuparsi di infrastrutture informatiche come questa e debba lasciar fare al mercato. Cosa che, nel 2020, equivale lasciare al mercato la progettazione e la manutenzione di strade statali, provinciali, comunali, ponti, gallerie... O meglio: significa lasciar fare ad altri Stati tramite le aziende che proteggono e sovvenzionano in vario modo. Giacomo

Aug. 24, 2020

Re: [nexa] sulla falsificazione di identità digitale (was Re: Sulla sicurezza del voto elettronico: Come sono riuscito a votare due volte su Rousseau)

by Giovanni Biscuolo

Ciao Stefano, Stefano Zacchiroli <zack(a)upsilon.cc> writes: > On Sun, Aug 23, 2020 at 11:53:52AM +0200, Giovanni Biscuolo wrote: >> Sull'uso di S/MIME piuttosto che OpenPGP ho già detto: questioni >> prettamente di FILOSOFIA della burocrazia, che però hanno anche >> importanti ripercussioni fattuali: infatti la PKI dei certificati >> X.509 è architetturalmente BACATA [1] e troppo facilmente >> compromessibile. [2] Ho lasciato la citazione sopra per due motivi: 1. chiarisco che non era mia intenzione sostenere che OpenPGP è esente da problemi tecnici 2. ritengo (concordando con altri più bravi di me) che i problemi architetturali delle PKI basate su CA siano insanabili [...] > Sono sempre stato un grande sostenitore del Web of Trust (WoT), in > particolare come alternativa a soluzioni di PKI più centralizzate. Ma > ricordi qui che, ad oggi, l'infrastruttura cardine del Web of Trust per > OpenPGP, ovvero i key server SKS, Non sono d'accordo nel considerare i server di ricerca e distribuzione delle chiavi infrastruttura cardine, però è certo un servizio molto importante. > risulta compromessa/inutilizzabile a causa degli attacchi di > certificate flooding (c.f. https://lwn.net/Articles/792366/ ; ci sono > probabilmente riferimenti più recenti sul tema, ma non li avevo sotto > mano) Da quello che ho letto in giro mi sento di dire che la miglior analisi (e sunto) di quello che è successo con gli attacchi di "poisoning" dei certificati OpenPGP è quella di Robert J. Hansen https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f Non voglio sminuire la portata di questo problema, tuttavia voglio sottolineare che si tratta di problemi tecnici (non architetturali) *seri* dovuti sostanzialmente al fatto che il software SKS è abandonware da tempo [1]. La soluzione che la community ha *rapidissimamente* adottato per uscire dal "SKS bug" è stata quella di adottare https://keys.openpgp.org/ che, in circa tre mesi dal suo lancio, è diventato il keyserver (non distribuito e non federato) di riferimento per molti progetti, tra cui Debian. Questo keyserver è tutt'altro che perfetto ma almeno risolve i problemi che c'erano con la rete SKS. Forse, dico *forse*, avere avuto l'attenzione delle istituzioni e qualche risorsa in più (non solo in termini finanziari) avrebbe consentito di creare un'infrastruttura di distribuzione delle chiavi OpenPGP ancora migliore. > contro i quali non esiste una vera soluzione a cause di scelte fatte > in OpenPGP (scelte che avevano un senso decadi fa, ma che purtroppo si > sono rivelata liabilities nella internet di oggi). Questo vale praticamente per quasi tutti i protocolli della internet di oggi, per questo va rifatta :-D [...] > Ci sono proposte di alternative ai key server per WoT, ma ad oggi mi > risulta che abbiano un'adozione molto ma molto limitata. https://keys.openpgp.org/ è una alternativa a SKS molto utilizzata > Prima di consigliare quindi oggi un'adozione massiva di WoT veramente > distribuito a livello di uno Stato ci penserei quindi molte molte > volte. Ci ho pensato molte molte volte e mi permetto di insistere :-) : i sistemi basati su WoT sono architetturalmente superiori a quelli basati sulle CA, al netto dei problemi tecnici (che hanno anche i software usati nell'ecosistema X.509)… non c'è proprio partita :-D > Una soluzione ibrida a-la Debian sarebbe certamente fattibile. Ma a quel > punto non si capisce bene quale sarebbe il vantaggio rispetto ad una PKI > centralizzata, con chiavi/certificati distribuiti direttamente dallo > Stato. Ma intendi creazione delle coppie o distribuzione? Se intendi creazione, non è certo quello che succede con il sistema semi-centralizzato di distribuzione delle chiavi pubbliche dei propri membri che effettua Debian, ma probabilmente non ho capito io quello che intendi dire. Semplificando un pochino, il problema architetturale con le CA è esattamente quello che la creazione della coppia chiave/certificato viene effettuata dalla CA e la verifica lato client si fonda sulla fiducia che **la catena** di firma del certificato ricevuto non sia stata compromessa. Dulcis in fundo, come tu sai l'architettura basata su CA non prevede nemmeno un sistema di *distribuzione* dei certificati, tanto che tali certificati sono distribuiti sotto forma di pacchetti da installare localmente (e aggiornare quando vengono aggiornati); Debian, per esempio, li distribuisce nel pacchetto ca-certificates [2] che nella descrizione dice: --8<---------------cut here---------------start------------->8--- Contiene le autorità di certificazione fornite con il browser di Mozilla che permettono alle applicazioni basate su SSL di verificare l'autenticità delle connessioni SSL. Notare che Debian non può né confermare né negare che sia stata in alcun modo verificata l'affidabilità o la conformità con la RFC 3647 delle autorità di certificazione, i cui certificati sono inclusi in questo pacchetto. La responsabilità di verificarle ricade completamente sull'amministratore del sistema locale. --8<---------------cut here---------------end--------------->8--- Le stesse CA sono utilizzate anche da S/MIME per le email. Questo sostanzialmente vale per ogni sistema operativo. Non credo che la situazione sarebbe sostanzialmente migliore se ca-certificates fosse distribuito dallo Stato. [...] Ciao, Giovanni. [1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f#why-hasnt… [2] https://packages.debian.org/buster/ca-certificates

Aug. 24, 2020

Re: [nexa] sulla falsificazione di identità digitale (was Re: Sulla sicurezza del voto elettronico: Come sono riuscito a votare due volte su Rousseau)

by Giovanni Biscuolo

Ciao Stefano, Stefano Zacchiroli <zack(a)upsilon.cc> writes: > On Sun, Aug 23, 2020 at 11:53:52AM +0200, Giovanni Biscuolo wrote: >> Sull'uso di S/MIME piuttosto che OpenPGP ho già detto: questioni >> prettamente di FILOSOFIA della burocrazia, che però hanno anche >> importanti ripercussioni fattuali: infatti la PKI dei certificati >> X.509 è architetturalmente BACATA [1] e troppo facilmente >> compromessibile. [2] Ho lasciato la citazione sopra per due motivi: 1. chiarisco che non era mia intenzione sostenere che OpenPGP è esente da problemi tecnici 2. ritengo (concordando con altri più bravi di me) che i problemi architetturali delle PKI basate su CA siano insanabili [...] > Sono sempre stato un grande sostenitore del Web of Trust (WoT), in > particolare come alternativa a soluzioni di PKI più centralizzate. Ma > ricordi qui che, ad oggi, l'infrastruttura cardine del Web of Trust per > OpenPGP, ovvero i key server SKS, Non sono d'accordo nel considerare i server di ricerca e distribuzione delle chiavi infrastruttura cardine, però è certo un servizio molto importante. > risulta compromessa/inutilizzabile a causa degli attacchi di > certificate flooding (c.f. https://lwn.net/Articles/792366/ ; ci sono > probabilmente riferimenti più recenti sul tema, ma non li avevo sotto > mano) Da quello che ho letto in giro mi sento di dire che la miglior analisi (e sunto) di quello che è successo con gli attacchi di "poisoning" dei certificati OpenPGP è quella di Robert J. Hansen https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f Non voglio sminuire la portata di questo problema, tuttavia voglio sottolineare che si tratta di problemi tecnici (non architetturali) *seri* dovuti sostanzialmente al fatto che il software SKS è abandonware da tempo [1]. La soluzione che la community ha *rapidissimamente* adottato per uscire dal "SKS bug" è stata quella di adottare https://keys.openpgp.org/ che, in circa tre mesi dal suo lancio, è diventato il keyserver (non distribuito e non federato) di riferimento per molti progetti, tra cui Debian. Questo keyserver è tutt'altro che perfetto ma almeno risolve i problemi che c'erano con la rete SKS. Forse, dico *forse*, avere avuto l'attenzione delle istituzioni e qualche risorsa in più (non solo in termini finanziari) avrebbe consentito di creare un'infrastruttura di distribuzione delle chiavi OpenPGP ancora migliore. > contro i quali non esiste una vera soluzione a cause di scelte fatte > in OpenPGP (scelte che avevano un senso decadi fa, ma che purtroppo si > sono rivelata liabilities nella internet di oggi). Questo vale praticamente per quasi tutti i protocolli della internet di oggi, per questo va rifatta :-D [...] > Ci sono proposte di alternative ai key server per WoT, ma ad oggi mi > risulta che abbiano un'adozione molto ma molto limitata. https://keys.openpgp.org/ è una alternativa a SKS molto utilizzata > Prima di consigliare quindi oggi un'adozione massiva di WoT veramente > distribuito a livello di uno Stato ci penserei quindi molte molte > volte. Ci ho pensato molte molte volte e mi permetto di insistere :-) : i sistemi basati su WoT sono architetturalmente superiori a quelli basati sulle CA, al netto dei problemi tecnici (che hanno anche i software usati nell'ecosistema X.509)… non c'è proprio partita :-D > Una soluzione ibrida a-la Debian sarebbe certamente fattibile. Ma a quel > punto non si capisce bene quale sarebbe il vantaggio rispetto ad una PKI > centralizzata, con chiavi/certificati distribuiti direttamente dallo > Stato. Ma intendi creazione delle coppie o distribuzione? Se intendi creazione, non è certo quello che succede con il sistema semi-centralizzato di distribuzione delle chiavi pubbliche dei propri membri che effettua Debian, ma probabilmente non ho capito io quello che intendi dire. Semplificando un pochino, il problema architetturale con le CA è esattamente quello che la creazione della coppia chiave/certificato viene effettuata dalla CA e la verifica lato client si fonda sulla fiducia che **la catena** di firma del certificato ricevuto non sia stata compromessa. Dulcis in fundo, come tu sai l'architettura basata su CA non prevede nemmeno un sistema di *distribuzione* dei certificati, tanto che tali certificati sono distribuiti sotto forma di pacchetti da installare localmente (e aggiornare quando vengono aggiornati); Debian, per esempio, li distribuisce nel pacchetto ca-certificates [2] che nella descrizione dice: --8<---------------cut here---------------start------------->8--- Contiene le autorità di certificazione fornite con il browser di Mozilla che permettono alle applicazioni basate su SSL di verificare l'autenticità delle connessioni SSL. Notare che Debian non può né confermare né negare che sia stata in alcun modo verificata l'affidabilità o la conformità con la RFC 3647 delle autorità di certificazione, i cui certificati sono inclusi in questo pacchetto. La responsabilità di verificarle ricade completamente sull'amministratore del sistema locale. --8<---------------cut here---------------end--------------->8--- Le stesse CA sono utilizzate anche da S/MIME per le email. Questo sostanzialmente vale per ogni sistema operativo. Non credo che la situazione sarebbe sostanzialmente migliore se ca-certificates fosse distribuito dallo Stato. [...] Ciao, Giovanni. [1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f#why-hasnt… [2] https://packages.debian.org/buster/ca-certificates

Aug. 24, 2020

Re: [nexa] Blockchain, the amazing solution for almost nothing - The Correspondent

by Giacomo Tesio

Ormai l'unica cosa che tiene in piedi la blockchain è il timore dei manager e degli sviluppatori coinvolti di perdere la faccia e il lavoro (quando non la libertà). > The fact that no one is in charge and nothing can be modified > also means that mistakes cannot be corrected. A bank can reverse > a payment request. > This is impossible for bitcoin and other cryptocurrencies. Questo comunque non è mai stato vero. Nel 2016, dopo The Dao, Ethereum ha dimostrato a tutti che la blockchain può essere modificata ogni volta che i miner rischiano di perdere il proprio investimento. E questo avrà interessanti implicazioni durante il collasso ormai prossimo. > OK, so with bitcoin, banks can’t just remove money from your account > at their own discretion. But does this really happen? ROTFL! :-D Su Ethereum è successo. E sulle "permissioned blockchain" può succedere by design. > There’s a market for magic, and that market is big In altri termini: la blockchain identifica alcune categorie di truffe che abusano l'ignoranza informatica diffusa (aka credulità popolare). Diffidate di chi vende, propone o sviluppa software basato sulla blockchain: se sa di cosa parla, sta cercando di ingannarvi, in un modo o nell'altro. (ma segnatevi i nomi... perché stanno gia togliendo la blockchain dai CV) Giacomo

Aug. 24, 2020

Re: [nexa] ARM

by Giuseppe Attardi

Dietro mia sollecitazione, Hauser ha scritto questa lettera al Financial Times. ARM, a British company, headquartered in the UK, has provided the design for over 160 billion processors via its 500+ licensees, making it the world’s most valuable IP Company. The proposed sale of ARM to Nvidia the dominant American graphics processor company would have disastrous consequences for Cambridge, the UK and Europe for three main reasons. - Firstly, it will lead to inevitable job losses in Cambridge, where 2500 people are employed, as the HQ will move to Silicon Valley. Nvidia bought the Bristol based company Icera in 2011 and subsequently in 2015 sacked all 300+ UK based staff. - Secondly, it will destroy ARM’s neutrality and even handedness to over 500 hundred licensees all over the world, many of which, including European companies are competitors of Nvidia. - Thirdly, and most seriously it will make ARM a division of an American company to which the US CFIUS regulations apply. This means that the American president can decide which companies ARM is allowed to sell to worldwide. This raises the vital issue of technology sovereignty which the UK and Europe have suffered from for many years. The dominance of Silicon Valley companies in search (Google), social media (Facebook), films (Netflix), e-commerce (Amazon) has become a pressing issue, fostering the belatedly debate on how we could have allowed this dominance to happen. Now we are about to witness one of our last great European technology companies with a dominant position in mobile phones becoming part of the US trade armoury. Whether we are allowed to use our own British designed microprocessors in the UK and Europe will be decided in the White House rather than in Downing Street. This is a major step towards the UK becoming an American vassal state. It must be stopped. A viable alternative to provide the cash to Softbank, ARM’s current owner, is to list ARM on the LSE and make it a UK based company again. If the LSE does not have enough firepower for an estimated $40bn IPO they will be happy to work with the NYSE, Shanghai Star or Euronext. This will be a crucial test of whether the UK government is serious about an industrial strategy. > On 20 Aug 2020, at 12:00, nexa-request(a)server-nexa.polito.it wrote: > > Date: Thu, 20 Aug 2020 11:37:30 +0200 > From: Giuseppe Attardi <attardi(a)di.unipi.it <mailto:attardi@di.unipi.it>> > To: nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> > Subject: [nexa] ARM > Message-ID: <472D9C85-EA5B-498A-884A-BE8CECFCE308(a)di.unipi.it <mailto:472D9C85-EA5B-498A-884A-BE8CECFCE308@di.unipi.it>> > Content-Type: text/plain; charset=utf-8 > > ARM è la società di Cambridge creata da Herman Hauser come spinoff di Acorn. > Quando Acorn venne acquisita da Olivetti, Hauser divenne direttore di ricerca Olivetti e interagii con lui sullo sviluppo di software per ARM, tra cui il port del linguaggio Lisp che comprendeva un innovativo sistema di parallelismo a thread. > Oggi ARM progetta i chip a basso consumo usati nei cellulari ed è stata acquistata dall?investitore giapponese SoftBank, che ora la vuole vendere. > SMT e Samsung producono i chip ARM. > ARM ha anche una divisione che progetta coprocessori GPU da usare per AI. > BTW: 30 anni fa aiutai SMT a realizzare una GPU per cellulari Nokia, evitando che questa si rivolgesse a Texas Instrument, che ne aveva una già pronta. > > ARM è oggi un asset strategico per l?Europa, visto che è l?unica azienda di processori e GPU in grado di competere con Intel, almeno nel settore dei chip a basso consumo. > > All?acquisto di ARM è interessata NVIDIA, la principale ditta che produce GPU per applicazioni sia grafiche tradizionali, che industriali (visione e AI), avendo introdotto la libreria CUDA, che consente di programmare le GPU per svolgere calcoli tensoriali ad alto parallelismo. > Oggi tutta l?AI di punto viene sviluppata su GPU NVIDIA. > > Herman Hauser stesso è contrario all?acquisto di ARM da parte di NVIDIA, che mette a rischio non solo l?esistenza della divisione GPU ma di lasciare agli USA il dominio totale dei processori. > > STM potrebbe essere l?acquirente ideale. > Ho provato a sondare gli attuali dirigenti di STM che conosco, ma mi hanno risposto che l?acquisto non sarebbe possibile per motivi antitrust. > Non mi sembra sia questo il caso: ci sono altri ben agguerriti produttori di chip, ben più monopolisti di una eventuale STM+ARM ed NVIDIA+ARM sarebbe avrebbe un più invadente dominio nel settore dei chip per AI. > > Bisognerebbe promuovere una cordata di grandi imprenditori europei del settore dei chip, comprendente ad esempio Herman Hauser, Federico Faggin, Pasquale Pistorio, che col sostegno dei politici europei, si proponga a per l?acquisto di ARM al fine di farla restare in mani europee. > > ? Beppe >

Aug. 24, 2020