Todo esto suena muy bien y muy futurista, sin embargo, Open Gateway choca frontalmente con tu privacidad como usuario de Internet, además, también podría atacar la neutralidad de la red. Debemos tener en cuenta que todas las compañías que paguen a los operadores por acceder a las APIs, tendrán acceso a muchísimos datos de los clientes de los operadores, y esto supone un grave riesgo para nuestra privacidad.

Así atacará Open Gateway tu privacidad en Internet

Este proyecto tiene actualmente más de 10 APIs diferentes que están enfocadas a realizar diferentes acciones, algunas de ellas atentan directamente contra tu privacidad y permitirá a las aplicaciones, empresas e incluso operadores, que estemos totalmente rastreados en tiempo real (más aún si cabe). A continuación, os vamos a explicar cuáles son las API más «peligrosas» para tu privacidad.

AnonymisedSubscriberIdentifier

Esta API proporciona a la empresa que tenga acceso a la misma, a obtener una identidad fija anonimizada de un cliente final que utilice un determinado dispositivo móvil, además, un aspecto muy importante es que tendremos la misma identidad, independientemente de si cambiamos de teléfono móvil o de tarjeta SIM. Siempre que un cliente final intente acceder a los servicios de Internet, tendremos una identidad fija a la que «asociarnos».

Ahora mismo el alcance de esta API solamente está limitada a redes 4G y 5G, no obstante, en la documentación oficial indican que esta solo es la primera etapa, por lo que suponemos que también estará próximamente en las redes de Internet fijo como la fibra óptica.

• ¿En qué te afecta esto? Si hasta el momento con las cookies y las supercookies ya estábamos bastante vigilados y era complicado mantener nuestra privacidad, con esto no solamente los operadores lo sabrán todo sobre nosotros, sino que comercializarán esta información, ya que las empresas pagarán para acceder a esta API.
• ¿Por qué le interesa al operador hacer esto? Para ganar dinero comercializando nuestros datos, las empresas pagarán por el acceso a la API y entonces tendrán acceso a todos los datos nuestros.

Recientemente los operadores han lanzado TrustPid que es una «supercookie» a nivel de operador, con el objetivo de rastrearnos, pues este nuevo método es básicamente lo mismo, pero con el objetivo de que otras empresas puedan acceder a los datos de los clientes para ofrecerles publicidad o algún servicio.

IdentityAndConsentManagement

Esta API se encarga de regular la privacidad del usuario, las plataformas de los operadores (Network as a Service) deberán construirse con el enfoque en la privacidad para cumplir completamente con las regulaciones de protección de datos, como el GDPR de Europa. Gracias a la GDPR, algunas API del proyecto CAMARA necesitarán del consentimiento del usuario para acceder a los datos. Por tanto, obligará a los operadores a proporcionar medios y soluciones para capturar datos de sus clientes, almacenar estos datos y gestionar el consentimiento a lo largo de todo el ciclo de vida.

Si esto no está contemplado, las API de CAMARA no se podrán implementar, ya que deberán cumplir con el GDPR de Europa. Los operadores tendrán que construir una solución para incorporar la identidad del usuario final y/o del suscriptor del servicio, ya que ambos podrían ser diferentes, un mismo titular podría tener diferentes números que usen diferentes personas.

• ¿En qué te afecta esto? Esta API lo que hará será «garantizar» tu privacidad, pidiéndote permiso para los casos en lo que la legislación vigente lo requiera.

Ahora será más importante que nunca leer todas las condiciones y términos, será algo similar al «banner» de cookies que tenemos actualmente en todas las webs.

DeviceLocation

Esta API proporciona a la empresa que contrate el servicio la posibilidad de comprobar la ubicación del dispositivo. En una primera etapa está previsto solamente para redes 4G y 5G según explica la documentación oficial, sin embargo, supuestamente después irán las redes fijas de fibra óptica. En concreto, lo que hace esto es verificar si la ubicación de un dispositivo está dentro de un área especificada por las coordenadas (latitud y longitud) que proporcione el GPS si está habilitado.

Actualmente, esta API solamente proporciona la verificación de la ubicación final, para hacer esto, el dispositivo móvil deberá pasar información como el «ueld» que es básicamente un identificador externo como el msisdn, dirección IPv4 o IPv6, también proporcionará la latitud y longitud, así como un valor esperado entre 2km y 200km a la redonda. El cliente preguntará si la ubicación del dispositivo se encuentra dentro de este «círculo» creado, el motivo de tener un rango entre 2km y 200km es que, al triangular por las antenas, tenemos este rango tan grande.

