Apple e Google monitorano tutte le vostre notifiche push. Ma Tuta vi protegge da questo dal 2017.

Siamo qui per fermare la sorveglianza da parte di aziende come Google e Apple. Ecco perché abbiamo sostituito l'FCM di Google con il nostro sistema di notifiche e manteniamo i dati di notifica di Apple al minimo. Continuate a leggere per capire perché è importante.

Quando abbiamo riprogettato il client Tuta nel 2017, ci siamo concentrati rigorosamente sulla nostra missione di liberare tutti dall'obbligo di utilizzare i servizi di Google. Le nuove prove dimostrano che è stata una mossa eccellente, poiché Google e Apple controllano tutte le notifiche push. Ecco perché pubblichiamo anche la nostra app per Android su F-Droid, rendendola una delle poche app di posta elettronica disponibili senza il servizio di notifiche push di Google. Si trattava di una vera e propria sfida, quindi vi spieghiamo come ci siamo riusciti.


Consentire a tutti di abbandonare Gmail

Il nostro obiettivo con Tuta è quello di consentire a tutti di passare a un servizio di posta elettronica sicuro che rispetti i vostri dati e il vostro diritto alla privacy. Per noi è molto importante che tutti possano abbandonare completamente Gmail.

Per questo motivo, l’eliminazione dei servizi di notifica push di Google è stata la nostra priorità assoluta quando abbiamo ricostruito da zero la nostra app di posta elettronica sicura. Siamo molto soddisfatti di essere riusciti a sostituire il GCM di Google per le notifiche push, in modo che l’app Tuta non abbia alcun legame con Google. Questo vi protegge dal massiccio ecosistema di tracciamento degli annunci di Google e dalle intercettazioni governative senza mandato.

Ora nuove prove dimostrano che questo cambiamento preventivo è stato un passo importante per proteggere la vostra privacy. Tuta è l’unico provider di e-mail crittografate che offre questo livello di privacy, nemmeno l’alternativa sicura Protonmail fa questo passo in più.

Apple e Google monitorano tutte le vostre notifiche push

Il 7 dicembre 2023 Reuters ha rivelato che i governi di tutto il mondo stanno spiando gli utenti di Apple e Google monitorando le notifiche push inviate ai loro dispositivi. Questa forma alternativa di sorveglianza è stata portata per la prima volta all’attenzione del pubblico dopo la pubblicazione di una lettera aperta inviata dal senatore statunitense Ron Wyden al Dipartimento di Giustizia degli Stati Uniti.

Queste notifiche consentono alle agenzie di intelligence e alle forze dell’ordine di collegare i metadati già raccolti agli account Google o Apple.

Tuta era già a conoscenza di questo rischio potenziale anni fa e nel 2017 abbiamo sostituito completamente i servizi di notifica di Google con il nostro servizio di notifica push. Se si utilizza Tuta su Android, nessun dato di notifica push viene condiviso con Google. La vostra privacy è al sicuro con noi.

Supportiamo anche l’installazione dell’app Tuta sui dispositivi Android attraverso F-Droid, che consente di utilizzare il software senza fornire a Google la segnalazione del suo utilizzo. Installando Tuta tramite F-Droid, anche le notifiche push non sono soggette a questa forma di raccolta e sorveglianza dei dati.

Sui dispositivi Apple non abbiamo ancora introdotto il nostro servizio di notifiche push, ma è previsto un rilascio futuro. Attualmente, tutte le notifiche push sui dispositivi iOS visualizzano solo informazioni minime, informando l’utente dell’arrivo di una nuova e-mail, al fine di limitare i possibili dati che potrebbero essere raccolti dai tentativi di sorveglianza governativa.

Come abbiamo sostituito GCM

GCM (o, come si chiama ora, FCM, Firebase Cloud Messaging) è un servizio di proprietà di Google. Noi di Tuta usavamo FCM per la nostra vecchia applicazione Android. Purtroppo, FCM include il codice di tracciamento di Google per le analisi, che non volevamo avere nella nostra app sicura.

