Cuando instalamos una aplicación en nuestro smartphone, se nos informa de qué tipo de permisos requiere para su funcionamiento.
El principal inconveniente de esto es que se trata de una simple pantalla de aviso: Te informa de los permisos que usará, pero no puedes hacer nada más que aceptarlos todos, o directamente no instalarlo sino estás de acuerdo.
Además, esto se junta a la tendencia cada vez mayor de agregar permisos «por si las moscas«, como el ejemplo del típico reloj que tiene acceso a tus contactos y a mandar SMS (quién sabe, quizás el día de mañana queramos poder avisar a nuestros amigos de qué hora es…).
Esta es una de las razones de más peso para considerar Android un sistema no tan seguro como el de la competencia. No me malinterpretéis, con ello no estoy diciendo que iOS sea más seguro, puesto que éste también peca lo suyo en su tendencia a la simplificación máxima, por ejemplo con la gestión de redes WIFI.
La solución al control de permisos en el sandbox de Android que a todos se nos ha ocurrido alguna vez la implementó hasta hace relativamente poco CyanogenMod, la popular ROM que añade varias características únicas a la distribución base de Google, entre las que destacaba el derecho de cada usuario a elegir qué permisos cedía a qué aplicaciones y cuáles no.
La nueva versión ya no cuenta con esta característica, lo cual ha llevado a un aluvión de quejas por parte de los heavy users, al ser privados de una característica a priori muy útil.
Parece una trivialidad, pero este servicio obligaba a «engañar» a las aplicaciones suministrándoles datos erróneos (puesto que en caso contrario, la mayoría de las aplicaciones directamente no funcionan), de tal forma que minimizaba lo mejor posible los fallos ocasionados de negarle uno u otro permiso. Como se puede entender, esto generaba un sistema hostil para las aplicaciones en Android, que mostraban errores y cierres de servicio que no había sido contemplados por los desarrolladores (lo único que puedes tener claro en la fase de testing es que el propio sistema no te engañe, cosa que aquí ocurría).
Por ello, coincido con las palabras de Steve Kondik (EN), la cara visible detrás de CyanogenMod, cuando habla de que el futuro de Android pasa por el desarrollo de APIs propias para que sean los desarrolladores quien gestionen redes privadas virtuales en cada aplicación.
Para que nos hagamos una idea, una VPN no es más que una red privada que utiliza la infraestructura de una red pública para conectarse entre otros terminales o servicios. A partir de la 2.3.5 (creo recordar, perdón si me equivoco), todos los Android tienen la capacidad de crear VPN propias, de tal manera que es el propio usuario quien gestiona las funciones y conexiones que se hacen en su pequeña red, un subdominio de su conexión 3G-4G, y de manera totalmente transparente.
Técnicamente, una VPN genera un túnel de conexión cifrado entre el cliente y el servidor, de tal manera que a efectos prácticos, nos conectamos a los servicios del servidor desde una dirección distinta, y los datos viajan seguros de miradas ajenas, como sería el caso en una conexión ordinaria y el propio operador.
Históricamente, las VPN se han usado para conexiones seguras en empresas, de tal manera que un trabajador podía conectarse a los servicios internos de la misma desde cualquier dispositivo acreditado, aprovechando la infraestructura masiva de internet y con la seguridad del cifrado.
Seguramente si estáis en este mundillo, habréis pensado que lo mismo lo podemos obtener mediante un proxy, aunque este hecho no es del todo correcto. En una conexión proxy, podemos navegar de forma anónima por la red, pero no mandar mails o chatear anónimamente, cosa que sí ocurre en una VPN, por lo que se transforman en herramientas muy útiles para salvar las absurdas restricciones geográficas de servicios de internet (bien sea por decisión de la propia compañía, o por regímenes autoritarios y censura).
Volviendo al tema que nos compete, el gran inconveniente de esto es la configuración inicial de VPN, que requiere cuanto menos un poco de conocimientos de redes, y a la que lamentablemente, no existe un método estandarizado de uso para desarrolladores.
Por ello, es bastante probable que ese pie cojo que tiene Android con la seguridad se equilibrara con la implantación de una API de gestión de VPN para aplicaciones, de tal manera que cada aplicación generaría su propia red cifrada según los permisos que necesita, estandarizando el envio de datos, y volviendo al SO de Google uno de los más seguros.
For starters, we need an API that lets an application (after manual user consent) manage the IPTables rules on the device. This is insanely powerful, and would enable an entirely new class of applications that can enable transparent proxies, Tor, general firewall rules, traffic shaping, and packet inspection. Could we build something that actually detected packets of data flowing to another country which contained all of your contact data, and notify the user and block the connection if desired? This would be a great thing for CM to have.
Hablaríamos entonces de apps que podrían funcionar como cortafuegos, notificando al usuario de qué datos están intentando salir. Un camino alternativo que seguir, alejado de los actuales permisos, y que devolvería el derecho al anonimato que en parte hemos perdido con este «vive la vida» de conexiones inseguras y constantes a servicios externos del smartphone.
Y esto se podría extrapolar a cualquier sistema operativo (aunque entiendo que si alguien debe dar el primer paso, ese debe ser un SO basado en open source como Android).
