Apple y Google monitorizan todas tus notificaciones push. Pero Tuta te protege de esto desde 2017.

Permitir que todo el mundo abandone Gmail

Nuestro objetivo con Tuta es que todo el mundo pueda cambiar a un servicio de correo electrónico seguro que respete sus datos y su derecho a la privacidad. Para nosotros es muy importante que todo el mundo pueda abandonar Gmail por completo.

Por eso, deshacernos de los servicios de notificaciones push de Google era nuestra máxima prioridad a la hora de reconstruir nuestra aplicación de correo seguro desde cero. Estamos muy contentos de haber conseguido sustituir GCM de Google para las notificaciones push, de modo que la aplicación Tuta no tiene ninguna conexión con Google. Esto te protege del enorme ecosistema de seguimiento de anuncios de Google, así como del espionaje gubernamental sin orden judicial.

Ahora, nuevas pruebas demuestran que este cambio preventivo fue un paso importante en la protección de tu privacidad. Tuta es el único proveedor de correo electrónico cifrado que ofrece este nivel de privacidad, ni siquiera la alternativa segura Protonmail da este paso adicional.

Apple y Google vigilan todas tus notificaciones push

Sorprendentes revelaciones fueron hechas por Reuters el 7 de diciembre de 2023 con pruebas de que los gobiernos de todo el mundo están espiando a los usuarios de Apple y Google mediante el control de las notificaciones push que se envían a sus dispositivos. Esta forma alternativa de vigilancia saltó a la luz pública tras la publicación de una carta abierta enviada por el senador estadounidense Ron Wyden al Departamento de Justicia.

Estas notificaciones permiten a los servicios de inteligencia y a las fuerzas de seguridad vincular metadatos ya recopilados a cuentas de Google o Apple.

Tuta ya era consciente de este riesgo potencial hace años y en 2017 sustituimos por completo los servicios de notificación de Google por nuestro propio servicio de notificaciones push. Si utilizas Tuta en Android, no se comparten datos de notificaciones push con Google. Tu privacidad está a salvo con nosotros.

También admitimos la instalación de la aplicación Tuta en dispositivos Android a través de F-Droid, que le permite utilizar el software sin proporcionar a Google el dato de que lo está utilizando. Al instalar Tuta a través de F-Droid sus notificaciones push tampoco son susceptibles de esta forma de recopilación de datos y vigilancia.

En los dispositivos de Apple aún no hemos introducido nuestro propio servicio de notificaciones push, pero esto está previsto para un futuro lanzamiento. Actualmente, todas las notificaciones push en dispositivos iOS muestran sólo la información mínima, informándole de que un nuevo correo electrónico ha llegado, con el fin de limitar los posibles datos que podrían ser recogidos por los intentos de vigilancia del gobierno.

Cómo sustituimos GCM

GCM (o, como se llama ahora, FCM, Firebase Cloud Messaging) es un servicio propiedad de Google. En Tuta utilizábamos FCM para nuestra antigua aplicación Android. Desafortunadamente, FCM incluye el código de seguimiento de Google para análisis, que no queríamos tener en nuestra aplicación segura.

Y, aún más importante: Para poder utilizar FCM, tienes que enviar todos tus datos de notificación a Google. También tienes que utilizar sus bibliotecas propietarias. Debido a los problemas de privacidad y seguridad que esto conlleva, en la antigua aplicación no enviábamos ningún tipo de información junto con los mensajes de notificación (lo que, comprensiblemente, provocó las quejas de nuestros usuarios). Por lo tanto, la notificación push en la antigua aplicación sólo mencionaba que habías recibido un nuevo mensaje sin ninguna referencia al correo electrónico en sí o al buzón en el que se había colocado el mensaje.

El uso de FCM es bastante cómodo, a lo largo de los años Google introdujo cambios en Android que hicieron más difícil no utilizar su servicio para las notificaciones. Por otro lado, renunciar al servicio de notificaciones de Google nos liberaría de exigir a nuestros usuarios que tuvieran Google Play Services en sus teléfonos.

El reto de sustituir el FCM de Google

Las aplicaciones de Tuta son software libre y queremos ofrecer una verdadera alternativa de código abierto a Gmail, lo que para nosotros incluye publicar nuestra aplicación para Android en F-Droid. Queríamos que nuestros usuarios pudieran utilizar Tuta en todas las ROM y en todos los dispositivos, sin la interferencia de un servicio de terceros como Google.

Decidimos aceptar el reto y crear nuestro propio servicio de notificaciones push.

Cuando empezamos a diseñar nuestro sistema push, teníamos varios objetivos en mente:

• debe ser seguro
• ser rápido
• que consumiera poca energía

Investigamos cómo otros (Signal, Wire, Conversations, Riot, Facebook, Mastodon) habían resuelto problemas similares. Teníamos varias opciones en mente, incluyendo WebSockets, MQTT, Server Sent Events y HTTP/2 Server Push.

Sustitución de FCM por SSE

Nos decidimos por SSE (Server Sent Events) porque parecía una solución sencilla. Con esto quiero decir "fácil de implementar, fácil de depurar". Depurar este tipo de cosas puede ser un quebradero de cabeza, así que no hay que subestimar este factor. Otro argumento a favor de SSE era la relativa eficiencia energética: No necesitábamos mensajes ascendentes y nuestro objetivo no era una conexión constante con el servidor.

¿Qué es SSE?

SSE es una API web que permite a un servidor enviar eventos a los clientes conectados. Es una API relativamente antigua que, en mi opinión, está infrautilizada. Nunca había oído hablar de SSE antes de echar un vistazo a la red federada Mastodon: Utilizan SSE para las actualizaciones de la línea de tiempo en tiempo real, y funciona de maravilla.

