Por aquí les dejo un pensamiento interesante: la noticia de la masiva brecha en AT&T que reveló los registros de llamadas y mensajes de texto de todos los clientes de AT&T durante seis meses en 2022 ejemplifica por qué el RCS es un protocolo terrible que no debería existir, y por qué es un error que Apple añada soporte para él en iOS 18 este año.
El argumento a favor del RCS es que mejora el SMS al agregar soporte para archivos de imagen y video mucho más grandes, así como comodidades como indicadores de escritura. Realmente es como el SMS pero mejor, lo que hace que parezca, a simple vista, una obviedad que todas las plataformas de telefonía celular lo deberían admitir. En esta visión, la única justificación para la negativa de Apple a admitir RCS durante años era mantener una brecha máxima de funciones entre iMessage (que, como se sabe, es exclusivo de los dispositivos de Apple) y los mensajes de los operadores. En el uso diario la gente no puede ver que iMessage está completamente cifrado de extremo a extremo, pero todos pueden ver claramente que las imágenes y videos enviados a través de SMS/MMS se ven mal. Así que parece ser simplemente por despecho que Apple se negó, durante años, a admitir RCS.
Pero el argumento en contra del RCS es fuerte y simple: no admite cifrado de extremo a extremo. Las nuevas plataformas de mensajería que deben tener éxito son aquellas que no solo admiten E2EE, sino que lo requieren. Los mensajes y las llamadas de audio/video solo deberían funcionar a través de E2EE. Eso es cierto para iMessage y FaceTime.
Los SMS y las llamadas de voz tradicionales carecen de cifrado alguno, pero están firmemente establecidos. Al igual que el correo electrónico. Pero cualquier nueva herramienta debería ser admitida solo si está fundamentalmente basada en E2EE. La especificación de RCS no ofrece cifrado alguno en los mensajes. Google ha implementado su propio cifrado para RCS, pero esa es una implementación propietaria que solo funciona para mensajes enviados entre usuarios que usan la aplicación Mensajes de Google. Según la “Descripción general del cifrado de extremo a extremo de Mensajes de Google”:
Para almacenar e intercambiar claves públicas de usuario como claves de identidad y claves previas, necesitamos un servidor de claves central. A diferencia de los servidores de mensajería RCS, el servidor de claves actualmente solo está alojado por Google.
Tal vez, algún día, la especificación de RCS admitirá un estándar abierto para E2EE. No estoy esperando mucho por eso. Por un lado, los consorcios de la industria suelen no producir buenas soluciones a problemas difíciles, y un estándar abierto para mensajería E2EE es un problema muy difícil. Quizás imposible. Alguien debe encargarse del intercambio y gestión de claves, pero ¿quién sería en un estándar abierto? Luego está la política: las agencias de aplicación de la ley de todo el mundo presionarán a los operadores en contra de eso. Como informé en febrero, la razón principal por la que Apple cambió de opinión sobre admitir RCS es que es obligatorio en China. El gobierno chino seguramente ama RCS porque no está cifrado.
Eso no es exclusivo de China u otras dictaduras autoritarias. Incluso en Occidente, las agencias de aplicación de la ley y de espionaje aman el hecho de que las llamadas de voz telefónicas y los mensajes de texto celulares no estén cifrados. No sabemos cuánto graban y conservan, pero es un hecho conocido que la NSA tiene cajas negras instaladas en los centros de llamadas de los operadores, y la apuesta más segura es que graban y almacenan todo. Pero incluso si confías en que las agencias de aplicación de la ley manejen estos datos sensibles de manera segura, está claro, solo con esta última violación de datos, que los propios operadores no son de fiar. Son ineptos. Siempre lo han sido. Y apuesto a que siempre lo serán.
Pero incluso si, de alguna manera, una versión futura de la especificación de RCS admite E2EE, ¿qué pasa con los dispositivos más antiguos que solo admiten la versión sin cifrado de RCS de hoy? Incluso si RCS eventualmente admite E2EE, lo cual, nuevamente, dudo, dicho soporte seguramente será opcional, no obligatorio, porque RCS ya se ha lanzado y se usa ampliamente en Android sin cifrado. Por eso las plataformas de mensajería deberían basarse en E2EE desde el principio. Es difícil imponer E2EE en una plataforma que ya admite mensajes no cifrados. RCS debería haber sido exclusivamente E2EE; en cambio, la norma no ofrece cifrado alguno.
La mensajería de operadores era mejor como protocolo heredado. El SMS no estaba muriendo, pero se estaba desvaneciendo lentamente, y debería haberse reservado para cosas como notificaciones automatizadas de “su mesa está lista” de los restaurantes. El RCS solo le va a dar a la mensajería de operadores nuevas oportunidades que no debería haber recibido.
Otra cosa que es molesta acerca de la mensajería de operadores es que requiere un dispositivo con una tarjeta SIM activa de un operador. Sí, puede enviar y recibir SMS desde una Mac o iPad con el Reenvío de mensajes de texto, pero necesita el iPhone para hacer el reenvío. Si apaga (o peor, pierde) su iPhone, su Mac e iPad ya no podrán enviar ni recibir mensajes de texto – y supongo que eso también será cierto para el RCS. Mientras que con plataformas de mensajería modernas como iMessage, Signal y WhatsApp, dispositivos como PC y tabletas pueden servir como clientes sin un teléfono.
Admito que hay un buen argumento a favor de RCS. Básicamente, que la mensajería de operadores telefónicos es ahora y siempre será una forma de comunicación universalmente accesible. Todos los que están en línea tienen un teléfono celular, y esos teléfonos pueden enviar y recibir SMS. Dado que la mensajería de operadores no va a desaparecer, argumenta esta posición, debería mejorarse tanto como sea posible, y el RCS – a pesar de sus deficiencias – es claramente mejor que el SMS. Por lo tanto, el RCS debería ser admitido por todos los dispositivos móviles, incluido iOS. Andy Ihnatko, en una conversación conmigo en Threads en noviembre, lo resume de esta manera:
La mensajería de operadores en una aplicación de mensajería preinstalada puede parecer irrelevante para muchos de nosotros. Pero funciona y satisface. Y el proceso de descubrimiento, selección e instalación de un servicio diferente – y conseguir que todo su círculo social lo adopte – es peligroso para tanta gente.
“Si sé su número de teléfono, les puedo enviar un mensaje o una foto” es una característica importante para el usuario promedio. Por eso, dichas aplicaciones deberían ser lo más robustas posible.
Ihnatko tiene razón, pero solo si crees que la mensajería de operadores debería permanecer como base. Yo no lo creo. Y también es un punto de vista centrado en EE. UU. En la mayoría de los países del mundo, plataformas como WhatsApp, Line o Facebook Messenger sirven ese rol, como la plataforma “todos la tienen” de mensajería – y son mejores por ello. Personalmente prefiero iMessage por varias razones, pero iMessage está limitado fundamentalmente para servir ese rol básico de “todos la tienen” por la decisión de Apple de no lanzar un cliente de Android. Eddy Cue no pierde muchas discusiones, pero perdió esa. Todo el esfuerzo dedicado a presionar a Apple para apoyar RCS habría sido mejor empleado presionando a Apple para lanzar iMessage para Android. Y sin un cliente de iMessage compatible con Android, ese papel debería ir a WhatsApp, no a RCS. WhatsApp es gratuito, seguro y funciona igualmente bien en todos los teléfonos.
Meta lo sabe, y claramente huele la oportunidad. ¿Lo sabe Apple?