Guasto a Google, così i dati personali di tutti sono gestiti negli Usa
L’azienda ha confermato che le problematiche riscontrate con il loro sistema di autenticazione che ha impedito l’accesso a buona parte dei suoi servizi sono state causate da una configurazione errata di un sistema di storage [...] Guasti tecnici ed attacchi informatici capitano a tutti, anche ai colossi del web come più volte Google, Amazon, Microsoft che in varie occasioni hanno interrotto le giornate lavorative di milioni di utilizzatori o impedito il corretto funzionamento di svariati gadget dipendenti da servizi Cloud. La cosa interessante di questo specifico guasto dell’infrastruttura Google è che ha confermato a coloro che pensavano di utilizzare dei servizi dedicati agli utenti europei, che le credenziali di tutti gli utilizzatori dei loro servizi sono gestite da un’unica piattaforma di autenticazione situata negli Stati Uniti. E questo – come si è visto per i servizi colpiti dal down – riguarda anche le scuole. La documentazione ed i contratti proposti da Google indicano chiaramente che i dati personali “potrebbero” essere trasferiti negli Stati Uniti ma diversi addetti alla privacy, istituzioni come il Ministero dell’Educazione o altre organizzazioni diversamente abili dal punto di vista tecnico ed in materia di protezione dei dati hanno promosso gli strumenti Google, e Microsoft, credendo che i dati ed i servizi sarebbero rimasti in Europa. Vista la sentenza del caso Schrems II che ha invalidato l’accordo chiamato Privacy Shield e confermato la non adeguatezza degli Stati Uniti con le misure minime necessarie alla protezione dei dati personali dei cittadini Europei non sembrano esservi basi legali valide per il trasferimento di quei dati rendendo i contratti firmati con Google, ed altri provider di servizi Cloud, nulli in quanto non conformi con il RGPD. Che i servizi forniti da Google non fossero conformi con il RGPD è chiaro a chiunque abbia letto i loro contratti [...] Malgrado il fatto che Google sia già stata portata in tribunale per aver abusato dei dati degli studenti negli Stati Uniti e condannata diverse volte in Europa per pratiche illegali ed abuso di posizione dominante è a dir poco incredibile che il Ministero dell’Educazione continui a promuovere i loro prodotti come idonei per le scuole. Sarebbe ora auspicabile che il Garante si attivi per informare i cittadini e le istituzioni che i servizi Cloud di Google e di altri fornitori afflitti dalle stesse carenze etiche non sono idonei per l’utilizzo nelle istituzioni Italiane e soprattutto in ambiti educativi dove studenti e spesso, tranne alcuni casi lodevoli, docenti sono stati formati per capire le problematiche relative a quelle piattaforme o a difendere i diritti acquisiti grazie alla Carta dei Diritti Fondamentali dell’Unione Europea che includono il diritto alla privacy. Tratto dall'ottimo articolo di Paolo Vecchi su https://www.agendadigitale.eu/sicurezza/privacy/guasto-a-google-cosi-i-dati-... Giacomo
Caro Giacomo, good catch! ... semmai ci fosse stato bisogno di ulteriori prove che i dati _sono_ esportati ancora negli USA. Giacomo Tesio <giacomo@tesio.it> writes: [...]
Che i servizi forniti da Google non fossero conformi con il RGPD è chiaro a chiunque abbia letto i loro contratti [...]
contrariamente alla notizia del "blackout" di alcuni servizi Google, questa notizia non farà *mai* capolino in un telegiornale o sulle prime pagine dei quotidiani: troppo grossa affiché si "sbatta" in prima pagina. Io ne farei un servizio di almeno 3 minuti ogni sera, dopo le fibrillazioni politiche e gli aggiornamenti sul covid, perché di infopandemia di tratta no?!?... ma io non sono normale :-D. [...] Saluti, Giovanni. -- Giovanni Biscuolo
On Tue, Dec 15, 2020 at 05:57:08PM +0100, Giovanni Biscuolo wrote:
... semmai ci fosse stato bisogno di ulteriori prove che i dati _sono_ esportati ancora negli USA.
Scusate, mi manca un pezzo. Come sappiamo che i server e i dati di auth per gli utenti Google europei non erano in Europa? L'articolo di Paolo mi sembra lo dia per scontato. Io non ho motivi specifici per dubitarne, ma vorrei sapere qual è la fonte di questa informazione. Ce lo ha detto Google? (magari anche indirettamente, ad es. confermando che il problema di quota ieri era su server/dati in USA) -- Stefano Zacchiroli . zack@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 »
On December 15, 2020 5:18:34 PM UTC, Stefano Zacchiroli <zack@upsilon.cc> wrote:
On Tue, Dec 15, 2020 at 05:57:08PM +0100, Giovanni Biscuolo wrote:
... semmai ci fosse stato bisogno di ulteriori prove che i dati _sono_ esportati ancora negli USA.
Scusate, mi manca un pezzo. Come sappiamo che i server e i dati di auth per gli utenti Google europei non erano in Europa?
Semplicemente, il guasto è stato globale. Se è stato un problema di "internal storage" che si è verificato contemporaneamente in tutti i data center Google del pianeta (così come la correzione, applicata 45 minuti dopo) ciò significa che tutti questi storage sono integrati in un unico sistema distribuito. Dove siano fisicamente storati i dati a questo punto diventa irrilevante: quei dati sono accessibili dagli Stati Uniti. Cosa che Google poteva negare prima ed il Garante della Privacy poteva (fingere di) credere. Ora non più. Il blocco globale di Google implica un unico sistema di controllo centralizzato (e dunque di accesso) allo storage distribuito. In sostanza è caduta la maschera. Non si può più fingere che Google Ireland sia indipendente da Google LLC, perché condividono lo stesso storage logico. Mutatis mutandis, è un po' come se condividessero lo stesso disco di rete: il gatto ha staccato il cavo negli USA ed questi hanno dovuto ricollegarlo per tutti. E se anche tutti i dati di tutti gli utenti del mondo fossero tutti storati in Europa, il fatto che siano accessibili agli utenti statunitensi (e dunque ai data center statunitensi) implicherebbe che sono ANCHE accessibili dal Governo USA. In qualunque caso, Google ha reso evidente che opera in violazione del GDPR nonostante la sentenza Shrems II. Complimenti a Paolo per averlo notato. Giacomo
On Tue, Dec 15, 2020 at 07:24:44PM +0100, Giacomo Tesio wrote:
Il blocco globale di Google implica un unico sistema di controllo centralizzato (e dunque di accesso) allo storage distribuito. [...] Non si può più fingere che Google Ireland sia indipendente da Google LLC, perché condividono lo stesso storage logico.
Non sono d'accordo. Il sistema potrebbe essere compartimentato stato per stato (o per "zona", come dicono per il "cloud") e stoccare sia dati che software solo nella zona di riferimento. In un sistema del genere esiste una spiegazione semplice al bug che è stato percepito come "globale": deployment di una stessa versione bacata del software (e/o di una sua configurazione bacata) in ogni zona. Tutto questo non implicherebbe affatto che Google US abbia accesso ai dati degli utenti Google di uno stato europeo, nemmeno ai "soli" dati di AAI (nel senso di Authentication and Authorisation Infrastructure). Un sistema di controllo di accesso basato semplicemente sulla verifica della zona geografica, potrebbe impedire facilmente un tale accesso. E, anche se non è il mio campo, a occhio sarebbe GDPR compliant. Per essere chiari: io come (credo) te penso che Google US *abbia* accesso ai dati europei. E più in generale che non siano GDPR compliant per vari motivi. Ma separiamo i piani: un conto è cosa supponiamo tutti. Un altro il fatto che questo down globale aggiunga evidenza a supporto delle nostre supposizioni. Ciao -- Stefano Zacchiroli . zack@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 »
On Tue, 15 Dec 2020 20:00:34 +0100 Stefano Zacchiroli <zack@upsilon.cc> wrote:
On Tue, Dec 15, 2020 at 07:24:44PM +0100, Giacomo Tesio wrote:
Il blocco globale di Google implica un unico sistema di controllo centralizzato (e dunque di accesso) allo storage distribuito. [...] Non si può più fingere che Google Ireland sia indipendente da Google LLC, perché condividono lo stesso storage logico.
Non sono d'accordo. Il sistema potrebbe essere compartimentato stato per stato (o per "zona", come dicono per il "cloud") e stoccare sia dati che software solo nella zona di riferimento. In un sistema del genere esiste una spiegazione semplice al bug che è stato percepito come "globale": deployment di una stessa versione bacata del software (e/o di una sua configurazione bacata) in ogni zona.
Io infatti ho parlato di sistema unico di controllo E DUNQUE di accesso. Mi spiego meglio. SE Google può, centralmente, diffondere inavvertitamente un bug in tutti i propri data center nel mondo, ALLORA può diffonderlo anche volontariamente, magari su richiesta del Governo USA. Il controllo è SEMPRE accesso. E ieri, per concludere il 2020 in bellezza, Google ha dimostrato a tutta Europa che sta mentendo: i dati dei cittadini europei in mano a Google sono TUTTI accessibili dagli USA.
Tutto questo non implicherebbe affatto che Google US abbia accesso ai dati degli utenti Google di uno stato europeo, nemmeno ai "soli" dati di AAI (nel senso di Authentication and Authorisation Infrastructure).
Su questo è interessante notare che i dati di autenticazione includono (per le scuole) - nome e cognome degli studenti - nome dell'istituto - IP (geolocalizzabile), ora, qualità del collegamento Informazioni assolutamente sensibili e capaci di permettere il tracciamento degli studenti individualmente ed in flotte (classi).
Un sistema di controllo di accesso basato semplicemente sulla verifica della zona geografica, potrebbe impedire facilmente un tale accesso. E, anche se non è il mio campo, a occhio sarebbe GDPR compliant.
Non è necessario. Se ho controllo sul tuo pc e posso aggiornare un software in esecuzione quante volte voglio perché tu non vedi (o non guardi) mi basta aggiornarlo con una versione che mi manda su una connessione cifrata il contenuto del tuo HD e poi riaggiornarlo con una versione pulita. E posso farlo quante volte voglio. Soprattutto se tu lavori per me.
Per essere chiari: io come (credo) te penso che Google US *abbia* accesso ai dati europei. E più in generale che non siano GDPR compliant per vari motivi. Ma separiamo i piani: un conto è cosa supponiamo tutti. Un altro il fatto che questo down globale aggiunga evidenza a supporto delle nostre supposizioni.
Ma certo! Di solito sono io l'avvocato del diavolo, ma devo dire la verità... ti cedo volentieri questo onere! :-D Qualsiasi altra obiezione è benvenuta, ma per quanto ne sappiamo ad oggi, gli Stati Uniti hanno accesso a tutti i dati dei cittadini europei in mano a Google. Giacomo
On Tue, Dec 15, 2020 at 08:22:26PM +0100, Giacomo Tesio wrote:
SE Google può, centralmente, diffondere inavvertitamente un bug in tutti i propri data center nel mondo, ALLORA può diffonderlo anche volontariamente, magari su richiesta del Governo USA. [...] Se ho controllo sul tuo pc e posso aggiornare un software in esecuzione quante volte voglio perché tu non vedi (o non guardi) mi basta aggiornarlo con una versione che mi manda su una connessione cifrata il contenuto del tuo HD e poi riaggiornarlo con una versione pulita.
E posso farlo quante volte voglio. Soprattutto se tu lavori per me.
Certamente, concordo. Ma questo è un rischio geopolitico --- di cui ovviamente l'Europa dovrebbe (pre)occuparsi --- che è un piano completamente diverso da quello legale/privacy. Non mi risulta che GDPR vieti ad una multinazionale di fare deployment di software da data center extra europei a data center europei. Lieto di essere smentito su questo punto da chi ne sa di più di me di GDPR. Ciao -- Stefano Zacchiroli . zack@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 »
è un piano completamente diverso da quello legale/privacy
No, scusami effettivamente dovevo essere più chiaro. Come rilevato dalla sentenza Shrems II, il GDPR vieta a qualunque responsabile europeo del trattamento di dati personali (data controller) di avvalersi di servizi (data processor) che potrebbero esporre tali dati ad una protezione non equivalente a quella garantita dal GDPR. La stessa sentenza ha inoltre affermato chiaramente che il diritto USA non fornisce una protezione equivalente a quella europea (da cui il riconoscimento dell'invalidità del Privacy Shield). Ora, siamo d'accordo che tali dati SONO facilmente accessibili dagli USA ovunque si trovino, perché dagli USA controllano completamente il software che li elabora in tutti i data center di Google. Ne consegue che, ad esempio, i responsabili di tutte le PA, tutte le scuole e tutte le aziende che affidano i dati di cittadini, studenti o dipendenti a Google, stanno violando il GDPR, come data controller. Sennonché alcuni DPO sostengono che la relazione di Google con le scuole non è di data processor (come afferma Google stesso nel Data Processing Agreement), ma di joint controllership. In tal caso, oltre ai Presidi e a tutti gli altri responsabili che non interrompono istantaneamente il trasferimento dati a Google, anche Google sta violando il GDPR. In qualunque caso, se dice che i dati non sono accessibili dalle autorità USA, Google mente.
Non mi risulta che GDPR vieti ad una multinazionale di fare deployment di software da data center extra europei a data center europei.
Assolutamente no! Google può fare quel che vuole! Ma nessuno può affidargli dati di Europei senza violare il GDPR.
questo è un rischio geopolitico --- di cui ovviamente l'Europa dovrebbe (pre)occuparsi
A Bruxelles? Quando? Fra un Bordeaux e l'altro offerto da Google? :-D Giacomo
On Tue, Dec 15, 2020 at 09:49:55PM +0100, Giacomo Tesio wrote:
Come rilevato dalla sentenza Shrems II, il GDPR vieta a qualunque responsabile europeo del trattamento di dati personali (data controller) di avvalersi di servizi (data processor) che potrebbero esporre tali dati ad una protezione non equivalente a quella garantita dal GDPR. [...] Ora, siamo d'accordo che tali dati SONO facilmente accessibili dagli USA ovunque si trovino, perché dagli USA controllano completamente il software che li elabora in tutti i data center di Google.
Concordo sulla tua sintesi di Shrems II, ma c'è un salto enorme tra questi due paragrafi è significativo. Il fatto che i dati siano *potenzialmente* accessibili (highlight mio, perché mi sembra dalle mail precedenti che su questo siamo d'accordo) via, ad esempio, deployment dagli USA di software che possa surrettiziamente esportare dati EU->USA non è condizione sufficiente per essere in violazione di GDPR. Bisogna che tale accesso accada *effettivamente*.[^] Quindi, tornando a bomba al punto di partenza di questo sotto thread (poi mi taccio), non sono al momento a conoscenza di evidenza tecnica che ci dica che da questo down possiamo dedurre che un tale accesso EU->USA sia avvenuto. Ciao [^] E bisogna inoltre che quando ciò accade la protezione garantita negli USA sia inferiore a quella offerta da GDPR in Europa. Ma questa sappiamo benissimo essere una trivialità. -- Stefano Zacchiroli . zack@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 »
On Tue, 15 Dec 2020 22:49:18 +0100 Stefano Zacchiroli <zack@upsilon.cc> wrote:
On Tue, Dec 15, 2020 at 09:49:55PM +0100, Giacomo Tesio wrote:
Come rilevato dalla sentenza Shrems II, il GDPR vieta a qualunque responsabile europeo del trattamento di dati personali (data controller) di avvalersi di servizi (data processor) che potrebbero esporre tali dati ad una protezione non equivalente a quella garantita dal GDPR. [...] Ora, siamo d'accordo che tali dati SONO facilmente accessibili dagli USA ovunque si trovino, perché dagli USA controllano completamente il software che li elabora in tutti i data center di Google.
Concordo sulla tua sintesi di Shrems II
Beh, ad onor del vero, non è farina del mio sacco: https://edpb.europa.eu/sites/edpb/files/consultation/edpb_recommendations_20...
Il fatto che i dati siano *potenzialmente* accessibili (highlight mio, perché mi sembra dalle mail precedenti che su questo siamo d'accordo) via, ad esempio, deployment dagli USA di software che possa surrettiziamente esportare dati EU->USA non è condizione sufficiente per essere in violazione di GDPR.
Bisogna che tale accesso accada *effettivamente*.[^]
Confondi data protection e data breach. Il down non dimostra un data breach, ma l'assenza di una protezione dei dati europei da parte di Google compatibile con il GDPR. E su questo la sentenza Schrems II è molto chiara. Al punto 135 "Where the controller or a processor established in the European Union is not able to take adequate additional measures to guarantee such protection, the controller or processor or, failing that, the competent supervisory authority, are required to suspend or end the transfer of personal data to the third country concerned." E le Raccomandazioni del EDPB che ho citato, alla nota 22 di pagina 8 dicono espressamente: "Please note that remote access by an entity from a third country to data located in the EEA is also considered a transfer." Il tipo di accesso remoto che questo down ha mostrato, evidenzia che non vi è alcuna protezione efficace dei dati dei cittadini europei da parte di Google. Venendo meno tale protezione, viene meno la compatibiltà con il GDPR, sebbene durante questo specifico down non sia stato effettuato un data breach dagli USA.
Quindi, tornando a bomba al punto di partenza di questo sotto thread (poi mi taccio), non sono al momento a conoscenza di evidenza tecnica che ci dica che da questo down possiamo dedurre che un tale accesso EU->USA sia avvenuto.
Non serve. La protezione dei dati consiste nel impedire il data breach, non nello sperare che non avvenga. Se il data breach è tecnicamente e notoriamente possibile (come in questo caso) non c'è alcuna protezione.
[^] E bisogna inoltre che quando ciò accade la protezione garantita negli USA sia inferiore a quella offerta da GDPR in Europa. Ma questa sappiamo benissimo essere una trivialità.
Su questo le FAQ del EDPB sono cristalline: "La Corte ha rilevato che la normativa degli Stati Uniti (Art. 702 della FISA ed EO 12333) non garantisce un livello di protezione sostanzialmente equivalente." https://edpb.europa.eu/sites/edpb/files/files/file1/20200724_edpb_faqoncjeuc... Giacomo
On Wed, 16 Dec 2020 10:18:41 +0100 Stefano Quintarelli <stefano@quintarelli.it> wrote:
On 16/12/2020 10:03, Giacomo Tesio wrote:
Il down non dimostra un data breach, ma l'assenza di una protezione dei dati europei da parte di Google compatibile con il GDPR.
punto di vista interessante. perche' ?
Il disservizio (come il ripristino) è stato globale e contemporaneo. Se si fosse verificato solo in Italia od in momenti diversi in luoghi diversi... o quanto meno se non fosse avvenuto negli USA, questo problema non avrebbe rivelato nulla di nuovo sull'infrastruttura interna di Google. Il fatto che il problema si sia verificato contemporaneamente in tutti i data center implica un controllo centralizzato del sistema di storage distribuito su cui il sistema di Identity and Access Management si basa. Come spiegavo a Stefano, questo significa che Google LLC controlla tutti i data center, controllando il software che gestisce i dati personali, indipendentemente da dove questi siano memorizzati. Può dunque accedere a questi dati da remoto. E' piuttosto ovvio se ci pensi: se posso modificare liberamente il software eseguito su un server, ho accesso a tutti i dati che contiene. Di conseguenza i dati personali dei cittadini europei che lo IAM detiene sono accessibili dagli Stati Uniti. E questo rende la protezione dei dati offerta da Google non equivalente a quella prevista dal GDPR. D'altronde, Paolo mi faceva notare che, in effetti, i contratti di Google dichiarano esplicitamente che tale trasferimento può avvenire. Questo implica che eventuali risarcimenti danni vanno richiesti non a Google, ma ai data controller europei che scelgono di avvalersi dei suoi servizi (i quali possono rivalersi su Google se ritengono). In qualunque caso, quanto avvenuto ieri mostra che tali data processing sono in contrasto con il GDPR e vanno subito interrotti dai data controller o, se questi cincischiano, dall'autorità Garante. Giacomo
Al di là di tutti i tecnicismi e della filosofia. Facendo un discorso terra-terra, se Google o equivalente gigante hi-tech non è adatto come fornitore di un'infrastruttura di servizi per la scuola allora cosa si dovrebbe fare? L'infrastruttura di stato? On Wed, Dec 16, 2020 at 12:40 PM Giacomo Tesio <giacomo@tesio.it> wrote:
On Wed, 16 Dec 2020 10:18:41 +0100 Stefano Quintarelli <stefano@quintarelli.it> wrote:
On 16/12/2020 10:03, Giacomo Tesio wrote:
Il down non dimostra un data breach, ma l'assenza di una protezione dei dati europei da parte di Google compatibile con il GDPR.
punto di vista interessante. perche' ?
Il disservizio (come il ripristino) è stato globale e contemporaneo.
Se si fosse verificato solo in Italia od in momenti diversi in luoghi diversi... o quanto meno se non fosse avvenuto negli USA, questo problema non avrebbe rivelato nulla di nuovo sull'infrastruttura interna di Google.
Il fatto che il problema si sia verificato contemporaneamente in tutti i data center implica un controllo centralizzato del sistema di storage distribuito su cui il sistema di Identity and Access Management si basa.
Come spiegavo a Stefano, questo significa che Google LLC controlla tutti i data center, controllando il software che gestisce i dati personali, indipendentemente da dove questi siano memorizzati.
Può dunque accedere a questi dati da remoto.
E' piuttosto ovvio se ci pensi: se posso modificare liberamente il software eseguito su un server, ho accesso a tutti i dati che contiene.
Di conseguenza i dati personali dei cittadini europei che lo IAM detiene sono accessibili dagli Stati Uniti. E questo rende la protezione dei dati offerta da Google non equivalente a quella prevista dal GDPR.
D'altronde, Paolo mi faceva notare che, in effetti, i contratti di Google dichiarano esplicitamente che tale trasferimento può avvenire.
Questo implica che eventuali risarcimenti danni vanno richiesti non a Google, ma ai data controller europei che scelgono di avvalersi dei suoi servizi (i quali possono rivalersi su Google se ritengono).
In qualunque caso, quanto avvenuto ieri mostra che tali data processing sono in contrasto con il GDPR e vanno subito interrotti dai data controller o, se questi cincischiano, dall'autorità Garante.
Giacomo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- *Ing. Davide Carboni, PhD Partita IVA 03800580924 -- **Albo sez. A (CA) n. 7236* *Via Stresa 5 - 09045 - Quartu Sant'Elena (CA)Tel: +39 3293547783 * Book call on Calendly <https://calendly.com/dcarboni-1/30min> Blog -- http://digitaldavide.me Dagli Smart Contract alle ICO https://bit.ly/2NI3174
La mia personale opinione è che, al di là delle battaglie di bandiera e delle considerazioni di natura legale, non capisco perchè su temi come acciaio, aerospazio, difesa si sia deciso di garantire una capacità tecnologica autonoma a livello nazionale o europeo, invece nel mondo delle tecnologie dell'informazione questa capability non viene evidentemente ritenuta importante. Ovviamente come nel mondo aeronautico una compagnia aerea europea è libera di scegliere tra Airbus, Sukhoi e Boeing, tale libertà di scelta deve poter essere garantita tra Google, AWS e Euro-Cloud (se un giorno esisterà mai). In altre parole, una cosa è dipendere totalmente, un'altra è poter scegliere garantendo una capacità tecnologica autonoma. E la seconda è garantita solo attraverso una politica industriale coerente. Giorgio Il 16/12/2020 13:35, Davide Carboni ha scritto:
Al di là di tutti i tecnicismi e della filosofia. Facendo un discorso terra-terra, se Google o equivalente gigante hi-tech non è adatto come fornitore di un'infrastruttura di servizi per la scuola allora cosa si dovrebbe fare? L'infrastruttura di stato?
On Wed, Dec 16, 2020 at 12:40 PM Giacomo Tesio <giacomo@tesio.it <mailto:giacomo@tesio.it>> wrote:
On Wed, 16 Dec 2020 10:18:41 +0100 Stefano Quintarelli <stefano@quintarelli.it <mailto:stefano@quintarelli.it>> wrote:
> On 16/12/2020 10:03, Giacomo Tesio wrote: > > Il down non dimostra un data breach, ma l'assenza di una protezione > > dei dati europei da parte di Google compatibile con il GDPR. > > punto di vista interessante. > perche' ?
Il disservizio (come il ripristino) è stato globale e contemporaneo.
Se si fosse verificato solo in Italia od in momenti diversi in luoghi diversi... o quanto meno se non fosse avvenuto negli USA, questo problema non avrebbe rivelato nulla di nuovo sull'infrastruttura interna di Google.
Il fatto che il problema si sia verificato contemporaneamente in tutti i data center implica un controllo centralizzato del sistema di storage distribuito su cui il sistema di Identity and Access Management si basa.
Come spiegavo a Stefano, questo significa che Google LLC controlla tutti i data center, controllando il software che gestisce i dati personali, indipendentemente da dove questi siano memorizzati.
Può dunque accedere a questi dati da remoto.
E' piuttosto ovvio se ci pensi: se posso modificare liberamente il software eseguito su un server, ho accesso a tutti i dati che contiene.
Di conseguenza i dati personali dei cittadini europei che lo IAM detiene sono accessibili dagli Stati Uniti. E questo rende la protezione dei dati offerta da Google non equivalente a quella prevista dal GDPR.
D'altronde, Paolo mi faceva notare che, in effetti, i contratti di Google dichiarano esplicitamente che tale trasferimento può avvenire.
Questo implica che eventuali risarcimenti danni vanno richiesti non a Google, ma ai data controller europei che scelgono di avvalersi dei suoi servizi (i quali possono rivalersi su Google se ritengono).
In qualunque caso, quanto avvenuto ieri mostra che tali data processing sono in contrasto con il GDPR e vanno subito interrotti dai data controller o, se questi cincischiano, dall'autorità Garante.
Giacomo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa <https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa>
-- *Ing. Davide Carboni, PhD Partita IVA 03800580924 -- **Albo sez. A (CA) n. 7236** Via Stresa 5 - 09045 - Quartu Sant'Elena (CA) Tel: +39 3293547783 * Book call on Calendly <https://calendly.com/dcarboni-1/30min> Blog -- http://digitaldavide.me <http://digitaldavide.me> Dagli Smart Contract alle ICO https://bit.ly/2NI3174 <https://bit.ly/2NI3174>
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- ======================================================================== Prof. Ing. Giorgio Ventre Direttore Dipartimento di Ingegneria Elettrica e Tecnologie dell'Informazione Università degli Studi di Napoli Federico II Via Claudio 21 80125, Napoli, Italy Tel: +39 081 7683908 Fax: +39 081 7683816 Mob: +39 3807679372 E-mail: giorgio@unina.it http://www.dieti.unina.it http://www.developeracademy.unina.it/en/ http://www.docenti.unina.it/giorgio.ventre ======================================================================== -- Questa e-mail è stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus
Bravo, Giorgio! jc On 16/12/20 14:03, Giorgio Ventre wrote:
La mia personale opinione è che, al di là delle battaglie di bandiera e delle considerazioni di natura legale, non capisco perchè su temi come acciaio, aerospazio, difesa si sia deciso di garantire una capacità tecnologica autonoma a livello nazionale o europeo, invece nel mondo delle tecnologie dell'informazione questa capability non viene evidentemente ritenuta importante.
Ovviamente come nel mondo aeronautico una compagnia aerea europea è libera di scegliere tra Airbus, Sukhoi e Boeing, tale libertà di scelta deve poter essere garantita tra Google, AWS e Euro-Cloud (se un giorno esisterà mai).
In altre parole, una cosa è dipendere totalmente, un'altra è poter scegliere garantendo una capacità tecnologica autonoma. E la seconda è garantita solo attraverso una politica industriale coerente.
Giorgio
Il 16/12/2020 13:35, Davide Carboni ha scritto:
Al di là di tutti i tecnicismi e della filosofia. Facendo un discorso terra-terra, se Google o equivalente gigante hi-tech non è adatto come fornitore di un'infrastruttura di servizi per la scuola allora cosa si dovrebbe fare? L'infrastruttura di stato?
On Wed, Dec 16, 2020 at 12:40 PM Giacomo Tesio <giacomo@tesio.it <mailto:giacomo@tesio.it>> wrote:
On Wed, 16 Dec 2020 10:18:41 +0100 Stefano Quintarelli <stefano@quintarelli.it <mailto:stefano@quintarelli.it>> wrote:
> On 16/12/2020 10:03, Giacomo Tesio wrote: > > Il down non dimostra un data breach, ma l'assenza di una protezione > > dei dati europei da parte di Google compatibile con il GDPR. > > punto di vista interessante. > perche' ?
Il disservizio (come il ripristino) è stato globale e contemporaneo.
Se si fosse verificato solo in Italia od in momenti diversi in luoghi diversi... o quanto meno se non fosse avvenuto negli USA, questo problema non avrebbe rivelato nulla di nuovo sull'infrastruttura interna di Google.
Il fatto che il problema si sia verificato contemporaneamente in tutti i data center implica un controllo centralizzato del sistema di storage distribuito su cui il sistema di Identity and Access Management si basa.
Come spiegavo a Stefano, questo significa che Google LLC controlla tutti i data center, controllando il software che gestisce i dati personali, indipendentemente da dove questi siano memorizzati.
Può dunque accedere a questi dati da remoto.
E' piuttosto ovvio se ci pensi: se posso modificare liberamente il software eseguito su un server, ho accesso a tutti i dati che contiene.
Di conseguenza i dati personali dei cittadini europei che lo IAM detiene sono accessibili dagli Stati Uniti. E questo rende la protezione dei dati offerta da Google non equivalente a quella prevista dal GDPR.
D'altronde, Paolo mi faceva notare che, in effetti, i contratti di Google dichiarano esplicitamente che tale trasferimento può avvenire.
Questo implica che eventuali risarcimenti danni vanno richiesti non a Google, ma ai data controller europei che scelgono di avvalersi dei suoi servizi (i quali possono rivalersi su Google se ritengono).
In qualunque caso, quanto avvenuto ieri mostra che tali data processing sono in contrasto con il GDPR e vanno subito interrotti dai data controller o, se questi cincischiano, dall'autorità Garante.
Giacomo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa <https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa>
-- *Ing. Davide Carboni, PhD Partita IVA 03800580924 -- **Albo sez. A (CA) n. 7236** Via Stresa 5 - 09045 - Quartu Sant'Elena (CA) Tel: +39 3293547783 * Book call on Calendly <https://calendly.com/dcarboni-1/30min> Blog -- http://digitaldavide.me <http://digitaldavide.me> Dagli Smart Contract alle ICO https://bit.ly/2NI3174 <https://bit.ly/2NI3174>
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa -- ======================================================================== Prof. Ing. Giorgio Ventre Direttore Dipartimento di Ingegneria Elettrica e Tecnologie dell'Informazione Università degli Studi di Napoli Federico II Via Claudio 21 80125, Napoli, Italy Tel: +39 081 7683908 Fax: +39 081 7683816 Mob: +39 3807679372 E-mail:giorgio@unina.it http://www.dieti.unina.it http://www.developeracademy.unina.it/en/ http://www.docenti.unina.it/giorgio.ventre ========================================================================
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> Mail priva di virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
La risposta europea sulle cloud (si può poi discutere se è veramente un'iniziativa valida) dovrebbe essere Gaia-X https://www.data-infrastructure.eu/GAIAX/Navigation/EN/Home/home.html -- Luca Sent by mobile Il giorno mer 16 dic 2020 alle ore 14:03 Giorgio Ventre <giorgio@unina.it> ha scritto:
La mia personale opinione è che, al di là delle battaglie di bandiera e delle considerazioni di natura legale, non capisco perchè su temi come acciaio, aerospazio, difesa si sia deciso di garantire una capacità tecnologica autonoma a livello nazionale o europeo, invece nel mondo delle tecnologie dell'informazione questa capability non viene evidentemente ritenuta importante.
Ovviamente come nel mondo aeronautico una compagnia aerea europea è libera di scegliere tra Airbus, Sukhoi e Boeing, tale libertà di scelta deve poter essere garantita tra Google, AWS e Euro-Cloud (se un giorno esisterà mai).
In altre parole, una cosa è dipendere totalmente, un'altra è poter scegliere garantendo una capacità tecnologica autonoma. E la seconda è garantita solo attraverso una politica industriale coerente.
Giorgio Il 16/12/2020 13:35, Davide Carboni ha scritto:
Al di là di tutti i tecnicismi e della filosofia. Facendo un discorso terra-terra, se Google o equivalente gigante hi-tech non è adatto come fornitore di un'infrastruttura di servizi per la scuola allora cosa si dovrebbe fare? L'infrastruttura di stato?
On Wed, Dec 16, 2020 at 12:40 PM Giacomo Tesio <giacomo@tesio.it> wrote:
On Wed, 16 Dec 2020 10:18:41 +0100 Stefano Quintarelli <stefano@quintarelli.it> wrote:
On 16/12/2020 10:03, Giacomo Tesio wrote:
Il down non dimostra un data breach, ma l'assenza di una protezione dei dati europei da parte di Google compatibile con il GDPR.
punto di vista interessante. perche' ?
Il disservizio (come il ripristino) è stato globale e contemporaneo.
Se si fosse verificato solo in Italia od in momenti diversi in luoghi diversi... o quanto meno se non fosse avvenuto negli USA, questo problema non avrebbe rivelato nulla di nuovo sull'infrastruttura interna di Google.
Il fatto che il problema si sia verificato contemporaneamente in tutti i data center implica un controllo centralizzato del sistema di storage distribuito su cui il sistema di Identity and Access Management si basa.
Come spiegavo a Stefano, questo significa che Google LLC controlla tutti i data center, controllando il software che gestisce i dati personali, indipendentemente da dove questi siano memorizzati.
Può dunque accedere a questi dati da remoto.
E' piuttosto ovvio se ci pensi: se posso modificare liberamente il software eseguito su un server, ho accesso a tutti i dati che contiene.
Di conseguenza i dati personali dei cittadini europei che lo IAM detiene sono accessibili dagli Stati Uniti. E questo rende la protezione dei dati offerta da Google non equivalente a quella prevista dal GDPR.
D'altronde, Paolo mi faceva notare che, in effetti, i contratti di Google dichiarano esplicitamente che tale trasferimento può avvenire.
Questo implica che eventuali risarcimenti danni vanno richiesti non a Google, ma ai data controller europei che scelgono di avvalersi dei suoi servizi (i quali possono rivalersi su Google se ritengono).
In qualunque caso, quanto avvenuto ieri mostra che tali data processing sono in contrasto con il GDPR e vanno subito interrotti dai data controller o, se questi cincischiano, dall'autorità Garante.
Giacomo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
--
*Ing. Davide Carboni, PhD Partita IVA 03800580924 -- **Albo sez. A (CA) n. 7236*
* Via Stresa 5 - 09045 - Quartu Sant'Elena (CA) Tel: +39 3293547783 * Book call on Calendly <https://calendly.com/dcarboni-1/30min> Blog -- http://digitaldavide.me Dagli Smart Contract alle ICO https://bit.ly/2NI3174
_______________________________________________ nexa mailing listnexa@server-nexa.polito.ithttps://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- ======================================================================== Prof. Ing. Giorgio Ventre Direttore Dipartimento di Ingegneria Elettrica e Tecnologie dell'Informazione Università degli Studi di Napoli Federico II Via Claudio 21 80125, Napoli, Italy Tel: +39 081 7683908 Fax: +39 081 7683816 Mob: +39 3807679372 E-mail: giorgio@unina.ithttp://www.dieti.unina.ithttp://www.developeracademy.unina.it/en/http://www.... ========================================================================
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> Mail priva di virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> <#m_7524508045068708991_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
On Wed, 16 Dec 2020 14:03:33 +0100 Giorgio Ventre <giorgio@unina.it> wrote:
In altre parole, una cosa è dipendere totalmente, un'altra è poter scegliere garantendo una capacità tecnologica autonoma. E la seconda è garantita solo attraverso una politica industriale coerente.
Sono d'accordo se sostituiamo "è garantita solo attraverso" con "necessita anche di". Limitarsi ad un'analisi economica delle dinamiche cibernetiche in corso, significa rinunciare a comprenderle e dunque a poterle influenzare. I soldi servono, è evidente a tutti, ma se anche oggi ci fossero, non sarebbero lontanamente sufficienti per realizzare alternative democratiche alle politiche imperialiste che si scontrano sul territorio europeo. Limitarsi ad una prospettiva economica significa consegnarsi, di nuovo, agli Stati Uniti. Infatti, se ci lasciassimo convincere che
tale libertà di scelta deve poter essere garantita tra Google, AWS e Euro-Cloud (se un giorno esisterà mai)
permetteremmo semplicemnte a Google ed AWS di incrementare prezzi e profitti, approfittando dell'effetto decoy. Questo "soluzionismo economico" è l'altra faccia del "soluzionismo tecnologico" che ammorba le classi dirigenti europee. E l'ho notato, ahimé, anche in alcuni passaggi della conferenza Nexa di qualche giorno fa, laddove alcuni relatori riconducevano i problemi di cui spesso trattiamo ad una mancanza di concorrenza. "Servirebbe più concorrenza", "Basterebbe un po' più di concorrenza"... Se l'Europa vuole avere un ruolo nell'evoluzione cibernetica di questo pianeta, se non vuole subirla, non può limitarsi a sovvenzionare surrogati europei di servizi stranieri. La competizione economica deve essere espressione di alterità di idee. L'Europa ha quindi bisogno di una propria visione dell'informatica. Una visione Democratica e plurale. Avremo voce in capitolo SOLO quando avremo qualcosa di NUOVO da dire. Giacomo
Mi permetto di dire che secondo me hai attribuito al termine "politica industriale" un significato totalmente economico. Quando poi in realtà gli esempi che avevo citato in altri settori sono "figli" di considerazioni più complesse: sicurezza del Paese, affidabilità delle catene di fornitura, permanenza di una autonomia tecnologica... Direi che gli aspetti che tu citi dal mio punto di vista cadono nelle motivazioni che spingono ad adottare una specifica politica industriale rispetto ad un'altra. Ovviamente, con le differenze che la parola politica implica: un governo a connotazione "liberista-conservatrice" potrà definire strategie totalmente differenti da uno più "laburista". Un cordiale saluto Giorgio Il 16/12/2020 15:44, Giacomo Tesio ha scritto:
On Wed, 16 Dec 2020 14:03:33 +0100 Giorgio Ventre <giorgio@unina.it> wrote:
In altre parole, una cosa è dipendere totalmente, un'altra è poter scegliere garantendo una capacità tecnologica autonoma. E la seconda è garantita solo attraverso una politica industriale coerente. Sono d'accordo se sostituiamo "è garantita solo attraverso" con "necessita anche di".
Limitarsi ad un'analisi economica delle dinamiche cibernetiche in corso, significa rinunciare a comprenderle e dunque a poterle influenzare.
I soldi servono, è evidente a tutti, ma se anche oggi ci fossero, non sarebbero lontanamente sufficienti per realizzare alternative democratiche alle politiche imperialiste che si scontrano sul territorio europeo.
Limitarsi ad una prospettiva economica significa consegnarsi, di nuovo, agli Stati Uniti. Infatti, se ci lasciassimo convincere che
tale libertà di scelta deve poter essere garantita tra Google, AWS e Euro-Cloud (se un giorno esisterà mai) permetteremmo semplicemnte a Google ed AWS di incrementare prezzi e profitti, approfittando dell'effetto decoy.
Questo "soluzionismo economico" è l'altra faccia del "soluzionismo tecnologico" che ammorba le classi dirigenti europee.
E l'ho notato, ahimé, anche in alcuni passaggi della conferenza Nexa di qualche giorno fa, laddove alcuni relatori riconducevano i problemi di cui spesso trattiamo ad una mancanza di concorrenza. "Servirebbe più concorrenza", "Basterebbe un po' più di concorrenza"...
Se l'Europa vuole avere un ruolo nell'evoluzione cibernetica di questo pianeta, se non vuole subirla, non può limitarsi a sovvenzionare surrogati europei di servizi stranieri. La competizione economica deve essere espressione di alterità di idee.
L'Europa ha quindi bisogno di una propria visione dell'informatica.
Una visione Democratica e plurale.
Avremo voce in capitolo SOLO quando avremo qualcosa di NUOVO da dire.
Giacomo
-- ======================================================================== Prof. Ing. Giorgio Ventre Direttore Dipartimento di Ingegneria Elettrica e Tecnologie dell'Informazione Università degli Studi di Napoli Federico II Via Claudio 21 80125, Napoli, Italy Tel: +39 081 7683908 Fax: +39 081 7683816 Mob: +39 3807679372 E-mail: giorgio@unina.it http://www.dieti.unina.it http://www.developeracademy.unina.it/en/ http://www.docenti.unina.it/giorgio.ventre ======================================================================== -- Questa e-mail è stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus
On Wed, 16 Dec 2020 16:50:43 +0100 Giorgio Ventre <giorgio@unina.it> wrote:
Mi permetto di dire che secondo me hai attribuito al termine "politica industriale" un significato totalmente economico.
La politica industriale è politica economica.
Quando poi in realtà gli esempi che avevo citato in altri settori sono "figli" di considerazioni più complesse
Indipendentemente dalle intenzioni reali o dichiarate, la politica industriale opera sull'economia. Non dico che non sia utile o financo necessaria, ma non sarebbe sufficiente in questo momento storico. E' politica industriale buttare soldi nella blockchain? Competere sul modello centralizzato del cloud? Creare la nostra industria AdTech? Creare la Netflix italiana? Eppure è il meglio che possiamo aspettarci, fintanto che ci focaliziamo sull'economia e sulle ottimizzazioni di breve periodo (profitto, PIL, market share, occupazione etc...) Una politica industriale non basta. PRIMA, serve una visione politica. Una visione di come vogliamo l'Europa fra 50 anni. E questa visione manca. Né viene ricercata. Ma se partiamo dall'economia, mettiamo il carro davanti ai buoi. Ogni singola volta.
un governo a connotazione "liberista-conservatrice" potrà definire strategie totalmente differenti da uno più "laburista".
... strategie basate su tensioni e analisi economiche novecentesche. Differiscono su come distribuire i profitti, non sull'opportunità di massimizzarli. E' ora di andare avanti. (e siamo andati off-topic :-D) Giacomo
Buongiorno nexiane, Giorgio Ventre <giorgio@unina.it> writes:
Mi permetto di dire che secondo me hai attribuito al termine "politica industriale" un significato totalmente economico.
Il GDPR, argomento dal quale è partito questo thread, è "politica industriale" o "politica dei diritti dei cittadini nel digitale"? La ratio del GDPR è quella di una politica indistriale più efficiente (quindi più concorrenziale secondo la retorica degli anni '90)? La politica industriale è senza dubbio importante ma è _una_ delle politiche di una nazione; molti di noi vorrebbero che la politica di cittadinanza (digitale e non) abbia *il primato* sulla politica industriale ed altre politiche di settore, NON viceversa. Siccome troppo spesso molti diritti dei cittadini sono stati _sacrificati_ in nome di una "Politica Industriale Superiore", permetteteci di accogliere con rispettoso sospetto la proposta di _ridurre_ le politiche sul digitale a politiche industriali. Noi "semplicemente" vorremmo che la politica digitale sia rispettosa dell'intera costituzione italiana e c'è molto da fare _prima_ della politica industriale per come stanno oggi le cose. [...] Cordiali saluti. Giovanni. -- Giovanni Biscuolo
Buongiorno, Stefano Zacchiroli <zack@upsilon.cc> writes: [...]
Il fatto che i dati siano *potenzialmente* accessibili (highlight mio, perché mi sembra dalle mail precedenti che su questo siamo d'accordo) via, ad esempio, deployment dagli USA di software che possa surrettiziamente esportare dati EU->USA non è condizione sufficiente per essere in violazione di GDPR.
Bisogna che tale accesso accada *effettivamente*.[^]
Non sono ancora in grado di sviluppare adeguatamente il discorso ma dopo una rapida lettura delle Recommendations 01/2020 «on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data» del EDPB [1], di cui si è discusso recentemente anche in questa lista, i controller o processor dei dati personali NON se la possono cavare rispondendo «devi dimostrare che tale accesso accada effettivamente»: l'onere della prova è ribaltato, esattamente come con la responsabilità da prodotto ;-) In particolare, l'executive summary specifica bene che occorrono _tutte_ le sei fasi, la _prima_ delle quali è: --8<---------------cut here---------------start------------->8--- As a first step, the EDPB advises you, exporters, to know your transfers. Mapping all transfers of personal data to third countries can be a difficult exercise. Being aware of where the personal data goes is however necessary to ensure that it is afforded an essentially equivalent level of protection wherever it is processed. You must also verify that the data you transfer is adequate, relevant and limited to what is necessary in relation to the purposes for which it is transferred to and processed in the third country. --8<---------------cut here---------------end--------------->8--- Quindi, non siamo "noi" a dover «know your transfer» verso gli USA, che Shrems II ha già chiarito essere decisamente problematici, ma sono i controllers o i processors. Ora che questa attività venga effettivamente svolta e che le autorità preposte al controllo verifichino la sua adeguatezza è seriamente messo in dubbio _esattamente_ dalla storia delle DUE sentenze Shrems: aspettiamo la terza? Dobbiamo rivolgerci alla corte europea _per_ogni_ caso di sospetto trasferimento inadeguato? Nel mio messaggio precedente ho scritto nero su bianco e senza _nessuna_ leggerezza che «gli indizi sono gravi e concordanti», qui aggiungo che sono DUE (almeno?): 1. i contratti dei servizi, Paolo Vecchi scrive: «Che i servizi forniti da Google non fossero conformi con il RGPD è chiaro a chiunque abbia letto i loro contratti». Io prima di leggere questa cosa mi sono chiesto esattamente questo: qual'è il contratto di servizio tra il Ministero dell'Istruzione e Google e Microsoft per l'utilizzo delle loro piattaforme? Mi immaginavo un contratto che imponesse il non trasferimento dei dati negli USA: Paolo Vecchi dice il contrario. 2. il guasto al sistema di auth fa sospettare che la gestione dei dati sia centralizzata Già solo 1. dovrebbe bastare no? Che il 2. sia vero o meno cambia il fatto che ce ne sarebbe già abbastanza per convincere le autorità preposte alla verifica del rispetto del GDPR e avviare un'indagine approfindita? Sono demagogo se dico che a me pare proprio manchi la volontà politica di andare effettivamente fino in fondo con la questione GDPR? ... una sorta di "legal washing": «noi abbiamo emanato delle leggi molto stringenti in materia, non è colpa nostra se *forse* non vengono rispettate, prego rivolgersi alla corte in caso di dubbi». Infine, come ho già detto in altro thread ritengo che le previsioni delle Recommendations 01/2020 di EDPB siano _molto_ solide MA manca totalmente un requisito fondamentale per tutte le questioni serie riguardanti la vita democratica: la trasparenza e _quindi_ il requisito di pubblicazione delle analisi che i processor o i controller svolgono **per ciascuno** dei sei "step" previsti... perché vorrei che chiunque con le adeguate competenze possa dare un'occhiata, in particolare in merito all'adeguatezza delle "misure tecniche" eventualmente applicate nello step quattro.
Quindi, tornando a bomba al punto di partenza di questo sotto thread (poi mi taccio), non sono al momento a conoscenza di evidenza tecnica che ci dica che da questo down possiamo dedurre che un tale accesso EU->USA sia avvenuto.
Visto che ancora non è del tutto chiaro, sarebbe interessante chiedere a Paolo Vecchi quali sono gli elementi tecnici che gli fanno scrivere: --8<---------------cut here---------------start------------->8--- La cosa interessante di questo specifico guasto dell’infrastruttura Google è che ha confermato a coloro che pensavano di utilizzare dei servizi dedicati agli utenti europei, che le credenziali di tutti gli utilizzatori dei loro servizi sono gestite da un’unica piattaforma di autenticazione situata negli Stati Uniti. E questo – come si è visto per i servizi colpiti dal down – riguarda anche le scuole. --8<---------------cut here---------------end--------------->8--- BTW IMHO questo sposta di POCHISSIMO il problema, anche se non fosse vero l'indizio numero 1. è ancora grave. [...] Saluti. Giovanni [1] https://edpb.europa.eu/our-work-tools/public-consultations-art-704/2020/reco... -- Giovanni Biscuolo
Buongiorno, Stefano Zacchiroli <zack@upsilon.cc> writes: [...]
Il fatto che i dati siano *potenzialmente* accessibili (highlight mio, perché mi sembra dalle mail precedenti che su questo siamo d'accordo) via, ad esempio, deployment dagli USA di software che possa surrettiziamente esportare dati EU->USA non è condizione sufficiente per essere in violazione di GDPR.
Bisogna che tale accesso accada *effettivamente*.[^]
Non sono ancora in grado di sviluppare adeguatamente il discorso ma dopo una rapida lettura delle Recommendations 01/2020 «on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data» del EDPB [1], di cui si è discusso recentemente anche in questa lista, i controller o processor dei dati personali NON se la possono cavare rispondendo «devi dimostrare che tale accesso accada effettivamente»: l'onere della prova è ribaltato, esattamente come con la responsabilità da prodotto ;-) In particolare, l'executive summary specifica bene che occorrono _tutte_ le sei fasi, la _prima_ delle quali è: --8<---------------cut here---------------start------------->8--- As a first step, the EDPB advises you, exporters, to know your transfers. Mapping all transfers of personal data to third countries can be a difficult exercise. Being aware of where the personal data goes is however necessary to ensure that it is afforded an essentially equivalent level of protection wherever it is processed. You must also verify that the data you transfer is adequate, relevant and limited to what is necessary in relation to the purposes for which it is transferred to and processed in the third country. --8<---------------cut here---------------end--------------->8--- Quindi, non siamo "noi" a dover «know your transfer» verso gli USA, che Shrems II ha già chiarito essere decisamente problematici, ma sono i controllers o i processors. Ora che questa attività venga effettivamente svolta e che le autorità preposte al controllo verifichino la sua adeguatezza è seriamente messo in dubbio _esattamente_ dalla storia delle DUE sentenze Shrems: aspettiamo la terza? Dobbiamo rivolgerci alla corte europea _per_ogni_ caso di sospetto trasferimento inadeguato? Nel mio messaggio precedente ho scritto nero su bianco e senza _nessuna_ leggerezza che «gli indizi sono gravi e concordanti», qui aggiungo che sono DUE (almeno?): 1. i contratti dei servizi, Paolo Vecchi scrive: «Che i servizi forniti da Google non fossero conformi con il RGPD è chiaro a chiunque abbia letto i loro contratti». Io prima di leggere questa cosa mi sono chiesto esattamente questo: qual'è il contratto di servizio tra il Ministero dell'Istruzione e Google e Microsoft per l'utilizzo delle loro piattaforme? Mi immaginavo un contratto che imponesse il non trasferimento dei dati negli USA: Paolo Vecchi dice il contrario. 2. il guasto al sistema di auth fa sospettare che la gestione dei dati sia centralizzata Già solo 1. dovrebbe bastare no? Che il 2. sia vero o meno cambia il fatto che ce ne sarebbe già abbastanza per convincere le autorità preposte alla verifica del rispetto del GDPR e avviare un'indagine approfindita? Sono demagogo se dico che a me pare proprio manchi la volontà politica di andare effettivamente fino in fondo con la questione GDPR? ... una sorta di "legal washing": «noi abbiamo emanato delle leggi molto stringenti in materia, non è colpa nostra se *forse* non vengono rispettate, prego rivolgersi alla corte in caso di dubbi». Infine, come ho già detto in altro thread ritengo che le previsioni delle Recommendations 01/2020 di EDPB siano _molto_ solide MA manca totalmente un requisito fondamentale per tutte le questioni serie riguardanti la vita democratica: la trasparenza e _quindi_ il requisito di pubblicazione delle analisi che i processor o i controller svolgono **per ciascuno** dei sei "step" previsti... perché vorrei che chiunque con le adeguate competenze possa dare un'occhiata, in particolare in merito all'adeguatezza delle "misure tecniche" eventualmente applicate nello step quattro.
Quindi, tornando a bomba al punto di partenza di questo sotto thread (poi mi taccio), non sono al momento a conoscenza di evidenza tecnica che ci dica che da questo down possiamo dedurre che un tale accesso EU->USA sia avvenuto.
Visto che ancora non è del tutto chiaro, sarebbe interessante chiedere a Paolo Vecchi quali sono gli elementi tecnici che gli fanno scrivere: --8<---------------cut here---------------start------------->8--- La cosa interessante di questo specifico guasto dell’infrastruttura Google è che ha confermato a coloro che pensavano di utilizzare dei servizi dedicati agli utenti europei, che le credenziali di tutti gli utilizzatori dei loro servizi sono gestite da un’unica piattaforma di autenticazione situata negli Stati Uniti. E questo – come si è visto per i servizi colpiti dal down – riguarda anche le scuole. --8<---------------cut here---------------end--------------->8--- BTW IMHO questo sposta di POCHISSIMO il problema, anche se non fosse vero l'indizio numero 1. è ancora grave. [...] Saluti. Giovanni [1] https://edpb.europa.eu/our-work-tools/public-consultations-art-704/2020/reco... -- Giovanni Biscuolo
On Tue, 15 Dec 2020 21:49:55 +0100 Giacomo Tesio <giacomo@tesio.it> wrote:
Non mi risulta che GDPR vieti ad una multinazionale di fare deployment di software da data center extra europei a data center europei.
Assolutamente no!
ERRATA CORRIGE: Paolo mi ha fatto pazientemente notare che la FAQ 11 del EDPB sulla sentenza Schrems II dice espressamente: si tenga presente che anche fornire accesso ai dati da un paese terzo, ad esempio per finalità amministrative, costituisce un trasferimento https://edpb.europa.eu/sites/edpb/files/files/file1/20200724_edpb_faqoncjeuc... Dunque mi sbagliavo: il GDPR vieta espressamente ad una multinazionale di fare deployment di software che acceda a dati di europei da data center extra europei (che non prevedano una protezione equivalente dei dati dei data subject). Scusate. Giacomo
On Thu, Dec 17, 2020 at 01:29:57AM +0100, Giacomo Tesio wrote:
Dunque mi sbagliavo: il GDPR vieta espressamente ad una multinazionale di fare deployment di software che acceda a dati di europei da data center extra europei (che non prevedano una protezione equivalente dei dati dei data subject).
Insisto: secondo me state confondendo la possibilità teorica di fare tale accesso US->EU (o installazione di software che lo faccia) con il fatto che ciò accada. Anche dal passaggio che hai citato a me non pare affatto che il primo scenario sia vietato e che quindi abbiamo nuove "prove" del fatto che Google sia in violazione di GDPR. -- Stefano Zacchiroli . zack@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 »
On Thu, 17 Dec 2020 08:01:21 +0100 Stefano Zacchiroli <zack@upsilon.cc> wrote:
On Thu, Dec 17, 2020 at 01:29:57AM +0100, Giacomo Tesio wrote:
Dunque mi sbagliavo: il GDPR vieta espressamente ad una multinazionale di fare deployment di software che acceda a dati di europei da data center extra europei (che non prevedano una protezione equivalente dei dati dei data subject).
Insisto: secondo me state confondendo la possibilità teorica di fare tale accesso US->EU (o installazione di software che lo faccia) con il fatto che ciò accada. Anche dal passaggio che hai citato a me non pare affatto che il primo scenario sia vietato e che quindi abbiamo nuove "prove" del fatto che Google sia in violazione di GDPR.
Scusami ma non capisco cosa intendi. Siamo d'accordo che il guasto di martedì è stato globale e contemporaneo, così come la sua risoluzione. Questo dimostra un controllo amminstrativo centralizzato della infrastruttura distribuita di storage dello IAM, indipendentemente dalla collocazione fisica dei data center. Ovvero abbiamo una conferma di ciò che qualunque informatico competente già immaginava, semplicemente perché è un approccio tecnicamente logico per un sistema di gestione delle credenziali di di identificazione e dei permessi di accesso. Il guasto non è stato teorico, così come la sua risoluzione. Dunque il controllo dei data center è in capo a Google LLC, che risponde alla legislazione statunitense. Questo tipo di accesso "per manutenzione" costituisce un trasferimento perché fornire accesso ai dati da un paese terzo, ad esempio per finalità amministrative, costituisce un trasferimento https://edpb.europa.eu/sites/edpb/files/files/file1/20200724_edpb_faqoncjeuc... Intendi che utilizzare un proxy automatico (uno script o altro software) per effettuare un trasferimento lo rende legittimo? Per quanto ho capito il GDPR, la sentenza Schrems II e le raccomandazioni del EDPB in merito, no: sarebbe come abrogare il GDPR. E per quanto ho capito, SE il controllo del software nei data-center europei è in mano a Google LLC, ALLORA questo controllo (sottoposto alla legislazione USA) riduce concretamente la protezione dei dati personali degli utenti europei in mano a Google, in modo incompatibile con il GDPR. E visto che tale controllo esite (come evidenziato dal guasto), allora affidare dati di terzi a Google costituisce una violazione del GDPR. Non è l'accesso in sé a ridurre la protezione dei dati cui i cittadini europei hanno diritto: l'accesso in sé costituirebbe un data breach. E' la sistematica possibilità di accesso dagli USA a costituire una violazione del GDPR. Mi sta forse sfuggendo qualcosa di ovvio? Giacomo
On Thu, Dec 17, 2020 at 01:13:17PM +0100, Giacomo Tesio wrote:
Dunque il controllo dei data center è in capo a Google LLC, che risponde alla legislazione statunitense.
Questo tipo di accesso "per manutenzione" costituisce un trasferimento perché
fornire accesso ai dati da un paese terzo, ad esempio per finalità amministrative, costituisce un trasferimento
Non concordo sul tuo passo logico da "controllo dei data center" a "fornire accesso ai dati". Il controllo dei data center implica che Google può accedere ai dati, non che lo abbia fatto in questo caso specifico, fornendo così accesso "ai dati da un paese terzo". Non so più come spiegarlo altrimenti. Facciamo che ci mettiamo d'accordo sul fatto di non essere d'accordo, OK? (Tanto lo sappiamo tutti che verranno comunque colti con le mani nella marmellata prima o poi.) Ciao -- Stefano Zacchiroli . zack@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 »
Permettimi solo di chiarire ciò su cui non siamo d'accordo, perché io sostengo che sono tutti sporchi di marmellata al lampone, mentre tu dici che potrebbero NON aver preso quella di mele!
Il controllo dei data center implica che Google può accedere ai dati
...da un paese terzo, gli USA, con un diritto incompatibile col GDPR. SE può accedere, ALLORA può essere OBBLIGATO AD ACCEDERE, secondo le norme di quel Paese terzo. E questa possibilità è CONDIZIONE NECESSARIA e SUFFICIENTE per non soddisfare i requisiti del GDPR evidenziati dalla sentenza Schrems II. Su questo, se sbaglio, prego davvero i giuristi in lista di correggermi.
non che lo abbia fatto in questo caso specifico, fornendo così accesso "ai dati da un paese terzo".
Sulla falsità di questa implicazione siamo d'accordo da un punto di vista tecnico: il blackdown di Google non dimostra che, durante il blackdown, siano stati trasferiti dati dai data center europei agli USA, solo che tale trasferimento è (ed è sempre stato) possibile in qualsiasi momento (e dunque anche durante il guasto). Da un punto di vista legale però tale implicazione POTREBBE essere vera se l'accesso per ragioni amministrative ai server che contengono i dati costituisce di per sé un trasferimento, anche se mediato da uno script o da altro software. In tal caso, FORSE tale accesso costituirebbe un data breach. Ma questo secondo problema, per me, è assolutamente secondario. La violazione del GDPR dimostrata dal guasto globale è la prima, non questa seconda su cui non sei d'accordo.
Tanto lo sappiamo tutti che verranno comunque colti con le mani nella marmellata prima o poi.
Sì. Qui: https://status.cloud.google.com/incident/zall/20013 :-D Giacomo
Ciao Stefano, scusa se insisto oltre a quanto già fatto da Giacomo ma l'incidente in questione dice molto di più rispetto a quanto _appare_, rileggiamolo assieme... Stefano Zacchiroli <zack@upsilon.cc> writes: [...]
Insisto: secondo me state confondendo la possibilità teorica di fare tale accesso US->EU
Il rapporto di incidente di Google https://status.cloud.google.com/incident/zall/20013 recita testualmente: --8<---------------cut here---------------start------------->8--- Google Cloud Platform and Google Workspace experienced a global outage affecting all services which require Google account authentication for a duration of 50 minutes. The root cause was an issue in our automated quota management system which reduced capacity for Google's central identity management system, causing it to return errors globally. As a result, we couldn’t verify that user requests were authenticated and served errors to our users. --8<---------------cut here---------------end--------------->8--- Il sistema mondiale di gestione delle identità dei servizi "Google Cloud Platform" e "Google Workspace" è *centralizzato* negli USA. C'è scritto «Google's central identity management system» e il centro di Google, quello che accede al sistema di identity management, è negi USA: sbaglio? Qualunque dato sia immagazzinato in quel sistema centralizzato è praticamente certo che si tratta di dati il cui trasferimento è regolato dal GDPR: sbaglio? (domanda retorica, perdonami). Se le due conclusioni sopra non sono errate, ne consegue che il database del sistema di identity management - indipendentemente da dove i dati siano "fisicamente" immagazzinati - è accessibile a Google USA e quindi sottoposto a legislazione USA e di conseguenza in violazione del GDPR secondo quanto emerso da Shrems II: sbaglio? Se il problema fosse stato circoscritto alla EU allora Google - e i data controller e processors che usano i suoi servizi - avrebbero potuto sostenere che dagli USA non hanno accesso a quei dati perché i sistemi sono separati *e* da quello EU non esce uno spillo verso quello USA (due condizioni)... ma è avvenuto _esattamente_ il contrario, Google USA ha indirettamente ammesso di controllare (anche) i dati dei cittadini EU. L'unica cosa che non sappiamo è *esattamente* quali dati sono memorizzati in quel sistema centralizzato di identity management, mi piacerebbe che siano i data controler a dircelo: loro lo DEVONO sapere. Ma questo è secondario. Conoscendo i sistemi di «identity management» come minimo ci sono i dati anagrafici forniti dagli utenti e ho il fondato sospetto ci siano anche quelli relativi agli accessi [1] e probabilmente anche altri dati (tipo indirizzo, telefono, posizioni GPS?!?) che gli utenti forniscono spIntaneamente a Google. Chi lo sa? Mah?!? Ma questo è secondario. [...] Saluti, Giovanni. [1] ATTENZIONE. Il problema legato alla quota (ovvero lo spazio massimo di memorizzazione su disco consentito ad un utente o a un servizio) ha bloccato l'autenticazione, questo significa che durante l'autenticazione il sistema ha bisogno di spazio disco: se non per memorizzare *nuovi* dati sull'account che vuole accedere, a cosa servirebbe quello spazio? -- Giovanni Biscuolo
On Fri, Dec 18, 2020 at 12:57:05PM +0100, Giovanni Biscuolo wrote:
Il sistema mondiale di gestione delle identità dei servizi "Google Cloud Platform" e "Google Workspace" è *centralizzato* negli USA. C'è scritto «Google's central identity management system» e il centro di Google, quello che accede al sistema di identity management, è negi USA: sbaglio?
Dove sia "il" centro in questione non lo so e quel report non lo dice. Ma me ne cale il giusto. Quel sistema "centralizzato" potrebbe benissimo avere delle istanze geograficamente distribuite, ognuna che conserva tutti e soli i dati degli utenti associati a quella zona geografica, ed esporli tutti come un'unica API logica. Che è poi la stessa cosa che ho scritto 10 mail fa... :-) -- Stefano Zacchiroli . zack@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 »
On Fri, 18 Dec 2020 13:07:41 +0100 Stefano Zacchiroli wrote:
Quel sistema "centralizzato" potrebbe benissimo avere delle istanze geograficamente distribuite, ognuna che conserva tutti e soli i dati degli utenti associati a quella zona geografica, ed esporli tutti come un'unica API logica.
Ma vedi che siamo d'accordo? Il guasto di martedì dimostra che Google amministra centralmente un sistema di storage globale accessibile attraverso un'unica API logica. Siamo perfettamente d'accordo su questo! E siamo d'accordo che questo controllo globale permette a Google LLC di accedere ai dati dei cittadini europei ovunque si trovino. Dal punto di vista tecnico siamo perfettamente d'accordo. Paolo ha semplicemente notato che, come scriveva Giovanni,
ne consegue che il database del sistema di identity management - indipendentemente da dove i dati siano "fisicamente" immagazzinati - è accessibile a Google USA e quindi sottoposto a legislazione USA e di conseguenza in violazione del GDPR secondo quanto emerso da Schrems II
La violazione del GDPR che questo guasto dimostra NON consiste in uno specifico trasferimento dati non autorizzato (un data breach), ma nell'impossibilità tecnica da parte di Google di garantire ai cittadini europei il livello di data protection prevista dal GDPR. Tutto qui. Niente di più e niente di meno. Giacomo
Stefano Zacchiroli <zack@upsilon.cc> writes:
On Tue, Dec 15, 2020 at 05:57:08PM +0100, Giovanni Biscuolo wrote:
... semmai ci fosse stato bisogno di ulteriori prove che i dati _sono_ esportati ancora negli USA.
Scusate, mi manca un pezzo. Come sappiamo che i server e i dati di auth per gli utenti Google europei non erano in Europa? L'articolo di Paolo mi sembra lo dia per scontato. Io non ho motivi specifici per dubitarne, ma vorrei sapere qual è la fonte di questa informazione. Ce lo ha detto Google? (magari anche indirettamente, ad es. confermando che il problema di quota ieri era su server/dati in USA)
Ma a 'sto punto, considerato che gli indizi sono gravi e concordanti (due su tre per fare una prova, manca il "precisi"), una bella commissione d'inchiesta del parlamento EU con tanto di ispettori e periti di parte che "mettano il naso" nei data centre dei fornitori di "cloud" multinazionali con sede in USA non sarebbe opportuna? ...così ci togliamo il dubbio :-D [...] Saluti, Giovanni -- Giovanni Biscuolo
On Tue, Dec 15, 2020 at 08:01:33PM +0100, Giovanni Biscuolo wrote:
Ma a 'sto punto, considerato che gli indizi sono gravi e concordanti (due su tre per fare una prova, manca il "precisi"), una bella commissione d'inchiesta del parlamento EU con tanto di ispettori e periti di parte che "mettano il naso" nei data centre dei fornitori di "cloud" multinazionali con sede in USA non sarebbe opportuna?
...così ci togliamo il dubbio :-D
Non ho idea di quale sarebbe lo strumento giuridico giusto, ma sul principio politico con me sfondi una porta aperta :-) -- Stefano Zacchiroli . zack@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 »
io al fatto che Google abbia un *single point of failure *faccio fatica a credere, e in questa vicenda non ci vedo chiaro non fatico affatto invece a credere che i dati se li possa portare dove gli pare: chi potrebbe controllare che non lo facciano? d'altra parte il fatto che Google mi profili in Irlanda o in California che differenza fa? l'evidenza più rilevante prodotta dal Grande Guasto di Google è che le infrastrutture vitali per la nostra economia sono in mano sua (e di pochi altri, *in primis* Amazon) l'approccio regolamenta-e-sanziona che mi sembra tipico della EU credo sia insufficiente per cambiare questo stato di cose non ho ancora letto il digital services act, ma spero di trovarvi misure concrete per favorire 'in positivo' un processo di decentralizzazione Guido On Tue, 15 Dec 2020 at 17:57, Giovanni Biscuolo <giovanni@biscuolo.net> wrote:
Caro Giacomo,
good catch!
... semmai ci fosse stato bisogno di ulteriori prove che i dati _sono_ esportati ancora negli USA.
Giacomo Tesio <giacomo@tesio.it> writes:
[...]
Che i servizi forniti da Google non fossero conformi con il RGPD è chiaro a chiunque abbia letto i loro contratti [...]
contrariamente alla notizia del "blackout" di alcuni servizi Google, questa notizia non farà *mai* capolino in un telegiornale o sulle prime pagine dei quotidiani: troppo grossa affiché si "sbatta" in prima pagina.
Io ne farei un servizio di almeno 3 minuti ogni sera, dopo le fibrillazioni politiche e gli aggiornamenti sul covid, perché di infopandemia di tratta no?!?... ma io non sono normale :-D.
[...]
Saluti, Giovanni.
-- Giovanni Biscuolo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
participants (10)
-
Davide Carboni -
Giacomo Tesio -
Giorgio Ventre -
Giovanni Biscuolo -
Guido Vetere -
J.C. DE MARTIN -
Luca Cicchelli -
Marco Ciurcina -
Stefano Quintarelli -
Stefano Zacchiroli