Sideloading en Android: seguridad frente a libertad del usuario

Google acaba de dificultar bastante la instalación de apps fuera de Play Store. Su nuevo proceso exige un periodo de espera de 24 horas para las apps sideloaded que Google Play Protect no ha verificado, durante el cual el APK se sube a los servidores de Google para ser analizado. Si instalas una app de una fuente externa, tienes que esperar un día completo antes de poder usarla. La justificación de seguridad es sencilla: los APK con malware son un problema real, sobre todo en regiones donde el sideloading es habitual. La reacción de desarrolladores y usuarios avanzados ha sido... bastante menos entusiasta.

Cambio de este tipo se sitúa en el centro de una tensión que ha definido a Android desde sus inicios: ¿cómo dar a los usuarios la libertad de instalar lo que quieran y, al mismo tiempo, proteger a quienes no saben lo que hacen? Android lleva 18 años iterando sobre esta pregunta, y la respuesta no deja de cambiar.

Breve historia de la instalación de apps en Android

Los primeros Android eran básicamente el Salvaje Oeste. Cualquier app podía instalarse desde cualquier origen con un solo toque. El interruptor «Orígenes desconocidos» en los ajustes era un interruptor global: si lo activabas, cualquier app del dispositivo podía instalar APK. Era sencillo, daba poder al usuario y era una auténtica pesadilla de seguridad.

Android 8 (Oreo, 2017) pasó a los permisos por origen. En lugar de un interruptor global, cada app tenía que solicitar individualmente el permiso «Instalar apps desconocidas». Tu navegador podía tener permiso para instalar APK mientras tu cliente de correo no. Fue una mejora real, porque limitaba el alcance de daño de una app comprometida.

Android 13 añadió los ajustes restringidos. Las apps sideloaded no podían acceder a determinadas APIs sensibles (servicios de accesibilidad, escuchas de notificaciones) sin que el usuario pasara por cuadros de confirmación adicionales. La lógica: las apps de fuera de Play Store no han pasado ningún control, así que no deberían tener acceso fácil a los permisos más potentes.

Ahora, el periodo de verificación de 24 horas añade otra capa de fricción. Cada iteración hace el sideloading más difícil, y cada una se justifica con datos reales de seguridad. La cuestión es si la fricción acumulada ha cruzado la línea que va de «proteger a los usuarios» a «obligarlos a irse a Play Store».

Por qué el sideloading es un problema de seguridad real

Antes de descartar las preocupaciones de Google: el malware distribuido por sideloading es un problema genuino y a gran escala. Los propios datos de Google muestran que las apps instaladas fuera de Play Store tienen 50 veces más probabilidades de contener malware que las de Play Store. En mercados como el sudeste asiático, donde las tiendas de apps de terceros son populares, las tasas de infección son bastante más altas que en mercados dominados por Play Store.

El vector de ataque es desesperantemente eficaz. Un usuario recibe un mensaje (WhatsApp, SMS, correo) con un enlace para descargar una «actualización de seguridad del banco», un «limpiador de teléfono» o una «app premium gratis». Descarga el APK, ignora las advertencias de seguridad (porque se ha acostumbrado a ignorar advertencias) y lo instala. El malware obtiene acceso al servicio de accesibilidad (de nuevo, convenciendo al usuario para que lo conceda) y pasa a robar credenciales bancarias, interceptar códigos de verificación por SMS o cifrar el dispositivo para pedir rescate.

Estos no son ataques sofisticados. Funcionan porque la ingeniería social es muy eficaz y porque la mayoría de los usuarios no entiende el modelo de riesgo de instalar código arbitrario. La postura de Google es que la fricción (hacer el sideloading más lento y difícil) es la defensa más eficaz, porque da tiempo al usuario para reconsiderarlo y a Google para analizar el APK.

Por qué los desarrolladores están frustrados

La oposición de los desarrolladores no va de malware. Va de control, distribución y de la creciente fricción para llegar a los usuarios fuera del ecosistema de Google.

• Pruebas y desarrollo. Los desarrolladores hacen sideloading constantemente durante el desarrollo. Esperar 24 horas por cada build de prueba es absurdo. Google exime de la espera a las apps instaladas mediante ADB (Android Debug Bridge), pero no todos los flujos de pruebas usan ADB: equipos de QA, betatesters y demos para clientes suelen instalar APK directamente.
• Distribución empresarial. Las empresas que distribuyen apps internas fuera de Play Store (gestionadas mediante soluciones MDM) se encuentran con fricción adicional. Aunque los MDM empresariales pueden saltarse algunas restricciones, las organizaciones pequeñas sin infraestructura MDM sí se ven afectadas.
• Tiendas de apps alternativas. F-Droid, Amazon Appstore, Samsung Galaxy Store: todos estos canales legítimos implican sideloading desde la perspectiva de Google. Cada restricción adicional empeora su experiencia de usuario frente a Play Store, que es exactamente lo que los críticos acusan a Google de querer.
• Cumplimiento normativo. La Ley de Mercados Digitales (DMA) de la UE exige a los guardianes de acceso (incluido Google) permitir el sideloading sin fricciones indebidas. Empeorar sustancialmente el sideloading manteniéndolo técnicamente posible es justo el tipo de teatro de cumplimiento que la DMA pretendía evitar.

Los problemas más profundos del modelo de permisos