• ¿En qué te afecta esto? Ahora mismo existen métodos para falsificar la ubicación que nos proporciona el GPS, por ejemplo, podemos indicar que estamos en Galicia cuando realmente estamos en Madrid, y las aplicaciones se van a creer que estamos en Galicia. Sin embargo, con esta API esto ya no será posible, porque el operador nos va a situar en unas antenas móviles en concreto, y los datos no van a coincidir, por tanto, no podremos falsificar la ubicación.
• ¿Por qué le interesa al operador hacer esto? Si el operador vende a diferentes aplicaciones nuestra ubicación real, como a aplicaciones de citas tipo Tinder, podrán confirmar que efectivamente estamos localizados en la zona donde decimos que estamos. Actualmente hay aplicaciones que permiten falsificar la posición GPS.

Tal y como podéis ver, con esta API podrán tenernos localizados físicamente en cualquier lugar y no habrá forma para impedirlo.

DeviceIdentifier

Esta API proporciona la posibilidad de obtener la identidad del dispositivo final que está utilizando el cliente, es básicamente obtener el código IMEI del terminal y saber tanto la marca como el modelo del terminal. Esto ya se hace actualmente porque parte del código IMEI identifica a la marca fabricante, esto no supone nada nuevo, pero sí es cierto que ahora empresas externas podrán acceder a información de cuál es nuestro móvil, para mandarnos publicidad de sus nuevos terminales o de la competencia.

Esta API, si se relaciona con la de AnonymisedSubscriberIdentifier, es la combinación perfecta para saberlo todo sobre nosotros, incluyendo qué móvil usamos, y extrapolar el nivel adquisitivo de los clientes.

• ¿En qué te afecta esto? Por sí misma solamente afecta que podrán saber la marca y modelo de terminal móvil, algo que ya se sabe porque el IMEI lo dice. El problema viene si lo combinan con otras API y más información, podrían saber aún más sobre nosotros. Si tienes un iPhone se puede extrapolar que tienes un nivel adquisitivo alto, y poder enviarte publicidad de productos premium.
• ¿Por qué le interesa al operador hacer esto? Si el operador vende a diferentes aplicaciones nuestra ubicación real, como a aplicaciones de citas tipo Tinder, podrán confirmar que efectivamente estamos localizados en la zona donde decimos que estamos. Actualmente hay aplicaciones que permiten falsificar la posición GPS.

Como podéis ver, una API más para recolección de datos y su venta a todo el que quiera entrar en Open Gateway.

NumberVerification

Esta API tiene como objetivo verificar que el número de teléfono proporcionado es el que realmente se utiliza en el dispositivo. De esta forma, se verifica que el usuario está usando en el dispositivo el mismo número de teléfono que está declarado. Por supuesto, hace posible que un proveedor de servicios verifique el número por sí mismo, devolviendo el número de teléfono asociado a un token de acceso del usuario autenticado

Esta API permite comprobar en tiempo real el número de teléfono que se está usando en un móvil, esto está enfocado exclusivamente a redes 4G y 5G, ya que las conexiones Wi-Fi estarán fuera de esta API. Tiene dos métodos para comprobar el teléfono, la primera es obteniendo el resultado de la comparación, y la más preocupante es que el cliente puede enviar tu número de teléfono del dispositivo que utiliza, para que puedan verificarlo ellos mismos.

Otra característica importante es que esta API usará las conexiones de red móvil directamente para verificar la posesión del número de teléfono en segundo plano, ni siquiera es necesario que haya interacción del usuario. No hay contraseñas de un solo uso recibidas por SMS o usando aplicaciones autenticadoras como Google Authenticator, es mucho más simple y transparente. Esta API se podrá usar para registrarnos en el servicio y también para comprobar después que no hemos cambiado de móvil.

• ¿En qué te afecta esto? Una aplicación de terceros puede recibir tu número de móvil directamente, nada de autenticar por el SMS recibido (independientemente del número móvil que hayas indicado), ahora las empresas recibirán directamente tu número de teléfono real que está usando.
• ¿Por qué le interesa al operador hacer esto? El operador puede vender el servicio de comprobación del teléfono móvil a una empresa externa, ya ni siquiera será necesario poner nuestro móvil y validarlo con un código por SMS, sino que directamente la empresa podría recibir nuestro número de móvil.

Imagina que quieres mantener tu número de móvil «bueno» en secreto para servicios como Twitter o Facebook, y solamente usar tu número bueno para tema de bancos y cosas personales. Ahora no podrás poner el número de tu línea secundaria para validar el código con el mensaje SMS recibido, o usar servicios de recepción de mensajes SMS en Internet. Directamente las empresas sabrán sí o sí tu número de móvil.

