Personalmente preferisco lineageOS https://lineageos.org/, senza Gapps e installando nanodroid https://forum.xda-developers.com/apps/magisk/module-nanomod-5-0-20170405-microg-t3584928, perchè purtroppo nel settore mobile senza un minimo di google non si va lontani. Tra l'altro lineage supporta molti più dispositivi. Ho parlato con vari devs di microG e nanodroid, loro chiamano /e/ "/e/g/a/y/" e parlano in generale moto male del progetto /e/ e dicono che ha più senso di fare il rooting sul device o installare lineageOS direttamente. Credo che /e/ deve cambiare molto, ribasandosi su una versione di android più moderna (o almeno di lineage), sopratutto acettare feedback negativo. Nessun dispositivo android / arm sarà mai senza blob e o approvato dalla fsf. Ma comunque comprando un nexus è , molto facile installare qualsiasi rom o anche una distribuzione Linux (ubuntu touch, sailfish os, kde mobile). Tra poco (si spera) uscira il pinephone prodotto da pine64 https://www.pine64.org/ e il librem5 https://puri.sm/products/librem-5/. Tra l'altro la librem sta cercando di creare un ecosistema alternativo ai prodotti google (librem.one) a pagamento ma FOSS. Volevo aggiungere su signal, che okay che è completamente OSS, ma ha server (e copyright) nei U.S.A, dipende da google play services e firebase per funzionare corretamente e non viene distribuito da f-droid (btw consiglio di usare aurora droid https://forum.xda-developers.com/android/apps-games/app-aurora-droid-fdroid-client-t3932663 come client per f-droid. (lo stesso dev ha fatto aurora store, un client per google play store a cui si può accedere con credenziali false)).

Il giorno gio 18 lug 2019 alle ore 09:48 Diego Maniacco < diego.maniacco@gmail.com> ha scritto:

Francesco, grazie per il contributo, visto che da tempo sto seguendo questo progetto /e/ e valutando se acquistarmi uno smart (sono ancora fermo ad un [nuovo] Nokia TA-1017 ;) L'intento iniziale di costituire un ecosistema alternativo aperto ma anche economicamente autonomo è lodevole e non banale; la realizzazione ha ancora zone d'ombra. A tuo parere /e/ potrebbe evolvere riscrivendo la parte microG, che pare quella più critica, e magari accettando contributi esterni (che pure sono chiamati)?

Grazie, diego

On Wed, 17 Jul 2019 at 17:37, Franci schenonef2004@gmail.com wrote:

...

Vorrei condividere questo in riguardo a e

https://ewwlo.xyz/evil

Francesco Schenone

-------- Messaggio originale -------- Oggetto: Re: [Lugbz-list] Cerco alternativa a Facebook e Whatsapp Da: Diego Maniacco A: Giulio Roman ,Linux User Group Bolzano-Bozen-Bulsan CC:

Faccio una considerazione al contorno.

Tutti i servizi "social" (Facebook/Whatsapp compresi) mettono a disposizione individualmente uno *spazio di memorizzazione* che difficilmente viene riempito e che pertanto appare come illimitato. A questo vengono aggiunti come frattaglie servizi vari come il backup dei dati, etc. Il tutto senza sborsare moneta; il pagamento tramite l'accesso e la fruizione dei ns. dati da parte del gestore del servizio non viene percepito come tale. Questo approccio deve necessariamente valere per tutti le forniture "gratuite": dietro ad esse ci sono costi elevati che vanno comunque, in qualche modo, pagati.

Rendersi effettivamente indipendenti significa dotarsi di una qualche infrastruttura, anche in cloud, che avrà un costo in moneta ma che potrà essere interamente gestita e controllata. Questa infrastruttura potrà anche essere ampia, ma mai "gratuita" in termini monetari.

Un esempio di un progetto di ecosistema ampio che si vuole contrappone a Google è oggi https://e.foundation/ ; in gestazione da circa 3-2 anni sta finalmente vedendo luce concreta. Vi sono certamente molti aspetti da migliorare ma ciò che non manca è la trasparenza del progetto, sia in termini di codice che finanziari (qui spazio per migliorare). Quantomeno è un inizio differente e concreto ed un progetto nato e sviluppatosi in territorio europeo, cadendo quindi sotto le normative EU e francesi.