Las restricciones al sideloading son un parche sobre un problema más profundo: el modelo de permisos de Android pide a los usuarios que tomen decisiones de seguridad para las que no están preparados. «¿Permitir que esta app acceda a tus contactos?» «¿Permitir que esta app lea tus SMS?» «¿Permitir que esta app use servicios de accesibilidad?». La mayoría de los usuarios no entiende las implicaciones y acaba aceptándolo todo o denegándolo todo.

El problema central: los permisos se plantean como decisiones binarias sobre capacidades, cuando los usuarios piensan en términos de finalidades. Un usuario no quiere decidir si una app puede leer SMS. Quiere decidir si la app puede verificar su número de teléfono (razonable) o interceptar los códigos de dos factores de su banco (no razonable). Ambas cosas requieren el mismo permiso.

<!-- AndroidManifest.xml -->
<!-- Both of these use the same permission: -->
<uses-permission android:name="android.permission.READ_SMS" />
<!-- Use case 1: Auto-fill SMS verification code during signup -->
<!-- Perfectly legitimate, saves the user time -->
<!-- Use case 2: Intercept banking 2FA codes and forward to attacker -->
<!-- Malware, obviously -->
<!-- The permission system can't distinguish between these.
The user is asked to make a security decision that requires
understanding the app's implementation, which they can't see. -->

iOS «resolvió» esto no permitiendo el sideloading en absoluto (hasta que la presión regulatoria obligó a introducir alternativas limitadas). Es un enfoque legítimo, porque quita la decisión de las manos del usuario, pero tiene sus propios costes: dependencia del desarrollador, rentismo de la App Store y la imposibilidad de ejecutar software que Apple no ha aprobado.

Cómo podría ser un sistema mejor

Ni el enfoque de iOS de «nada de sideloading» ni el de Android de «sideloading con fricción creciente» son ideales. Un sistema mejor tendría que abordar varias cosas a la vez.

• Fricción proporcional al riesgo. Una app que no pide permisos peligrosos y está firmada por un desarrollador conocido debería instalarse al instante. Una app que solicita servicios de accesibilidad, acceso a SMS y permisos de administrador del dispositivo debería someterse a más escrutinio. El sistema actual aplica la misma fricción a una calculadora de código abierto inofensiva que a una app ávida de permisos que pide todo.
• Permisos ligados a una finalidad. En lugar de conceder «leer SMS» de forma amplia, conceder «leer SMS para autocompletar el código de verificación»: un permiso acotado que solo puede usarse en contextos concretos de la API. Android ha avanzado en esa dirección con la API SMS Retriever, pero la mayoría de los permisos siguen siendo muy amplios.
• Análisis transparente sin esperas. Subir y analizar es razonable. Una espera de 24 horas no lo es, sobre todo cuando la mayoría de los análisis terminan en minutos. Muestra al usuario el resultado del análisis, deja que continúe de inmediato si está limpio y avisa si el análisis detecta problemas.
• Paridad entre la tienda oficial y las de terceros. Si Play Store puede instalar apps al instante, las tiendas alternativas también deberían poder hacerlo, siempre que implementen controles de seguridad equivalentes. El argumento de la seguridad solo se sostiene si las restricciones se refieren a la seguridad y no a la ventaja competitiva.

Qué deberían hacer los desarrolladores ahora

Independientemente de lo que pienses del enfoque de Google, la realidad práctica es que la fricción del sideloading está aumentando y es poco probable que disminuya. Si distribuyes apps fuera de Play Store, planifícate para ello.

1. Usa el programa Play App Signing. Las apps firmadas a través del programa de Google pueden encontrar menos fricción en la verificación del sideloading, porque Google puede comprobar la firma frente a claves conocidas.
2. Para desarrollar, usa ADB. Las apps instaladas con ADB se saltan la espera de 24 horas. Asegúrate de que tus pipelines de CI/CD y tus flujos de pruebas usen ADB en lugar de instalar APK directamente.
3. Considera las Progressive Web Apps. Para las apps que no necesitan una integración profunda con la plataforma, las PWA evitan por completo la tienda de apps y la cuestión del sideloading. Se instalan desde el navegador, se actualizan automáticamente y no requieren permisos especiales para instalarse.
4. Si gestionas una tienda alternativa, implementa un análisis robusto. Las tiendas que demuestran buenas prácticas de seguridad podrían obtener en algún momento exenciones o menos fricción, porque el entorno regulatorio empuja en esa dirección.
5. Comunica los retrasos a los usuarios. Si tu distribución depende del sideloading, avisa a los usuarios de la espera de 24 horas desde el principio. Un retraso previsto frustra menos que una sorpresa.

La apertura de Android siempre ha sido un espectro, no un absoluto. Cada versión ha desplazado ese espectro un poco más hacia el control, justificada por preocupaciones de seguridad reales y criticada por coincidir de forma muy conveniente con intereses comerciales. El retraso de 24 horas en el sideloading es el último punto de esta trayectoria, y probablemente no sea el último. Si lo ves como una protección razonable o como una fricción artificial depende en buena medida de dónde creas que debe estar el equilibrio entre seguridad y libertad. Pero la realidad técnica es clara: se acabaron los días del sideloading sin fricción en Android, y los desarrolladores tienen que adaptar sus estrategias de distribución en consecuencia.