En el 2012 escribí un artículo sobre las novedades que traía la nueva versión de Android (por aquel entonces la 4.2), sorprendiéndome cómo en este caso habían apostado por un elemento tan crítico y a la vez tan desprestigiado como era el tema de la seguridad.
Android 4.2 incluía por primera vez un sistema anti-malware en Google Play, o lo que es lo mismo, una capa inicial que intentaba minimizar el aún alarmante porcentaje de malware con el que cuenta la plataforma de aplicaciones móviles de Google.
Influenciados seguramente por la compra de nuestros amigos de Virus Total, lo cierto es que solo esta noticia me motivó a pensar en ese futuro hipotético en el que la seguridad fuera considerada un elemento más de venta.
Lo que vino más tarde, es historia.
La industria del malware ya existía, como también los abusos masivos de privacidad, pero ambos dos vivían en una suerte de escenario donde el riesgo no era cuantificable, o al menos, no llegaba a ser considerado por el usuario final.
Tres años más tarde, llega a algunos modelos la versión 6.0 de Android. Y curiosamente, el eje principal del discurso, es la seguridad.
No una parte más de todas las novedades, sino prácticamente el eje principal. Un cambio de paradigma que me gustaría resumir en 5 puntos principales.
Empecemos.
Índice de contenido
1.- Administrador de permisos en stock
El administrador de permisos era uno de los dos grandes puntos pendientes de Android (el otro es, como bien sabe, la fragmentación).
La cuestión es que prácticamente cualquier aplicación actual está pidiendo una cantidad insana de permisos, simplemente porque pueden (incluyes la petición por si acaso), y porque el usuario, o las acepta todas, o no puede instalarla.
La presión ejercida por ese grupo cada vez mayor de usuarios que exigimos un sistema más seguro se veía hasta ahora equilibrada por la propia costumbre (cuesta menos seguir como hasta ahora que ponerse a implementar sistemas como estos, que deben cambiar todo el sandbox donde se ejecutan las apps), y por la presión que habitualmente hace la comunidad de desarrolladores (puesto que permitir que sea el usuario quien decida qué permisos deja y cuáles no, hace en la práctica más inestable el producto final).
Para generar por tanto un administrador de permisos eficiente, es necesario que en cualquier causística, el desarrollador haya incluido excepciones que le permitan gestionar en la medida de lo posible el buen desempeño de la aplicación cuando alguno de esos permisos falten.
Esto pasa porque sea el administrador capaz de avisar a la aplicación de turno de que no tiene derecho a acceder a la localización (por ejemplo), y la aplicación haya considerado esto en su código para evitar lecturas absurdas o cierres forzosos.
¿Qué nos encontramos en Android Marshmallow?
Un administrador bastante logrado, que ni es el primero ni será el último, pero que al menos vendrá por defecto en Android.
Seguimos teniendo que aceptar todos los permisos a la hora de instalar la aplicación (mal hecho, Google), pero por lo menos al momento ya podremos elegir cuáles aceptamos, cuales queremos que nos alerten con un mensaje para pedirlos, y cuales directamente le estamos negando. Ojo, no deja administrar absolutamente todos (por ejemplo, no deja cambiar la configuración del permiso de despertar el sistema), sino únicamente los que habitualmente ofrecen mayor riesgo para la seguridad y privacidad de nuestros datos (y de nuestra cartera).
Es una acción voluntaria por parte del usuario, ya que por defecto seguiremos cediendo todos los permisos que haya pedido el desarrollador, pero es un paso. De hecho, es bajo mi humilde opinión la mejor de las posibles soluciones a este problema.
Y esto es importante, ya que por primera vez hay la presión suficiente para que las aplicaciones incluyan esas excepciones que ahora mismo están haciendo el sistema inestable en ROMs como la de Flyme o CyanoGen, que llevan ya tiempo ofreciendo este aliciente.
La pelota está en el tejado de la comunidad de desarrolladores, y con ello, el usuario adquiere mayor control de la información que cede en todos estos desarrollos.
2.- Suspensión forzada gestionada a bajo nivel
Hablé de Doze cuando lo presentaron en el último Google IO, y lo tenemos presente en esta nueva versión del SO móvil.
La sorpresa ha sido que Google obligará a los fabricantes a que Doze funcione forzosamente en los terminales, aunque la ROM desarrollada por el fabricante ya incluya una funcionalidad parecida (esto es, a bajo nivel, ergo más seguro).
El dispositivo aprenderá de nuestro uso, y gestionará una especie de suspensión de aplicaciones mientras no lo usamos, sin que por ello dejen de llegar las notificaciones.
Es de nuevo un ejemplo de ruptura de libertad de stakeholders (Android hace tiempo que dejó de ser abierto) a cambio de un mayor control de la plataforma, que asegurará un mayor rendimiento de la batería, y de paso, el control de posibles malwares que hayan saltado los controles y operen por ejemplo como botnets.
3.- Cifrado por defecto de la memoria interna
Temía hablar de esto, habida cuenta de que se suponía que iba a venir obligatoriamente implementado en versiones anteriores, y que nuevamente por la presión del resto de la cadena, se dejó a elección de cada fabricante.
Google vuelve a atacar obligando el cifrado por defecto, lo que a priori podría hacer reducir ligeramente el rendimiento de los dispositivos (el usuario únicamente podría notarlo en procesos terriblemente exigentes, pero hay que reconocer que un disco cifrado es más costoso de trabajar que uno sin cifrar).
¿A cambio? Un elemento crítico tanto para proteger la fuga de información por fallos de sandbox (ej. tapjacking), como para evitar problemas mayores el día en que extraviemos el terminal (o nos lo roben).
Y un paso más cerca de esas comunicaciones cifradas por defecto, como medida necesaria para salvaguardarnos del abuso reiterado de gobiernos y corporaciones.
4.- Control de la experiencia y confianza del sistema de autenticación
O lo que es lo mismo, unos requisitos mínimos en terminales Android con sistema de huella dactilar.
Las APIs de Android que gestionan este tipo de sistemas de autenticación serán lo suficientemente estrictas para requerir funcionar en sistemas que tengan un margen de falsos positivos menor del 0,002%, de falsos rechazos inferior al 10%, y una latencia inferior a un segundo desde que se coloca el dedo en el sensor.
El patrón de la huella no debe salir del entorno de seguridad (Trusted Execution Enviroment), para evitar cualquier alteración del mismo, y únicamente podrá incluirse huellas nuevas estableciendo la identificación afirmativa el usuario (por ejemplo, con un sistema de autenticación basado en el conocimiento previo).
Además, ahora las ROMs de los fabricantes están obligadas a establecer un sistema de restricción temporal frente a ataques de fuerza bruta, cosa que hasta ahora no era estrictamente necesario.
Cada cinco intentos fallados, el sistema debe bloquearse un mínimo de 30 segundos, pudiendo aumentar este tiempo conforme más fallos haya.
5.- El compromiso de actualizaciones de seguridad periódicas
Sería el quinto y último elemento que nos trae Android 6.0, y es que ahora, desde ajustes, junto con el número de la versión que tengamos instalado, nos aparecerá la fecha de la última actualización de seguridad.
La idea de Google es liberar mensualmente parches de seguridad, en una estrategia por minimizar posibles futuras vulnerabilidades masivas, como ocurría recientemente con Stagefright.
Pero claro, aquí volvemos a lo de siempre. Esas actualizaciones dependen también del fabricante, y por ende, una cosa es que Google las libere y otra muy distinta es que nos lleguen.
Parece que hay algunos fabricantes (Samsung, HTC,…) que han acordado apostar por la liberación continua de parches de seguridad. Pero por ahora es un simple compromiso, que sin duda estará presente en terminales Nexus, y que falta por ver realmente en el resto.
En definitiva, movimientos de una empresa sabedora de la necesidad de vender productos afines con las preocupaciones del usuario, que han cambiado (y de qué manera) en apenas tres años.
5 tips que benefician al usuario final sin que por ello reste la experiencia de uso. Algo que lamentablemente no vemos todos los días.