Non mi pare di aver dato risposta al tuo quesito, ma spero di aver fornito uno spunto alla discussione.

diego

Diego Maniacco, Bolzano (Italy) diego.maniacco@gmail.com

---

On Tue, 16 Jul 2019 at 23:39, Giulio Roman giulio@roman.bz.it wrote:

...

Ciao a tutti,

Sono membro di una associazione che organizza a Merano un festival musicale di beneficenza ogni anno a ferragosto.

Fino ad ora ci siamo organizzati attraverso un gruppo privato facebook e un gruppo whatsapp.

Forse sono riuscito a mettere la pulce nell'orecchio alle persone giuste e probabilmente discuteremo di migrare a soluzioni piú "etiche" delle due sopracitate.

Whatsapp lo rimpiazzo con Signal, ma facebook?

Sarebbe figo avere un client mobile decente per Diaspora, ma fanno tutti schifo. Nessuno ha le notifiche integrate con quelle native android/iOS.

Oggi ho provato Mastodon, ha un ottimo client mobile - Tusky, ma é un concetto troppo distante da facebook e sarebbe impossibile gestire una migrazione di questo tipo di utenti.

Qualcuno di voi saprebbe indirizzarmi verso qualcosa che permetta la creazione di contenuti discretamente strutturati (post e commenti) con la possibilitá di caricare media (foto e video) che abbia anche un client mobile decente?

Grazie anticipatamente Giulio_______________________________________________ http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list

---

http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list

---

http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list

On 18/07/2019 16:51, Franci wrote:

Personalmente preferisco lineageOS https://lineageos.org/, senza Gapps e installando nanodroid https://forum.xda-developers.com/apps/magisk/module-nanomod-5-0-20170405-microg-t3584928, perchè purtroppo nel settore mobile senza un minimo di google non si va lontani. Tra l'altro lineage supporta molti più dispositivi. Ho parlato con vari devs di microG e nanodroid, loro chiamano /e/ "/e/g/a/y/" e parlano in generale moto male del progetto /e/ e dicono che ha più senso di fare il rooting sul device o installare lineageOS direttamente. Credo che /e/ deve cambiare molto, ribasandosi su una versione di android più moderna (o almeno di lineage), sopratutto acettare feedback negativo. Nessun dispositivo android / arm sarà mai senza blob e o approvato dalla fsf. Ma comunque comprando un nexus è , molto facile installare qualsiasi rom o anche una distribuzione Linux (ubuntu touch, sailfish os, kde mobile). Tra poco (si spera) uscira il pinephone prodotto da pine64 https://www.pine64.org/ e il librem5 https://puri.sm/products/librem-5/. Tra l'altro la librem sta cercando di creare un ecosistema alternativo ai prodotti google (librem.one) a pagamento ma FOSS. Volevo aggiungere su signal, che okay che è completamente OSS, ma ha server (e copyright) nei U.S.A, dipende da google play services e firebase per funzionare corretamente e non viene distribuito da f-droid (btw consiglio di usare aurora droid https://forum.xda-developers.com/android/apps-games/app-aurora-droid-fdroid-client-t3932663 come client per f-droid. (lo stesso dev ha fatto aurora store, un client per google play store a cui si può accedere con credenziali false)).

Ciao Francesco,

correggimi se sbaglio, ma /e/vil e' un OS mobile, non una piattaforma social, giusto?

Inoltre non mi e' chiara una cosa: per Signal che svantaggi vedi nell'avere i server negli USA? Da come ho capito io, la E2E encryption serve proprio per evitare di porsi problemi di chi stia in mezzo ad ascoltare.

Grazie Giulio

/e/ vuole essere un ecosistema, non solo un OS; il tutto è in fase beta. - qui un articolo sull'inizio del progetto che inizialmente si chiamava "eelo" https://www.indidea.org/gael/blog/leaving-apple-google-eelo-odyssey-introduc...

- qui la base del progetto attuale https://e.foundation/ - qui la community https://community.e.foundation/ -- diego

On Fri, 19 Jul 2019 at 11:47, Franci schenonef2004@gmail.com wrote:

