La retrocompatibilidad… Quién le iba a decir a mi yo de hace unos años que acabaría por ser un crítico a lo que a todas luces, en aquellos momentos, defendía a ultranza.
Pero los tiempos, amigo mío, han cambiado, y apenas tengo que tirar de una búsqueda en esta web para encontrarme con al menos una quincena de situaciones donde la retrocompatibilidad nos ha jugado unas malas pasadas.
Entre ellas, un problema que la electrónica de consumo hemos vivido durante muchísimos años: la fragmentación.
El que un sistema operativo tenga que operar en diferentes conjuntos de hardware hace que, lamentablemente, su evolución se vea cohibida por la dependencia de terceros. Ergo, al usuario final no le llegan las actualizaciones, y el ecosistema se vuelve poco a poco más inseguro, arrastrando una mochila histórica cada vez más pesada.
Linux, Windows, Internet y Android son ejemplos de entornos donde la fragmentación incide de una u otra forma. En el primero, debido a las múltiples distribuciones que hoy en día existen en el mercado. En el segundo, en base a la necesidad de ofrecer soporte para versiones antiguas, habida cuenta de que hasta Windows10 actualizar el SO costaba dinero y no era por tanto algo obligatorio. En el tercero por el propio caracter descentralizado de la web, que obliga a que hasta cierto punto versiones anteriores de protocolos de comunicación sigan estando disponibles durante muchísimos años para no romper el acceso a la información de proyectos que ya no tienen soporte. Y en el último, por la delegación en terceros (fabricantes) de la liberación de las actualizaciones que vienen firmadas de Google.
Precisamente sobre este último punto quería hablar en esta pieza, puesto que recientemente la compañía ha publicado en el blog para desarrolladores (EN) una serie de decisiones que algunos llevamos mucho tiempo demandando.
A saber:
- Para agosto de 2018 toda aplicación nueva en el market de Google deberá ser compatible con Android 8 Oreo: Lo que en la práctica significa que deben abrazar las últimas APIs (level 26 o superior) de Android, abandonando aquellas hoy en día consideradas deprecated y que aun así el sistema está forzado a mantener retrocompatibilidad. Si la aplicación ya estaba en el market, han dado unos meses extra para actualizarla (hasta noviembre).
- Para agosto de 2019 todas las apps deben ser compatibles con arquitectura de 64 bits: Una funcionalidad que en Android lleva presente desde Lollipop (Android 5), y que ya iba siendo hora de forzar. Lo que permitirá, de hecho, abandonar el desarrollo para 32 bits ahora que ya prácticamente cualquier dispositivo es capaz de operar a 64.
- Para 2018 Google tiene planeado añadir un sello de confianza a la firma de las aplicaciones: Algo que seguramente viene dado por la grave vulnerabilidad que hace apenas un par de semanas conocíamos (Janus Vulnerability (EN)) y que permitía a un atacante hacerse pasar por una aplicación legítima a ojos de los sistemas de seguridad de Google Play (la firma del APK era la misma), cuando realmente lo que instalaba el usuario estaba oculto en un fichero DEX.
Retrocompatibilidad pero con matices
Y los tres movimientos me parecen un gran acierto.
Por un lado, hablamos de crear un nuevo ecosistema en el que la retrocompatibilidad seguirá estando presente… siempre y cuando no entre en conflicto directo con las nuevas versiones del sistema operativo. La mayoría de problemas de seguridad que tenemos hoy en día se deben, precisamente, a este hecho (vulnerabilidades que ya han sido parcheadas en las nuevas versiones pero que seguirán presentes en todo el parqué de dispositivos ya que éstos jamás recibirán dicha actualización).
De esta manera, se modulariza el SO, y aunque sea, se fuerza a que el ecosistema de aplicaciones esté actualizado a las versiones grandes del mismo. Dan además algo más de un año para actualizarse, así que tampoco debería haber mucha excusa por parte de los desarrolladores al respecto (si tu negocio es vivir de las aplicaciones, te va a tocar mantenerlas actualizadas, lo que por otro lado debería ser lo habitual).
El tema del certificado de firma me parece además muy interesante, aunque lamentablemente hay poca información aún al respecto. Por lo que conocemos, no será algo que dependa del desarrollador. Dentro del APK Signing Block incluirán a partir de 2018 una serie de metadatos que, entiendo, tendrán como objetivo hacer de capa extra para legitimar ese desarrollo frente a copias de terceros, como hoy en día ocurre con las etiquetas en productos físicos.
Con estos cambios Android no va a solucionar el problema de la fragmentación, pero al menos sí va a limitar su alcance.
Pese a todo, sigo diciendo que el futuro del ecosistema Android debería ir ligado a Android One. Ese programa del cual ya disfrutamos algunos, y que fuerza al fabricante a mantener al menos durante dos años envíos mensuales de las actualizaciones de seguridad al cliente final.
Sin ir más lejos, mi Xiaomi Mi A1 ya recibió la de Diciembre (EN) a principios, que solventaba precisamente, y entre otras cosas, la vulnerabilidad Janus anteriormente comentada.
Un pasito más para atacar ahí donde la competencia (iOS) es fuerte. Porque en materia de seguridad, no hay nada mejor que ser dueño y señor de todo el ecosistema, gobernando con mano férrea y dictando lo que se puede o no se puede hacer.
Algo en lo que Apple es ejemplo a seguir. Que tiene su lado negativo (dependencia absoluta del proveedor de software, menor capacidad de innovación y evolución más lenta), pero que saca pecho cuando se trata de ofrecer en todo momento la mejor cara del producto.
