Permitir que todo el mundo abandone Google por completo

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, también conocido como “deGoogle”, 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 de la recopilación masiva de datos 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 de Estados Unidos.

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

El equipo de Tuta ya era consciente de este riesgo potencial hace años y, en 2017, sustituimos 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 la información de que lo está utilizando. Pero no importa si instalas la aplicación Android a través de F-Droid o Google Play, tus notificaciones push están seguras con nosotros y no son susceptibles a la recopilación de datos y vigilancia de Google.

Para una máxima protección de la privacidad, en el pasado todas las notificaciones push en dispositivos iOS solo mostraban información mínima, limitándose a informarte de que se había recibido un nuevo correo electrónico. De esta forma, limitamos los datos potenciales que podrían recopilar Apple y los intentos de vigilancia del gobierno. Cuando añadimos una vista previa de la notificación para mostrar el remitente y el asunto en las notificaciones, nos aseguramos de que esta información está cifrada de forma segura para protegerte de la vigilancia de Apple. Ahora, incluso puede utilizar acciones rápidas en notificaitons de la aplicación Tuta todo mientras estamos protegiendo su privacidad al máximo.

Cómo sustituimos GCM

GCM (o, como se llama ahora, FCM, Firebase Cloud Messaging) es un servicio propiedad de Google. En Tuta solíamos utilizar FCM para nuestra antigua aplicación Android, hasta 2017. Por desgracia, FCM incluye el código de seguimiento de Google para analíticas, que no queríamos tener en nuestra app de correo electrónico seguro.

Y, aún más importante: Para poder utilizar FCM, tienes que enviar todos tus datos de notificación a Google, lo que debería ser un no-go para cualquier servicio de correo electrónico seguro. 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 para Android 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. Así que eso es exactamente lo que hicimos.

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
• Debe ser rápido
• Debe consumir poca energía

Hemos investigado cómo otras aplicaciones seguras y privadas (Signal, Wire, Conversations, Riot, Mastodon) han 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 desde el punto de vista energético.

Ya teníamos experiencia con WebSocket y sabíamos que a los cortafuegos no les gustan las conexiones “keep-alive”. 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 algunas 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.

La nueva aplicación Tuta Calendar también se puede encontrar en F-Droid, nuestra tienda de aplicaciones favorita.

Reflexión final: Cada usuario debería poder elegir un “proveedor de notificaciones” para cada aplicación.

¿No sería genial que el usuario pudiera elegir un “proveedor de notificaciones push” en la configuración del teléfono y que 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 encriptarse 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.