Si forse stiamo andando leggermente OT, con /e/, e si è un os mobile. Il problema dei server negli usa, è che le agenzie federali posso chiedere di implementare delle backdoor o di ricevere direttamente le chiavi di crittografazione. Se non lo fanno, viene proibito la distribuzione di quell'applicazione su suolo americano. Nel caso posso anche linkare dei articoli che lo spiegono meglio.

Francesco Schenone

-------- Messaggio originale -------- Oggetto: Re: [Lugbz-list] Ris: Cerco alternativa a Facebook e Whatsapp Da: Giulio Roman A: lugbz-list@lists.lugbz.org CC:

On 18/07/2019 16:51, Franci wrote:

...

Personalmente preferisco lineageOS , senza Gapps e installando nanodroid , perchè purtroppo nel settore mobile senza un minimo di google non si va lontani. Tra l'altro lineage supporta molti più dispositivi. Ho parlato con vari devs di microG e nanodroid, loro chiamano /e/ "/e/g/a/y/" e parlano in generale moto male del progetto /e/ e dicono che ha più senso di fare il rooting sul device o installare lineageOS direttamente. Credo che /e/ deve cambiare molto, ribasandosi su una versione di android più moderna (o almeno di lineage), sopratutto acettare feedback negativo. Nessun dispositivo android / arm sarà mai senza blob e o approvato dalla fsf. Ma comunque comprando un nexus è , molto facile installare qualsiasi rom o anche una distribuzione Linux (ubuntu touch, sailfish os, kde mobile). Tra poco (si spera) uscira il pinephone prodotto da pine64 e il librem5 . Tra l'altro la librem sta cercando di creare un ecosistema alternativo ai prodotti google (librem.one) a pagamento ma FOSS. Volevo aggiungere su signal, che okay che è completamente OSS, ma ha server (e copyright) nei U.S.A, dipende da google play services e firebase per funzionare corretamente e non viene distribuito da f-droid (btw consiglio di usare aurora droid

come client per f-droid. (lo stesso dev ha fatto aurora store, un client per google play store a cui si può accedere con credenziali false)).

Ciao Francesco,

correggimi se sbaglio, ma /e/vil e' un OS mobile, non una piattaforma social, giusto?

Inoltre non mi e' chiara una cosa: per Signal che svantaggi vedi nell'avere i server negli USA? Da come ho capito io, la E2E encryption serve proprio per evitare di porsi problemi di chi stia in mezzo ad ascoltare.

Grazie Giulio

---

http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list

---

http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list

Il punto è il dato lato server, non il tratto end2end, che affronta il caso man-in-the-middle. Concedendo l'accesso al server il provider apre il dato in locale allae autorità usa come se fosse in chiaro. In https://edri.org/microsoft-office-365-banned-from-german-schools-over-privac... si affronta il problema relativamente MS, ma i riferimenti normativi valgono in generale.

On Fri, 19 Jul 2019 at 12:28, Giulio Roman giulio@roman.bz.it wrote:

...

Il problema dei server negli usa, è che le agenzie federali posso chiedere di implementare delle backdoor o di ricevere direttamente le chiavi di crittografazione. Se non lo fanno, viene proibito la distribuzione di quell'applicazione su suolo americano. Nel caso posso anche linkare dei articoli che lo spiegono meglio.

Non sono assolutamente un esperto di sicurezza ma credo che il discorso in questo caso sia marginale. Dato che Signal implementa la crittografia end-to-end, le chiavi private sono essere salvate solo sui singoli device, non sui server.

---

http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list

Giulio, vedi la risposta a seguire inviata da Igor. Aggiungo che chi ha il possesso del server può implementarci quello che gli pare, a maggior ragione se i protocolli usati sono proprietari e se opera senza trasparenza. Se poi si considera che "The newly enacted “US Cloud Act” https://edri.org/cloud-act-letter-uscongress-global-implications/ empowers US government agencies to request access to customer data from all US-based companies no matter where their servers are located." , il discorso necessariamente deve considerare dove risiede il provider del servizio, per capire a quali leggi è soggetto.

diego

On Fri, 19 Jul 2019 at 12:56, Giulio Roman giulio@roman.bz.it wrote:

On 19/07/2019 12:39, Diego Maniacco wrote:

...