Este servicio no funcionará si hacemos Tethering, si estamos en redes Wi-Fi o usamos conexiones VPN.

CarrierBillingCheckOut

Esta API permite proporcionar a las empresas la forma de que se paguen sus servicios a través de la factura del cliente del operador de telecomunicaciones. Actualmente existen diferentes servicios que se pueden pagar a través de la factura del operador, esto es un paso más allá ya que cualquiera que tenga acceso a Open Gateway, podrá cargar las compras que se realicen o se suscriban al contenido digital directamente en la factura.

La parte positiva es que tendremos una forma fácil y rápida de pagar, directamente en la factura. La parte negativa es que ha habido en el pasado muchos problemas con suscripciones que realmente no han sido realizadas por los clientes, bien por despiste o por desconocimiento, así que habría que mirar con mucho cuidado a partir de ahora esto, porque muchas más empresas se podrían adherir a esta API para vender sus servicios a través de la factura del operador.

Esta API no nos parece mal para quien quiera pagar los servicios a través de la factura de la compañía de telecomunicaciones, pero siempre que haya algún método de dar de baja que sea eficiente y fácil.

La neutralidad de la red en jaque

Hay algunas API de Open Gateway que están enfocadas específicamente a priorizar algunos servicios sobre otros en Internet, cuando se supone que hay una cierta «neutralidad» de la red. Esto choca frontalmente con este principio, ya que las empresas que paguen, tendrán una mejor conectividad, y las que no, funcionarán simplemente peor porque los que han pagado han «copado» todo el ancho de banda disponible.

QualityOnDemand

Esta API permite que las empresas soliciten una latencia estable o un rendimiento mínimo en términos de velocidad, todo gestionado por las redes de telecomunicaciones, sin la necesidad de tener un conocimiento avanzado de los sistemas 4G o 5G, ni tampoco de la complejidad global de los sistemas de telecomunicaciones. De esta forma, si una empresa como una industria de IoT, de juegos en realidad virtual, o transmisión de vídeo en tiempo real, necesitan una serie de requisitos específicos, podrán «configurar» la red para garantizarles una latencia mínima y una velocidad mínima para que estos servicios funcionen a la perfección.

Esta API lo que hará será priorizar los datos de las empresas que paguen por acceder a Open Gateway, el resto de empresas que no paguen tendrán el conocido como Best effort o «mejor esfuerzo», sin garantías de latencia ni tampoco velocidades mínimas.

• ¿En qué te afecta esto? La neutralidad de la red está en jaque, es posible que uses ciertos servicios que funcionarán muy mal debido a que otras empresas están pagando para tener la prioridad máxima. Imagina que vas en coche y pagas a la DGT para poder adelantar por la izquierda y derecha a la velocidad que quieras, y, además, te proporcionan una sirena en el coche para saltarte los semáforos. Llega un momento en que, si muchas empresas hacen esto, tú tendrás que ir más lento obligatoriamente, no se puede dar la máxima prioridad a todos. Cuando se prioriza un servicio siempre va a tener un impacto en los otros que no están priorizados.
• ¿Por qué le interesa al operador hacer esto? El operador recibirá ingresos por priorizar el tráfico de las empresas que paguen. Las empresas verán reducida la latencia y garantizada la velocidad. Todo el que quiera una conexión que funcione perfectamente, tendrá que pasar por «caja» del operador.

El principal problema de esto, es que habrá un Internet de primera y un Internet de tercera división. Mientras que los que paguen tendrán latencia y velocidad garantizadas, los que no lo hagan tendrán best-effort sin garantías de absolutamente nada. En la práctica podríamos ver que ciertos servicios funcionarán peor (los que no paguen).

APIs que creemos que sí son útiles

Hay algunas API de Open Gateway que sí consideramos interesantes y útiles con el objetivo de mejorar la seguridad de los usuarios o su conectividad, a continuación, os explicamos cuáles son y qué hacen exactamente.

DeviceStatus

Esta API es la menos «peligrosa» de cara a nuestra privacidad, básicamente lo que hace es decirle a la empresa o cliente que contrate Open Gateway, si el dispositivo final ha perdido la conexión a la red, se ha vuelto a conectar, e incluso si estamos en roaming. Ahora mismo, esta API solamente estará disponible para redes 4G y 5G, que al fin y al cabo es donde tiene sentido, aunque podrían añadir más funciones en el futuro para redes fijas.

