October 2020 - nexa - server-nexa.polito.it

un cloud pubblico per scuola e università

by Enrico Nardelli

https://www.key4biz.it/cloud-perche-serve-uninfrastruttura-digitale-pubblic… (con molte grazie a Beppe Attardi per stimoli e contributi) -- EN ===================================================================== Prof. Enrico Nardelli Dipartimento di Matematica - Universita' di Roma "Tor Vergata" Via della Ricerca Scientifica snc - 00133 Roma tel: +39 06 7259.4204 fax: +39 06 7259.4699 mobile: +39 335 590.2331 e-mail: nardelli(a)mat.uniroma2.it home page: http://www.mat.uniroma2.it/~nardelli blog: http://www.ilfattoquotidiano.it/blog/enardelli/ http://link-and-think.blogspot.it/ ===================================================================== --

Oct. 24, 2020

Re: [nexa] Libreoffice e verifica validità della firma elettronica: una jungla?

by Giovanni Biscuolo

Ciao, ci tengo a un'ultima precisazione. Roberto Resoli <roberto(a)resolutions.it> writes: [...] >> Quello che si può fare è già molto, soprattutto considerando che (da >> quello che capisco) questo risultato è stato ottenuto senza la benché >> minima collaborazione da parte della "mano pubblica". > > Non direi, visto che, almeno per j4sign, è frutto del lavoro di un > dipendente pubblico e il rilascio è stata una decisione politica. Hai ragione, ho parlato a vanvera e me ne scuso con tutti i decisori politici che sostengono convintamente il lavoro sul e per il software libero e per una sana digitalizzazione della PA. Coraggio! [...] Grazie, Giovanni. -- Giovanni Biscuolo

Oct. 24, 2020

Re: [nexa] Apple gave the FBI access to the iCloud account of a protester accused of setting police cars on fire

by Giovanni Biscuolo