E, cosa ancora più importante: Per poter utilizzare FCM, è necessario inviare tutti i dati di notifica a Google. Inoltre, è necessario utilizzare le loro librerie proprietarie. A causa delle preoccupazioni per la privacy e la sicurezza che naturalmente ne derivano, con la vecchia app non abbiamo inviato alcuna informazione insieme ai messaggi di notifica (il che, comprensibilmente, ha portato a lamentele da parte dei nostri utenti). Pertanto, la notifica push della vecchia app segnalava solo la ricezione di un nuovo messaggio, senza alcun riferimento all’e-mail stessa o alla casella di posta in cui il messaggio era stato inserito.

FCM è abbastanza comodo da usare, nel corso degli anni Google ha apportato modifiche ad Android che hanno reso più difficile non utilizzare il loro servizio per le notifiche. D’altra parte, rinunciare al servizio di notifica di Google ci libererebbe dall’obbligo per i nostri utenti di avere Google Play Services sui loro telefoni.

La sfida di sostituire l’FCM di Google

Le applicazioni Tuta sono software libero e vogliamo fornire una vera alternativa open source a Gmail, il che per noi significa pubblicare la nostra applicazione Android su F-Droid. Volevamo che i nostri utenti potessero utilizzare Tuta su ogni ROM e su ogni dispositivo, senza l’interferenza di un servizio di terze parti come Google.

Abbiamo deciso di accettare la sfida e di costruire il nostro servizio di notifiche push.

Quando abbiamo iniziato a progettare il nostro sistema push, avevamo in mente diversi obiettivi:

  • deve essere sicuro
  • essere veloce
  • deve essere efficiente dal punto di vista energetico

Abbiamo fatto una ricerca su come altri (Signal, Wire, Conversations, Riot, Facebook, Mastodon) hanno risolto problemi simili. Avevamo in mente diverse opzioni, tra cui WebSockets, MQTT, Server Sent Events e HTTP/2 Server Push.

Sostituzione di FCM con SSE

Abbiamo scelto SSE (Server Sent Events) perché ci sembrava una soluzione semplice. Con questo intendo “facile da implementare e da debuggare”. Il debug di questo tipo di cose può essere un grosso grattacapo, quindi non bisogna sottovalutare questo fattore. Un altro argomento a favore di SSE era la relativa efficienza energetica: Non avevamo bisogno di messaggi upstream e la connessione costante al server non era il nostro obiettivo.

Che cos’è SSE?

SSE è un’API web che consente a un server di inviare eventi ai client connessi. È un’API relativamente vecchia che, a mio parere, è sottoutilizzata. Non avevo mai sentito parlare di SSE prima di guardare la rete federata Mastodon: Utilizzano SSE per gli aggiornamenti della timeline in tempo reale e funziona benissimo.

Il protocollo è molto semplice e assomiglia al buon vecchio polling: Il client apre una connessione e il server la mantiene aperta. La differenza rispetto al polling classico è che noi teniamo aperta questa connessione per più eventi. Il server può inviare eventi e messaggi di dati, semplicemente separati da nuove linee. Quindi l’unica cosa che il client deve fare è aprire una connessione con un timeout elevato e leggere il flusso in un ciclo.

SSE si adatta alle nostre esigenze meglio di WebSocket (è più economico e converge più velocemente, perché non è duplex). Abbiamo visto diverse app di chat che cercavano di usare WebSocket per le notifiche push e non sembravano efficienti dal punto di vista energetico.

Avevamo già un po’ di esperienza con WebSocket e sapevamo che ai firewall non piacciono le connessioni keepalive. Per risolvere questo problema, abbiamo utilizzato lo stesso workaround per SSE come per WebSocket: Inviamo messaggi vuoti “heartbeat” ogni pochi minuti. Abbiamo reso questo intervallo regolabile dal lato server e randomizzato per non sovraccaricare il server.

Il supporto di più account pone ulteriori sfide

Va notato che l’applicazione Tuta supporta più account e questo ha rappresentato una sfida per noi: Volevamo mantenere aperta una sola connessione per dispositivo. Dopo alcune iterazioni, abbiamo trovato un design che ci soddisfa. Ogni dispositivo ha un solo identificatore. All’apertura della connessione, il client invia l’elenco degli utenti per i quali desidera ricevere le notifiche. Il server convalida questo elenco con i record degli utenti e filtra quelli non validi.