Esto no afecta demasiado a la privacidad, porque actualmente los operadores ya saben si un cliente está en roaming, se ha desconectado de la red o si se ha vuelto a conectar. Además, creemos que es algo positivo porque así podrán detectar posibles problemas a nivel de red en ciertas ubicaciones. Apoyamos el uso de esta API con el objetivo de mejorar las redes, porque cuando detecte caída, se puede saber perfectamente cuál es la última antena de telefonía que se ha usado.

OTPvalidationAPI

Esta API se puede utilizar para enviar contraseñas de un solo uso (OTP) de corta duración a un número de teléfono a través de un SMS, y validarlo automáticamente, para proporcionar la prueba de posesión del número de teléfono. Otras características importantes es que puede realizar comprobaciones en tiempo real para verificar que el usuario que poseía el dispositivo lleva el número de teléfono móvil indicado. Esto permite proporcionar un OTP frecuente para añadir una capa de seguridad a diferentes servicios.

En la documentación oficial, indica que las contraseñas de un solo uso vía SMS es un método seguro para proporcionar acceso a una aplicación o realizar una transacción. Sin embargo, con la amenaza del Sim Swapping creemos que esto no es lo mejor, de hecho, por temas de seguridad, lo mejor es usar una aplicación autenticadora local e incluso una aplicación del propio servicio. Por ejemplo, el banco Caixabank nunca envía mensajes SMS, sino que todo se hace a través de su aplicación Caixabank Sign con nuestra contraseña o huella dactilar.

Este tipo de autenticación ya es algo que existe, pero ahora los fabricantes tendrán un acceso «nativo» para autenticar a los clientes. En nuestra opinión, esto no aporta nada nuevo actualmente, porque los SMS actuales ya hacen eso mismo, aunque sí es posible que ya no tengamos que introducir el código, sino que lo hará automáticamente.

SimSwap

Esta API es la más interesante de todas para hacer frente al SIM Swapping, uno de los principales ataques a los usuarios para robarles las claves por SMS (como recomienda la anterior API), y acceder a banca o servicios online con autenticación en dos pasos de este tipo. Tal y como hemos explicado antes, usar un método de verificación en dos pasos a través de un SMS no es nada seguro, pero esta API llamada SimSwap podría mejorar la seguridad.

El objetivo de esta API es solicitar la última fecha de intercambio de tarjeta SIM realizado en la línea móvil, o para verificar si se ha realizado anteriormente un intercambio de SIM durante un periodo anterior. Esto permite hacer una verificación en tiempo real sobre la fecha de activación de una nueva tarjeta SIM para un determinado número. Esta característica permite prevenir el fraude y reducir enormemente el riesgo de fraude.

Caso de uso práctico:

Imaginemos que un banco como BBVA (que sí manda mensajes SMS para ciertas cosas) compra el acceso a esta API de SimSwap, antes de enviar un mensaje SMS a un teléfono para comprobar su identidad, puede verificar si ha habido un cambio de SIM, y decidir no enviar ningún código SMS. Ejemplo de uso:

• Si ha habido un cambio de SIM en la última semana: no envía ningún código SMS y envía un error a través de la aplicación o la banca online.
• Si no ha habido un cambio de SIM desde hace 1 año o más: envía el código SMS porque ha comprobado que el teléfono (con mucha certeza) pertenece al cliente, y que no le han hecho un ataque SimSwap.

Aunque esta API es realmente interesante y mejora la seguridad frente a estas estafas, el SimSwap es algo que deben controlar muy bien los operadores para que nadie pueda cambiar la tarjeta SIM de un cliente y ocasionarle un agujero en la cuenta bancaria.

HomeDevicesQoD

Esta API es similar a la de QualityOnDemand, pero está enfocada en redes domésticas fijas con fibra óptica. Esto permite implementar políticas de gestión de tráfico además de los servicios de conectividad a Internet del operador. La API podrá configurar el router con el protocolo DSCP para priorizar cierto tráfico de red en descarga dentro de la red doméstica del usuario para un determinado dispositivo doméstico. Un aspecto muy importante es que el DSCP solamente prioriza el tráfico dentro de la red, no en la red del operador, además, solamente es capaz de priorizar la descarga de los datos (desde el router hasta el cliente), el perfil de tráfico solamente se aplica a los dispositivos domésticos que estén conectados por WiFi.

Esto es básicamente como tener configurado un QoS en el router, pero configurado por la aplicación o servicio que vayamos a utilizar. Podemos ver que este servicio, como una videollamada, funciona mucho mejor y de manera más fluida porque él mismo ha configurado el QoS de nuestro router de forma automática y completamente transparente.