Buongiorno nexiane, non so assolutamente nulla di iCloud ma... Executive summary: per ottenere la cifratura end-to-end vera, soprattutto quando uno degli "end" è il server di qualcun altro, non basta fare tre swipe e quattro click e *tantomeno* fidarsi delle "brochures" dei fornitori. Silvio Colloca <colloca(a)gmail.com> writes: > Provo a dare il mio piccolo contributo: leggendo quanto indicato da > Apple in merito alla sua cifratura, mi viene in mente l’ipotesi che il > soggetto in questione non avesse abilitato l’autenticazione a due > fattori. Grazie mille, mi stavo giusto chiedendo dove Apple dichiara come viene effettuata la cifratura e il documento che indichi lo riassume benissimo, mi permetto di riportare le informazioni salienti a favore di discussione: > https://support.apple.com/it-it/HT202303 --8<---------------cut here---------------start------------->8--- iCloud protegge le tue informazioni codificandole quando sono in transito, archiviandole in formato codificato e usando token sicuri per l'autenticazione. Per alcune informazioni sensibili, Apple usa la codifica end-to-end [...] Per la codifica end-to-end è necessario che l'autenticazione a due fattori sia attivata per l'ID Apple. --8<---------------cut here---------------end--------------->8--- Se non interpreto male la tabella riportata in quella pagina (che qui ometto) *pare* che molti dati - foto, note, messaggi, ecc) siano crittografati anche sul server ovvero "on rest", tranne l'email (occorrerebbe un server IMAP "speciale"). Una menzione a parte la merita la voce "backup": mi pare di capire si riferisca ai dati delle funzioni elencate in "Codifica end-to-end" (transazioni Apple Card, dati app Casa, dati sanitari, ecc.). Attenzione che la codifica "on rest" implica (non sempre, ma qui sì) che la chiave di crittazione deve essere memorizzata da qualche parte e di solito quella chiave è pure protetta da password; nel caso iCloud la pagina dice questo: --8<---------------cut here---------------start------------->8--- Usare token sicuri per l'autenticazione Quando accedi ai servizi di iCloud con le app integrate di Apple (ad esempio, Mail, Contatti e Calendario su iOS o macOS), l'autenticazione viene gestita tramite un token sicuro. I token sicuri eliminano la necessità di archiviare la password di iCloud sui dispositivi e i computer. --8<---------------cut here---------------end--------------->8--- Non ho capito nulla: qualche utente iCloud che usa questa funzione saprebbe rispiegarmi come funziona lo "sblocco" del backup cifrato? Mi sarei anche documentato meglio ma la "Guida sicurezza in iOS" citata nella pagina https://www.apple.com/it/business/docs/iOS_Security_Guide.pdf mi da un bel "documento non trovato" :-O > Silvio > > >> Il giorno 23 ott 2020, alle ore 11:41, Gianni <ceramicola(a)gmail.com> ha scritto: >> >> >> Buongiorno Giacomo, >> >> è uno spunto di riflessione interessante, ma non mi risulta che Apple >> abbia mai dichiarato di cifrare i contenuti presenti su iCloud e >> specificatamente i backup dei dispositivi La pagina segnalata da Silvio parla chiaro: molti dati su iCloud sono cifrati end-to-end *e* dalla tabella fornita io _mi_aspetto_ che lo siano foto, contatti, calendari, note, promemoria, messaggi, Drive... A meno che Apple stia giocando con la frase "Per alcune informazioni sensibili, Apple usa la codifica end-to-end". Mi sfugge qualcosa? >> o di fornire solo i >> metadati: sul sito Apple è possibile trovare varie informazioni in >> proposito oltre a un c.d. Report sulla trasparenza. Questo: https://www.apple.com/legal/transparency/ >> Il sito dice chiaramente, tra le altre cose: “Account requests may >> also seek customers’ content data, such as photos, email, iOS device >> backups, contacts or calendars”. Sì ma mica dice che c'è qualcuno che è in grado di accedervi se sono cifrate. Certo resta un certo livello di ambiguità. >> È ad esempio relativamente noto che un’app come whatsapp, che offre >> la cifratura end to end per la sua messaggistica, salvi poi nel >> backup su iCloud i dati in chiaro, purtroppo (lato privacy) questa >> non è una informazione compresa dai più, dato che normalmente si >> pubblicizza la cifratura e non i suoi limiti. Già, questo un articolo del 2016 che *pare* essere ancora attuale: https://www.eff.org/deeplinks/2016/10/where-whatsapp-went-wrong-effs-four-b… wazzupp in che categoria rientrerebbe quindi, nei "Messaggi in Cloud" o in altro? [...] >> Per concludere, è notizia di pochi mesi fa il mancato passaggio di >> Apple alla cifratura dei backup, pare (ma sono chiaramente solo voci) >> per pressioni esterne da parte della politica e delle forze di >> polizia e intelligence statunitensi. Sono voci abbastanza informate: https://www.reuters.com/article/us-apple-fbi-icloud-exclusive/exclusive-app… --8<---------------cut here---------------start------------->8--- Apple Inc AAPL.O dropped plans to let iPhone users fully encrypt backups of their devices in the company's iCloud service after the FBI complained that the move would harm investigations, six sources familiar with the matter told Reuters. --8<---------------cut here---------------end--------------->8--- Non è più un mistero (è documentato dai leaks di Snowden) che NSA e Five-Eyes da anni fanno di tutto per sabotare i sistemi - compresi gli algoritmi - di crittpografia: https://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-intern… >> Si conferma ancora una volta che se si vogliono mantenere i propri >> dati riservati è assolutamente preferibile conservarli in locale e >> non caricarli su server di proprietà di terzi. Io sono un assoluto sostenitore del "local first", ma se usati cum granu salis molti servizi che funzionano su server di altri possono essere sufficientemente sicuri [1]. Esistono servizi e sistemi di backup in grado di crittografare i dati "on rest" anche su spazio disco remoto, in modo assolutamente sicuro. Faccio tre esempi tra quelli che conosco: 1. Backup: Borgbackup https://www.borgbackup.org/ 2. Cloud: Nextcloud (c'è la possibilità di attivare la e2e encryption) 3. IMAP: Dovecot con mail_crypt_plugin (https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/) Venendo a bomba al backup degli smartphone, purtroppo la cosa è assai (artatamente) complicata e la maggior parte degli utenti sono costretti ad affidarsi ai tool forniti dal produttori, che in genere rendono la vita facile ma la sicurezza compromessa gravemente. Non no nulla di backup con iOS (per parlare di sicurezza dovremmo parlare anche di sicurezza - e fiducia - di un sistema operativo, ma non qui) ma su Android con un pochino di sforzo si può ottenere il backup (e il sync di un po' di dati, tipo calendari e contatti) con un discreto livello di sicurezza, anche remoto. Saluti, Giovanni. [...] [1] la sicurezza dei sistemi è una cosa molto complessa, gli addetti ai lavori sanno quanto possa essere compromettente avere accesso fisico alla macchina, per non parlare avere accesso a un server virtualizzato (VPS). -- Giovanni Biscuolo