Il punto è il dato lato server, non il tratto end2end, che affronta il caso man-in-the-middle. Concedendo l'accesso al server il provider apre il dato in locale allae autorità usa come se fosse in chiaro.

Scusa ma non ho capito bene cosa intendi: puoi spiegare meglio magari facendo un esempio?

On Fri, Jul 19, 2019 at 10:28:21AM +0000, Giulio Roman wrote:

...

Il problema dei server negli usa, è che le agenzie federali posso chiedere di implementare delle backdoor o di ricevere direttamente le chiavi di crittografazione. Se non lo fanno, viene proibito la distribuzione di quell'applicazione su suolo americano. Nel caso posso anche linkare dei articoli che lo spiegono meglio.

Non sono assolutamente un esperto di sicurezza ma credo che il discorso in questo caso sia marginale. Dato che Signal implementa la crittografia end-to-end, le chiavi private sono essere salvate solo sui singoli device, non sui server.

Confermo, nel caso di messaging tipo signal (ma anche whatsapp, che usa un protocollo di crittografia basato su quello di signal) il messaggio è cifrato end-to-end, quindi *tecnicamente* non intercettabile nemmeno sul server (dove però rimangono i metadati, es. chi parla con chi, quanto, quando, chi è amico di chi, ecc.).

E' anche possibile che ci siano delle "backdoor" (o che vengano messe in una versione aggiornata in seguito) direttamente nell'app per intercettare specifiche conversazioni, anche se il rischio di farsi scoprire per il produttore dell'app è molto alto (se qualcuno reversa l'app e la scopre) che *IMHO* è difficile che ci sia una cosa del genere, ma non ci metterei la mano sul fuoco :)

Di solito per intercettare questo tipo di comunicazioni le agenzie di law enforcement ricorrono a trojan (aka "captatori informatici") direttamente sul dispositivo della persona da intercettare, che a quel punto possono intercettare testi/audio/video direttamente alla fonte (o a tecniche tradizionali, es. intercettazione ambientale).

Al contrario telegram (salvo messaggio "segreto"), messenger, ecc. proteggono solo il canale, i messaggi possono essere letti/intercettati da chi ha il controllo del server (oltre ai metadati di cui sopra).

ciao, I.

Il problema dei server negli usa, è che le agenzie federali posso chiedere di implementare delle backdoor o di ricevere direttamente le chiavi di crittografazione. Se non lo fanno, viene proibito la distribuzione di quell'applicazione su suolo americano. Nel caso posso anche linkare dei articoli che lo spiegono meglio.

Ok, d'accordo, ma...

Non vedo perche` le agenzie USA dovrebbe essere limitati a suolo USA. Anzi, forse piu` verosimile al di fuori degli USA (e trattando non-citizens) hanno anche meno vincoli legali.

E non vedo neanche perche` le nostre agenzie non dovrebbero fare lo stesso. La rilevazioni legate ai clienti di Hacking Team (*Italia*) o FinFisher (*Germania*) ci hanno detto che questo tipo di snooping lo fanno un po` tutte le agenzie - da noi e in tutto il mondo.

OK, forse la polizia postale fa piu` *surveillance* che *mass surveillance* ma complice il fatto che spesso siamo tutti sulle stesse piattaforme il passo da uno al altro e` corto. E una volta introdotta *mass surveillance* siamo nella m**** se mai in futuro ci sara` un altro regime autoritario in Italia (storia docet).

La mia ricetta contro *mass surveillance* e`:

- privilegiare l'uso di sistemi decentrali e dove cio` non e` possibile almeno non usare tutti quanti un unico grosso service provider

- divulgare l'uso di tutti i tipi di encryption a tutti i livelli

- privilegiare l'uso di FOSS

Invece non ho mai sottoscritto quest'idea che sento spesso dei "dati che non devono lasciare i confini UE". Non e` vero ne da un punto di vista logico (vedi sopra) ne da un punto di vista giuridico (la UE ha mutual agreement con mezzo mondo sulla privacy, vedi sito del garante).