El protocolo en sí es muy sencillo y se asemeja al viejo sondeo: El cliente abre una conexión y el servidor la mantiene abierta. La diferencia con el sondeo clásico es que nosotros mantenemos esta conexión abierta para múltiples eventos. El servidor puede enviar eventos y mensajes de datos, simplemente separados por nuevas líneas. Así que lo único que tiene que hacer el cliente es abrir una conexión con un tiempo de espera grande y leer el flujo en un bucle.

SSE se ajusta mejor a nuestras necesidades de lo que lo haría WebSocket (es más barato y converge más rápido, porque no es dúplex). Hemos visto múltiples aplicaciones de chat intentando usar WebSocket para notificaciones push y no parecía eficiente energéticamente.

Ya teníamos experiencia con WebSocket y sabíamos que a los cortafuegos no les gustan las conexiones keepalive. Para solucionarlo, utilizamos la misma solución para SSE que para WebSocket: Enviamos mensajes "heartbeat" vacíos cada pocos minutos. Este intervalo es ajustable desde el servidor y aleatorio para no saturarlo.

El soporte multicuenta plantea retos adicionales

Hay que tener en cuenta que la aplicación Tuta admite varias cuentas, lo que supuso un reto para nosotros: Queríamos mantener abierta una sola conexión por dispositivo. Tras varias iteraciones, hemos encontrado el diseño que nos satisfacía. Cada dispositivo tiene un único identificador. Al abrir la conexión, el cliente envía la lista de usuarios de los que quiere recibir notificaciones. El servidor valida esta lista con los registros de usuarios y filtra los no válidos.

Los usuarios pueden eliminar un token de notificación de su configuración, pero ello no afectaría a otros inicios de sesión en este dispositivo. Además, tuvimos que crear un mecanismo de seguimiento de la entrega cuando se recibe una notificación. Por desgracia, descubrimos que nuestro servidor no es capaz de detectar cuándo se interrumpe una conexión, por lo que tuvimos que enviar confirmaciones desde el lado del cliente.

Para recibir las notificaciones, aprovechamos las capacidades de Android. Ejecutamos un servicio en segundo plano que mantiene abierta la conexión con el servidor, de forma similar a lo que hace el proceso FCM. Otra dificultad la causó el modo Doze, introducido en Android M. El Doze, que se activa tras un periodo de inactividad, entre otras cosas impide que los procesos en segundo plano accedan a la red. Como puedes imaginar, esto impide que nuestra app reciba notificaciones.

Mitigamos este problema pidiendo a los usuarios que hicieran una exención de las optimizaciones de batería para nuestra app. Funcionó bastante bien. Un problema similar, pero no relacionado con Doze, son las optimizaciones de batería específicas del proveedor. Para prolongar la vida de la batería de sus dispositivos, los fabricantes de teléfonos, como Xiaomi, activan por defecto estrictas optimizaciones de la batería. Por suerte los usuarios pueden desactivarlas, pero hay que comunicarlo mejor.

Otro problema fue causado por los cambios de Android O. Uno de ellos son las restricciones de procesos en segundo plano: A menos que tu app sea visible para el usuario, tus procesos en segundo plano se van a detener y no podrás lanzar nuevos.

Inicialmente pensamos que podemos solucionar esto mostrando una notificación persistente con prioridad mínima, que es visible en el canalón de notificaciones, pero no en la barra de estado. Esto no funcionó en Oreo: Si intentas lanzar un servicio en segundo plano y usas la prioridad mínima para su notificación, la prioridad de la notificación se actualiza a una prioridad más alta (visible todo el tiempo) y, además de eso, el sistema muestra otra notificación persistente: "La aplicación X está consumiendo batería".

Inicialmente planeamos explicar a los usuarios cómo podían ocultar estas notificaciones persistentes, pero no era una buena experiencia de usuario, así que tuvimos que encontrar una solución mejor. Aprovechamos el mecanismo Job de Android para lanzar nuestro servicio periódicamente (al menos cada 15 minutos), y también intentamos mantenerlo vivo después. No mantenemos WakeLocks manualmente, el sistema lo hace por nosotros. Hemos podido prescindir por completo de las notificaciones persistentes. Aunque a veces las notificaciones tengan un pequeño retraso, siempre se reciben y los correos electrónicos llegan al instante.

Al final, tuvimos que hacer algo de trabajo, pero mereció totalmente la pena. Liberamos a nuestros usuarios del requisito de Google Play Services. Por fin, todo el mundo puede tener la aplicación Tuta en F-Droid. El sistema combina ahora ambas cosas: buena eficiencia energética y velocidad.

Pensamiento final: Cada usuario debería poder elegir un "Proveedor de notificaciones" para cada aplicación.

¿No sería genial si el usuario pudiera elegir un "proveedor de notificaciones push" en la configuración del teléfono y el sistema operativo gestionara todos estos detalles por sí mismo? ¿Así, cada aplicación que no quiera ser controlada por el propietario de la plataforma no tendría que inventar de nuevo el sistema? Podría estar cifrado de extremo a extremo entre la aplicación y el servidor de aplicaciones. No hay ninguna dificultad técnica real en ello, pero mientras nuestros sistemas estén controlados por grandes actores que no lo permiten, tenemos que resolverlo por nosotros mismos.

Por una web libre y abierta, tenemos que dejar de entregar todos nuestros datos privados a las grandes corporaciones. Por eso decimos #NoMoreGoogle