Gli utenti possono eliminare un token di notifica dalle loro impostazioni, ma ciò non influisce sugli altri accessi a questo dispositivo. Inoltre, abbiamo dovuto creare un meccanismo di tracciamento della consegna quando viene ricevuta una notifica. Purtroppo abbiamo scoperto che il nostro server non è in grado di rilevare l’interruzione della connessione, quindi abbiamo dovuto inviare le conferme dal lato client.

Per ricevere le notifiche, sfruttiamo le funzionalità di Android. Eseguiamo un servizio in background che mantiene aperta la connessione al server, in modo simile a quanto fa il processo FCM. Un’altra difficoltà è stata causata dalla modalità Doze, introdotta in Android M. La modalità Doze, che si attiva dopo un periodo di inattività, tra le altre cose impedisce ai processi in background di accedere alla rete. Come potete immaginare, questo impedisce alla nostra app di ricevere notifiche.

Abbiamo attenuato questo problema chiedendo agli utenti di esentare la nostra app dall’ottimizzazione della batteria. Ha funzionato abbastanza bene. Un problema simile, ma non correlato a Doze, è rappresentato dalle ottimizzazioni della batteria specifiche del produttore. Per prolungare la durata della batteria dei loro dispositivi, i produttori di telefoni, come Xiaomi, attivano di default rigide ottimizzazioni della batteria. Fortunatamente gli utenti possono disattivarle, ma dobbiamo comunicarlo meglio.

Un altro problema è stato causato dai cambiamenti di Android O. Uno di questi è la restrizione dei processi in background. Uno di questi è la restrizione dei processi in background: A meno che la vostra app non sia visibile all’utente, i processi in background verranno interrotti e non potrete avviarne di nuovi.

Inizialmente pensavamo di poter risolvere il problema mostrando una notifica persistente con priorità minima, visibile nel riquadro delle notifiche, ma non nella barra di stato. Questo non ha funzionato con Oreo: Se si tenta di avviare un servizio in background e si utilizza la priorità minima per la sua notifica, la priorità della notifica viene portata a una priorità più alta (visibile per tutto il tempo) e, in aggiunta, il sistema mostra un’altra notifica persistente: “L’app X sta consumando la batteria”.

Inizialmente avevamo previsto di spiegare agli utenti come nascondere queste notifiche persistenti, ma l’esperienza d’uso non era delle migliori, quindi abbiamo dovuto trovare una soluzione migliore. Abbiamo sfruttato il meccanismo Job di Android per lanciare il nostro servizio periodicamente (almeno ogni 15 minuti) e cerchiamo di mantenerlo in vita anche in seguito. Non manteniamo i WakeLock manualmente: il sistema lo fa per noi. Siamo riusciti a eliminare del tutto le notifiche persistenti. Anche se a volte le notifiche hanno un piccolo ritardo, vengono sempre ricevute e le e-mail arrivano immediatamente.

Alla fine abbiamo dovuto fare un po’ di lavoro, ma ne è valsa la pena. Abbiamo liberato i nostri utenti dai requisiti di Google Play Services. Finalmente tutti possono avere l’app Tuta su F-Droid. Il sistema ora combina entrambe le cose: buona efficienza energetica e velocità.

Pensiero finale: Ogni utente dovrebbe poter scegliere un “fornitore di notifiche” per ogni app.

Non sarebbe fantastico se l’utente potesse scegliere un “fornitore di notifiche push” nelle impostazioni del telefono e il sistema operativo gestisse da solo tutti questi dettagli? Così ogni app, che non vuole essere controllata dal proprietario della piattaforma, non dovrebbe inventare di nuovo il sistema? Potrebbe essere crittografato Ende-zu-Ende tra l’app e il server dell’app. Non c’è alcuna difficoltà tecnica in questo, ma finché i nostri sistemi sono controllati da grandi operatori che non lo permettono, dobbiamo risolverlo da soli.

Per un web libero e aperto, dobbiamo smettere di dare tutti i nostri dati privati alle grandi aziende. Ecco perché diciamo: #NoMoreGoogle