Ah, eh prima che qualcuno nomini la GDPR... Non ci protegge in questo contesto perche` hanno pensato bene di mettere l'exemption per law enforcement...

Bye, Chris.

Ciao Toni,

Grazie della risposta. La comunicazione che cerco di sostituire é solo quella interna. Per l'esterno credo che sarebbe un suicidio mediatico scegliere di non usare i social classici per farsi pubblicitá.

Il fattore etico é principalmente legato al fatto di non voler contribuire alla ulteriore crescita di un monopolio come quello di facebook e co. Come giustamente scrive Diego il prezzo che paghiamo nell'utilizzare questi servizi non é direttamente legato al denaro, ma c'é, e prima o poi quello che gli diamo si trasforma in soldi.

La sovranitá dei dati é un concetto interessante ma troppo "tecnico" per gli utenti a cui mi riferisco. Personalmente lo ritengo un plusvalore.

Ciao

-------- Original Message -------- On Jul 17, 2019, 10:51, Anton Auer wrote:

ciao giulio,

non penso che ci siano soluzioni "out of the box" :-( presumo che dovrà essere "un cammino insieme".

per approfondire ( la domanda si pone in tante situazioni ! ) distinguerei: -- la comunicazione "interna" tra gli attivisti, un gruppo circoscritto di persone -- la comunicazione verso l'esterno ( "avere tanti likes" )

nota sull'etica: -- probabilmente il criterio etico decisivo riguarda la concreta sovranità sui propri dati (del gruppo e delle singole persone costituenti il gruppo)

ci sentiamo ? anton ( 3921046439 - https://t.me.antonauer )

---

...

From: "Giulio Roman" giulio@roman.bz.it To: lugbz-list@lugbz.org Sent: Tuesday, 16 July, 2019 23:39:00 Subject: [Lugbz-list] Cerco alternativa a Facebook e Whatsapp

...

Ciao a tutti,

Sono membro di una associazione che organizza a Merano un festival musicale di beneficenza ogni anno a ferragosto.

Fino ad ora ci siamo organizzati attraverso un gruppo privato facebook e un gruppo whatsapp.

Forse sono riuscito a mettere la pulce nell'orecchio alle persone giuste e probabilmente discuteremo di migrare a soluzioni piú "etiche" delle due sopracitate.

Whatsapp lo rimpiazzo con Signal, ma facebook?

Sarebbe figo avere un client mobile decente per Diaspora, ma fanno tutti schifo. Nessuno ha le notifiche integrate con quelle native android/iOS.

Oggi ho provato Mastodon, ha un ottimo client mobile - Tusky, ma é un concetto troppo distante da facebook e sarebbe impossibile gestire una migrazione di questo tipo di utenti.

Qualcuno di voi saprebbe indirizzarmi verso qualcosa che permetta la creazione di contenuti discretamente strutturati (post e commenti) con la possibilitá di caricare media (foto e video) che abbia anche un client mobile decente?

Grazie anticipatamente Giulio _______________________________________________ http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list

On 17/07/2019 18:35, Daniele Gobbetti wrote:

Ciao Giulio,

Io farei un tentativo con matrix.org / riot.im

Matrix é il protocollo, riot il client "bandiera".

Il servizio nasce federato, con encryption end-to-end opzionale e ritenuta affidabile, il client é web based ma ci sono app per dispositivi mobili che integrano notifiche e compagnia bella. Tutto lo stack é free software.

Io gestisco un server (piccolino, 3 utenti) che partecipa alla federazione da - direi - almeno due anni e a parte un errore mio che ci ha tagliati fuori per un po' di tempo non ho mai riscontrato problemi.

Io fossi in te ci darei un'occhiata! Ha anche dei bridge verso altri servizi (es: XMPP) e supporta, se siete tra quelli che ci tengono, alcune cose frivole tipo gli stickers :-)

Ciao, Daniele

Ciao Daniele,

grazie. Mi ero dimenticato di riot.im, me l'aveva mostrato Konrad qualche mese fa. Sono riuscito a recuperare l'account che avevo creato su matrix.org e ho installato l'app mobile.

Sembra un ottimo prodotto per IM. Appena posso lo testo su piu' di un dispositivo.

Purtroppo non permette l'organizzazione delle comunicazioni in post/commenti, che e' abbastanza fondamentale per gli utonti che vorrei far migrare.

In ogni caso lo tengo in considerazione allo stesso livello di Signal per le funzioni di IM (forse anche un po' piu' alto, visto che consente anche di fare delle telefonate multiutente).

Grazie Giulio