Oct. 24, 2020

Re: [nexa] youtube-dl DMCA takedown

by Roberto Resoli

Il 23 ottobre 2020 23:16:50 CEST, Stefano Quintarelli <stefano(a)quintarelli.it> ha scritto: >non c'e' drm in YT.. Quindi l'unica differenza è l'interfaccia ... rob

Oct. 24, 2020

Re: [nexa] youtube-dl DMCA takedown

by Stefano Quintarelli

non c'e' drm in YT.. On 23/10/2020 22:35, Giacomo Tesio wrote: > Dear Sir or Madam: > > I am contacting you on behalf of the Recording Industry Association of > America, Inc. (RIAA) and its member record companies. The RIAA is a > trade association whose member companies create, manufacture or > distribute sound recordings representing approximately eighty-five (85) > percent of all legitimate recorded music consumption in the United > States. Under penalty of perjury, we submit that the RIAA is authorized > to act on behalf of its member companies on matters involving the > infringement of their sound recordings, audiovisual works and images, > including enforcing their copyrights and common law rights on the > Internet. > > Copyright Violations. We have learned that your service is hosting the > youtube-dl source code on its network at the following locations, among > others: > > https://github.com/ytdl-org/youtube-dl > https://github.com/ytdl-org/youtube-dl/tree/gh-pages > http://ytdl-org.github.io/youtube-dl/ > [...] > > The above list includes a representative sample of the youtube-dl forks > of the youtube-dl source code being hosted on GitHub. Based on our > review of the representative sample noted above, we have a good faith > belief that most of the youtube-dl forks are infringing to the same > extent as the parent repository. > > The clear purpose of this source code is to (i) circumvent the > technological protection measures used by authorized streaming services > such as YouTube, and (ii) reproduce and distribute music videos and > sound recordings owned by our member companies without authorization > for such use. We note that the source code is described on GitHub as “a > command-line program to download videos from YouTube.com and a few more > sites.” > > Continua su > https://github.com/github/dmca/blob/master/2020/10/2020-10-23-RIAA.md > > Il repository principale era > https://github.com/ytdl-org/youtube-dl/ > > Qui un mirror https://gitee.com/mirrors/youtube-downloader > > $ git clone https://gitee.com/mirrors/youtube-downloader.git > > (la ridondanza è una chiave della libertà... ;-) > > Qui invece è possibile scaricare copie del master > https://web.archive.org/web/20201018130325/https://codeload.github.com/ytdl… > > https://pypi.org/project/youtube_dl/ > > Comunque, se non ricordo male, youtube-downloader evita accuratamente > di aggirare le protezioni DRM. > > Dunque è un bene che Microsoft abbia prontamente nascosto il repository. > Sia mai che qualcuno inizi a porsi qualche domanda su cosa significhi > dipendere da società statunitensi! > > > Giacomo > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > -- reserve your meeting with me at https://cal.quintarelli.it

Oct. 23, 2020

youtube-dl DMCA takedown

by Giacomo Tesio

Dear Sir or Madam: I am contacting you on behalf of the Recording Industry Association of America, Inc. (RIAA) and its member record companies. The RIAA is a trade association whose member companies create, manufacture or distribute sound recordings representing approximately eighty-five (85) percent of all legitimate recorded music consumption in the United States. Under penalty of perjury, we submit that the RIAA is authorized to act on behalf of its member companies on matters involving the infringement of their sound recordings, audiovisual works and images, including enforcing their copyrights and common law rights on the Internet. Copyright Violations. We have learned that your service is hosting the youtube-dl source code on its network at the following locations, among others: https://github.com/ytdl-org/youtube-dl https://github.com/ytdl-org/youtube-dl/tree/gh-pages http://ytdl-org.github.io/youtube-dl/ [...] The above list includes a representative sample of the youtube-dl forks of the youtube-dl source code being hosted on GitHub. Based on our review of the representative sample noted above, we have a good faith belief that most of the youtube-dl forks are infringing to the same extent as the parent repository. The clear purpose of this source code is to (i) circumvent the technological protection measures used by authorized streaming services such as YouTube, and (ii) reproduce and distribute music videos and sound recordings owned by our member companies without authorization for such use. We note that the source code is described on GitHub as “a command-line program to download videos from YouTube.com and a few more sites.” Continua su https://github.com/github/dmca/blob/master/2020/10/2020-10-23-RIAA.md Il repository principale era https://github.com/ytdl-org/youtube-dl/ Qui un mirror https://gitee.com/mirrors/youtube-downloader $ git clone https://gitee.com/mirrors/youtube-downloader.git (la ridondanza è una chiave della libertà... ;-) Qui invece è possibile scaricare copie del master https://web.archive.org/web/20201018130325/https://codeload.github.com/ytdl… https://pypi.org/project/youtube_dl/ Comunque, se non ricordo male, youtube-downloader evita accuratamente di aggirare le protezioni DRM. Dunque è un bene che Microsoft abbia prontamente nascosto il repository. Sia mai che qualcuno inizi a porsi qualche domanda su cosa significhi dipendere da società statunitensi! Giacomo