• ¿En qué te afecta esto? Esto tiene sus puntos fuertes y sus puntos débiles. La parte positiva es que tendremos una mejor experiencia de usuario al realizar videollamadas, o jugar online, siempre que la empresa pague por el acceso a Open Gateway. La parte negativa es si estamos usando varios servicios de forma simultánea, cuando tenemos «prioridad alta» en muchos dispositivos, esto se traduce en que todos seguirán teniendo la misma prioridad porque no se puede priorizar a todos a la vez.
• ¿Por qué le interesa al operador hacer esto? El operador recibirá ingresos por permitir que la empresa pueda configurar el QoS del router utilizado por el cliente, y todo ello de forma transparente de cara al usuario.

Lógicamente si cambias el router del operador y compras uno por ti mismo, esta funcionalidad no la tendrás, tanto para lo bueno como para lo malo. Esta API lo que permite es mejorar el QoE (calidad de experiencia) del usuario para aquellos servicios que lo requieran, como llamadas VoIP o videollamadas entre otros usos.

EdgeCloud

Esta API permite proporcionar el router de borde más cercano al dispositivo desde donde se ha realizado la consulta, con el objetivo de optimizar al máximo la ruta desde el origen hasta el destino. Esto permitirá saber qué plataforma MEC está más cerca del cliente, para que tenga la mínima latencia y la máxima velocidad posible. Al estar más cerca físicamente, se reduce la latencia de propagación y de ida y vuelta de los datos, haciendo que tengamos menos latencia y también una mayor velocidad real.

• ¿En qué te afecta esto? La aplicación o servicio que uses te funcionará mejor, con una menor latencia y una mayor velocidad porque te conectarás directamente con el servidor más cercano, y no tendrá que conectarte a un servidor lejano.
• ¿Por qué le interesa al operador hacer esto? El operador recibirá ingresos por dar información sobre cuál es el servidor más cercano para una determinada aplicación. No obstante, esto es algo que ya se hace actualmente a través de protocolos de enrutamiento dinámicos de pasarela exterior como BGP, si el BGP está bien configurado, siempre se proporcionarán rutas óptimas. Esto parece que va un paso más allá para mejorar la experiencia de usuario final, ya que entrará en juego la geolocalización, y tendrá en cuenta el enrutamiento interno del AS de los operadores (que suelen usar IS-IS o OSPF).

Creemos que esta API es bastante interesante para proporcionar un servicio mejor y más rápido, pero que haya que pagar a los operadores para que tengamos estas mejoras, creemos que podrían hacerlo por defecto, porque esto también permitirá mejorar la eficiencia de sus redes, y evitar que ciertos nodos se colapsen porque todo el tráfico viaja por ellos, es un win-win, no obstante, no nos parece mal que quieran ganar más dinero brindando un «enrutamiento premium» para quien quiera pagarlo, pero siempre que no perjudiquen al resto que no paguen.

Conclusiones

Como hemos visto anteriormente, existen API que están enfocadas específicamente en violar la privacidad de los usuarios, recogiendo aún más datos de los que ya se recogen, y comerciando con los datos para venderlos al que pague por acceder a Open Gateway. Creemos que esta nueva tecnología podría ser muy peligrosa para la privacidad de los usuarios, porque ni siquiera podrás librarte de todas ellas usando redes VPN para enmascarar el tráfico, ya que se hará de forma nativa en tu smartphone a través de las antenas de los operadores.

Otras API están específicamente diseñadas para mejorar la experiencia de usuario final, pero el problema es que la neutralidad de la red podría verse muy afectada. Si las empresas y marcas pagan para tener la máxima prioridad, ¿qué pasará con las que no paguen? En cualquier QoS, si lo que se hace es priorizar el 80% del tráfico (los que paguen), para empezar ese tráfico no será prioritario y estaremos casi igualando la prioridad si no le aplicamos QoS, y el restante 20% podría ver la latencia de la conexión aumentada y también la velocidad será claramente inferior. Hay algunas API que sí consideramos interesantes en este aspecto, como la de HomeDevicesQoD para activar el QoS del router local y proporcionar un muy buen rendimiento por WiFi, y también vemos bastante bien la de EdgeCloud, pero siempre que no se perjudique el enrutamiento de las empresas que no vayan a pagar.

Por último, hay algunas API muy interesantes como la de SimSwap para prevenir fraudes, sin lugar a dudas, esta es nuestra favorita de todas ellas, porque permitirá que los bancos comprueben si ha habido un cambio de SIM reciente, para no enviar el código OTP vía SMS y mandar un aviso de alerta.