Oct. 23, 2020

Ex-Googler Meredith Whittaker on Political Power in Tech, the Flaws of ‘The Social Dilemma,’ and More | by Alex Kantrowitz | Oct, 2020 | OneZero

by J.C. DE MARTIN

https://onezero.medium.com/ex-googler-meredith-whittaker-on-political-power… (Sent from my wireless device; please excuse brevity and typos (if any))

Oct. 23, 2020

Re: [nexa] Libreoffice e verifica validità della firma elettronica: una jungla?

by Roberto Resoli

Il 23/10/20 15:30, Giovanni Biscuolo ha scritto: > Ciao Roberto, > > Roberto Resoli <roberto(a)resolutions.it> writes: > > [...] > >>> Sono esausto. E io faccio il sistemista da anni, per lavoro. >> >> ... sfondi portoni spalancati ... >> :(( > > Sì lo so, siamo in tanti in questa situazione: «Ciao, mi chiamo Giovanni > e faccio uso di software libero da 15 anni; ho provato molte terapie ma > non riesco a smettere...» :-D eh, contro la libertà le terapie sono tante, e per lo più cercano di reprimere i sintomi ... ma una volta infetti c'è poco da fare. > [...] > >> Ah, tra l'altro attualmente è possibile chiedere la e-residenza in >> Estonia, ricevendo la relativa carta d'identità: >> >> https://e-resident.gov.ee/become-an-e-resident/ > > Interessante: ne avevo sentito parlare ma non ho mai approfondito, da > tenere in considerazione. > >> Naturalmente dovresti poi convincere chi riceve il tuo documento che la >> firma fatta con la carta estone è valida (lo è). > > Ah andiamo bene... > > [...] > >> Hai capito bene, ma la normativa astrae dal tipo di canale. Ad esempio >> ci sono soluzioni che remotizzano l'accesso al dispositivo. > > Sì sì, mi è tutto chiarissimo dal punto di vista tecnico e mi è anche > chiarissima l'abberrazione di aver permesso che l'accesso al dispositivo > fosse remotizzato (smaterizliazato). Io mi riferivo più ad un'accesso indiretto ad un dispositivo che è comunque sotto il tuo controllo, come in PCSC Relay[a], che ha un interesse più che altro accademico, oppure per parlare di cose attuali, al recente uso della Carta d'Identità Elettronica come token di autenticazione gestito via NFC dal proprio telefono[b] > La cosa che mi fa letteralmente rotolare dal ridere è che io che > possiedo fisicamente la smartcard _non_ sono in grado di leggere il > certificato per la firma qualificata mentre nel caso di firma remota > quel certificato lo possono leggere tutti quelli che hanno accesso alla > macchina dove è "ospitato": _magari_ mi sbaglio e la faccio troppo > facile ma... diciamo che non sono lontano dall'azzeccarci. Attenzione, il certificato è pubblico per definizione, tu probabilmente pensi alla corrispondente chiave privata, che dovrebbe essere non estraibile dal dispositivo (anche da quello remoto). Si genera lì e rimane lì. Sempre secondo i sacri testi, ovviamente. Cosa succeda in realtà, già con dei dispositivi non inizializzati autonomamente (figuriamoci quelli remoti), non è dato sapere. > [...] > >> Probabilmente sì, anche se credo che nel mondo attuale, invece di >> permetter l'accesso paritario all'hardware, semplicemente si elimini >> l'hardware (vedi firma remota), aumentando enormemente il lock-in. > > Se fosse disponibile solo la firma remota io di certo NON la userei e > sconsiglierei vivamente, in modo professionale e documentato, altri ad > usarla. > > [...] > >>>> Nella normativa tecnica italiana si prescriveva che le chiavi per firma >>>> riportassero nel certificato corrispondente l'attributo KeyUsage marcato >>>> critico con il solo flag "nonRepudiation". Non so se sia ancora così. >>> >>> OK, non ne so abbastanza di X.509... uff >> >> Basta che apri un qualsiasi certificato ssl, anche dal browser, e trovi >> tutto. > > Sì grazie, intendevo dire che non ho studiato abbastanza i flag a > disposizione e la loro semantica. Ma certo, si sta veramente entrando molto nel dettaglio, e volevo solo dare un esempio percorribile da tutti. >>> Per quanto mi riguarda, installare un driver proprietario o l'intero >>> DIKE proprietario non fa differenza > > Ho detto una sciocchezza sull'onda del nervoso che mi è venuto nell'aver > constatato che mi ero illuso di poter fare a meno di driver proprietari: > usare "solo" un piccolo driver proprietario o un'intera applicazione > ovviamente fa differenza. Si, la differenza vera la farebbe il potersi generare le chiavi autonomamente (su un dispositivo certificato, certo) e invocare i servizi del certificatore solo per la firma della chiave pubblica, come si fa da sempre per i server web. Ma viviamo qui e ora ... >> Di fatto ti basta solo la libreria PKCS11, per il resto puoi usare sw >> libero. Questo è il massimo che si possa fare, con il token che hai in >> mano, al momento. > > Quello che si può fare è già molto, soprattutto considerando che (da > quello che capisco) questo risultato è stato ottenuto senza la benché > minima collaborazione da parte della "mano pubblica". Non direi, visto che, almeno per j4sign, è frutto del lavoro di un dipendente pubblico e il rilascio è stata una decisione politica. > Nei limiti delle mie risorse vedrò come riesco a collaborare affinché > firmare digitalmente sia sempre più facile e alla portata di tutti > (nonostante le serie perplessità sull'intero sistema X.509). Perplessità sacrosante. > Grazie ancora! Giovanni A te, rob > [1] è già abbastanza facile anche usando una smartcard, se poi la > _smaterializziamo_ e la rendiamo accessibile tramite internet > allora... ciao! > [a] http://frankmorgner.github.io/vsmartcard/pcsc-relay/README.html [b] https://www.cartaidentita.interno.gov.it/identificazione-digitale/cie-id/

Oct. 23, 2020

Errata Corrige | Presentazione del libro di Antonio A. Casilli "Schiavi del clic - Perchè lavoriamo tutti per il nuovo capitalismo?" | Nuovo Link per partecipare all'incontro

by Nexa Media

Gentilissimi, vi informiamo che il *nuovo link per partecipare all'incontro* dedicato alla presentazione del libro: /*"Schiavi del clic - Perchè lavoriamo tutti per il nuovo capitalismo?"*/ (Antonio A. Casilli, Feltrinelli, Milano, 2020) con ospite/Antonio A. Casilli (Faculty Fellow Centro Nexa) /è/: / https://webinaire.ehess.fr/b/cas-wyq-fqk // Cordiali saluti,   -- Anita Botta Communication Manager Nexa Center for Internet & Society Politecnico di Torino – DAUIN Corso Duca degli Abruzzi, 24 - 10129 Torino _web:_ https://nexa.polito.it/ _mail:_anita.botta@polito.it <mailto:anita.botta@polito.it> tel: 011 090 7219

Oct. 23, 2020

Re: [nexa] Presentazione del libro di Antonio A. Casilli "Schiavi del clic - Perchè lavoriamo tutti per il nuovo capitalismo?" | Nuovo Link per partecipare all'incontro

by Roberto Resoli

Il 23/10/20 16:57, Nexa Media ha scritto: > Gentilissimi, > > > vi informiamo che il nuovo link per partecipare all'incontro dedicato > alla presentazione del libro: > > /*"Schiavi del clic - Perchè lavoriamo tutti per il nuovo > capitalismo?"*/ (Antonio A. Casilli, Feltrinelli, Milano, 2020) > > con ospite/Antonio A. Casilli (Faculty Fellow Centro Nexa) > /è//https://webinaire.ehess.fr/html5client/join?sessionToken=pchqwa6m6vlxxp4 > <https://webinaire.ehess.fr/html5client/join?sessionToken=pchqwa6m6vlxxp4z>/ Attenzione, il link corretto è: https://webinaire.ehess.fr/b/cas-wyq-fqk (Una volta collegati l'url cambia) rob

Oct. 23, 2020