- Google comenzó a aplicar recientemente una política de restricciones a la instalación manual de apps en Android, lo que ha ampliado el debate sobre la autonomía digital de los usuarios y la apertura del ecosistema móvil
- En un programa piloto en Singapur, se reforzó la regulación al bloquear la instalación de apps recibidas por web, mensajería o administradores de archivos que soliciten permisos sensibles (como SMS o accesibilidad)
- Con la introducción de la Play Integrity API, los desarrolladores pueden limitar funciones de apps instaladas manualmente, lo que refuerza una estructura de distribución cerrada y centrada en Google Play Store
- Aunque estas medidas pueden contribuir a mejorar la seguridad, también han surgido críticas porque debilitan la innovación y la competencia, y erosionan la apertura de Android
- Purism propone como alternativa móviles de código abierto y centrados en la privacidad como PureOS y Librem 5, garantizando la soberanía de los datos del usuario y un entorno libre para instalar aplicaciones
Google introduce restricciones a la instalación manual de apps en Android
- Google empezó recientemente a aplicar nuevas restricciones a las apps instaladas manualmente en Android, citando motivos de seguridad
- La política piloto en Singapur fue implementada en colaboración con una agencia de ciberseguridad, y en particular restringe la instalación, a través de navegadores web, apps de mensajería y administradores de archivos, de aplicaciones que soliciten permisos sensibles como acceso a SMS o servicios de accesibilidad
- La medida tiene como objetivo prevenir delitos mediante fraudes y malware
Play Integrity API y dependencia de la tienda de apps
- Al introducir la Play Integrity API, Google permite que los desarrolladores limiten algunas funciones cuando una app haya sido instalada manualmente
- Estas políticas presionan a los usuarios para que instalen apps solo por la vía oficial de Google Play Store
- Aunque en apariencia se presentan como una forma de reforzar la seguridad, en la práctica terminan fortaleciendo el control de Google sobre el ecosistema Android
- Como resultado, han resurgido preocupaciones sobre la autonomía digital, la innovación y los derechos de los usuarios
Críticas e impacto
- Los críticos señalan que, si bien la política puede ayudar a bloquear apps maliciosas, al mismo tiempo plantea problemas de restricción de la competencia y reducción de la capacidad de elección del usuario
- La característica apertura de la plataforma Android y la libertad de instalación manual se debilitan, empujando al sistema hacia una dirección similar al ecosistema cerrado de Apple iOS
- Existe la posibilidad de que esta tendencia termine derivando en menos innovación y en un monopolio de la distribución de aplicaciones
La alternativa de Purism: PureOS y Librem Phone
- Frente al aumento de la vigilancia y el control corporativo, Purism presenta una solución centrada en la privacidad
- PureOS es un sistema operativo Linux basado en Debian, incluido en Librem 5 y Liberty Phones, que garantiza plena autonomía del usuario y soberanía sobre sus datos
- Este entorno solo admite apps de seguridad de código abierto que no usan publicidad dirigida, minería de datos, algoritmos adictivos ni manipulación del comportamiento
- Los usuarios pueden disfrutar de una experiencia de cómputo más transparente y segura sin depender de tiendas de apps corporativas ni APIs invasivas
Conclusión: la importancia de las alternativas abiertas
- Mientras Google vuelve el ecosistema Android cada vez más cerrado, Purism apuesta por un entorno de computación móvil ético, seguro y abierto
- Las alternativas enfocadas en la soberanía del usuario y la privacidad están emergiendo como una opción importante para la industria tecnológica y los desarrolladores
3 comentarios
En realidad, con la carga lateral basta con implementar un “esquema de firmantes confiables” y abrirlo a certificadores externos como DigiCert; así al menos se puede verificar si es un APK confiable. El problema es que Google dejó esto en manos de la Play Store. Pero si preguntas si Google Play Store detecta bien las apps maliciosas, pues quién sabe, y las apps que van contra las políticas de Google Play......
El texto en sí parece tener una intención cuestionable, pero es cierto que en el uso real cada vez se vuelve más molesto.
De hecho, en los dispositivos Galaxy ya dejaron configurado que ni siquiera se pueda desactivar esa función de bloqueo de apps sospechosas o malware. Hay formas de saltárselo, pero cada vez agregan más regulaciones de este tipo.
Para los usuarios casuales, que casi no usan el sideloading y pueden evitar la ejecución de malware, puede ser una buena función, pero al menos no deberían permitir desactivarla?
Quería que Pixel se lanzara oficialmente, pero si Google también va a hacer algo parecido...
Opiniones en Hacker News
Se comenta que resulta muy extraño el momento en que publicaron esta entrada del blog; surge la duda de si era un texto preparado hace meses y recién lo hicieron público ahora. También se comparte que este programa piloto fue anunciado en Singapur hace 1 año y 4 meses, que se limita a Singapur y a apps que requieren permisos específicos, como
RECEIVE_SMS,READ_SMS,BIND_NOTIFICATIONSo permisos de accesibilidad, y que solo aplica a apps descargadas directamente fuera de una tienda de aplicaciones. Se aclara que instalar mediante F-Droid oadbva por un camino aceptable, que se puede intentar eludirlo desactivando Play Protect aunque no está claro si eso realmente funciona en Singapur, y que, de forma curiosa, Google impidió desactivar Play Protect durante una llamada, algo que consideran una decisión sensata. También se cita un comunicado de la policía de Singapur según el cual este enfoque no ha dado resultados particularmente efectivos en la práctica: a las víctimas se les indica desactivar Google Play Protect antes de instalar el APK, e incluso instalar una app VPN, con lo que los estafadores logran saltarse las tecnologías de protección bancaria (https://police.gov.sg/media-room/news/…)Se menciona que hay datos que muestran que la gente en Singapur es especialmente vulnerable a las estafas: decenas de miles de personas fueron afectadas el año pasado y perdieron en total 1.1 mil millones de dólares singapurenses, un aumento del 70% interanual. También se comparte la experiencia de que, según estadísticas de la Global Anti-Scam Alliance, la cifra real probablemente sea mayor que la de los casos reportados. Se explica que Singapur se vuelve un objetivo por su nivel de riqueza, digitalización y cultura de cumplimiento normativo (https://archive.is/fCmW1)
Se opina que no está claro por qué la publicación del blog de Purism salió justo ahora, y que probablemente sea solo FUD con fines de marketing. Se menciona directamente a los teléfonos Librem 5 y Liberty basados en PureOS, preguntándose incluso si pueden ejecutar APK. Se añade que solo Sailfish ofrece algo así, aunque como una excepción por temas de licencia. También se reconoce que Purism ha invertido bastante en el desarrollo de Linux táctil como Phosh, pero se recalca que el entorno táctil de Linux sigue siendo muy deficiente. Se considera que el texto intenta retratar mal a una alternativa mainstream para promocionar sus propios productos, pese a que no se trata de una situación que los afecte directamente.
Se plantea que es importante distinguir si esto ocurrió antes o después del fallo adverso para Google en el litigio relacionado con App Store. Se subraya lo difícil que es encontrar un equilibrio entre proteger a los usuarios y preservar su libertad. También se menciona que, cuando la gente se acostumbra a las advertencias de seguridad, acaba ignorándolas. Se agrega que ni siquiera la Play Store puede considerarse completamente segura, y que incluso datos públicos de GPS de usuarios de Android mostrarían comportamientos maliciosos por parte de apps oficiales. La conclusión es que quizá la alternativa sea permitir que un tercero inteligente y confiable tenga privilegios de administrador del dispositivo para proteger a los usuarios más vulnerables.
Se dice que el texto se siente más como publicidad de Purism que como contenido sustancioso.
Al darse cuenta de que era un anuncio, una persona concluyó que todo el contenido carecía de valor y pidió un mejor enlace.
A juzgar por la cantidad de votos positivos, se piensa que mucha gente está preocupada por la dirección que está tomando Android y tiene interés en alternativas.
Se pregunta si este tema no era en realidad de 2024 (https://techcrunch.com/2024/02/…)
Sobre el programa piloto introducido primero en Singapur, se explica que el bloqueo solo aplica cuando una app que solicita ciertos permisos —como SMS o accesibilidad— se instala a través del navegador web, mensajería o el administrador de archivos. Se señala que hay muchas condiciones, así que los usuarios avanzados probablemente aún podrán instalar las apps que quieran. Se interpreta como una medida pensada para evitar que el usuario promedio haga sideloading fácilmente de apps riesgosas con permisos de SMS o accesibilidad. También se enfatiza que se implementa en colaboración con la Agencia de Ciberseguridad de Singapur para prevenir estafas y malware, lo que explicaría por qué está limitado a ese país.
Se advierte que este tipo de restricción sí puede funcionar de forma anticompetitiva en el mercado masivo: aunque una minoría con conocimientos técnicos pueda instalar apps, la mayoría quedará dentro del “corral” controlado por Google. También se subraya que Google y Apple usan lenguaje alarmista hacia apps de terceros para generar barreras psicológicas, algo que se describe como una forma de “control mental” que debería eliminarse mediante regulación.
Se insiste en que el hecho de que esté “limitado a Singapur” no es motivo suficiente para sentirse tranquilo. Como el navegador y el administrador de archivos son medios normales para mover archivos, tampoco generan mucha confianza como criterio.
Se argumenta que, mientras no se bloquee también
ADB, la expresión “bloqueo del sideloading” no resulta del todo precisa. Al final, se sostiene que es indispensable equilibrar la protección contra malware con la libertad de instalar las apps que uno desee.Alguien comparte que, al trabajar con un cliente de Singapur, le exigieron integración con SingPass, el sistema nacional de identidad digital. Ya no es cliente, pero esa integración seguramente sigue perdida en algún rincón del código.
Se advierte que siempre pueden añadir más regiones, así que no conviene bajar la guardia por ahora. Incluso se propone que sería mejor que Google avanzara hacia una tecnología de “permisos falsos” para las apps; de otro modo, los delincuentes simplemente buscarán otra forma de eludir las restricciones.
Se menciona el argumento popular en los comentarios de que “el problema del sideloading se resuelve instalando GrapheneOS”, y se critica por estar muy desconectado de la realidad de la mayoría de los usuarios. Se recuerda que quienes usan HN quizá puedan hacer depuración de hardware, pero la gente común no puede manejar configuraciones a ese nivel del sistema.
Se comparte una experiencia de hace tiempo en foros de Linux, donde respuestas que daban por hecho el uso de CLI compleja resultaban desconcertantes. Se señala que ese sesgo de los expertos puede terminar obstaculizando la adopción y difusión entre principiantes que solo buscan soluciones simples y directas.
Se diagnostica que la mayoría de la gente realmente no entiende cómo es una experiencia “promedio”, y que en comunidades de expertos esa distorsión de perspectiva se agrava, produciendo opiniones muy alejadas de la realidad de la mayoría de los usuarios.
Se analiza que la mayoría de las personas no hace sideloading y, una vez que instala la app que necesita, tiende a seguir usando siempre esa misma app repetidamente.
Se apunta que la gente común normalmente no puede distinguir si una app instalada por sideloading que solicita permisos de SMS o accesibilidad es legítima o no. Por eso, se enfatiza que el verdadero objetivo de este tipo de bloqueo es evitar el mal uso por parte del usuario promedio.
Se expresa preocupación porque, a medida que Google añade tecnologías DRM y APIs, incluso instalar GrapheneOS dejará de ser una alternativa realista en el futuro. Llegado ese punto, usar un sistema operativo alternativo implicaría tener que salir por completo del ecosistema Android.
Una persona admite que antes era del tipo “el teléfono es mío y quiero hacer lo que sea con él”, pero que le impactó descubrir que el uso de drones DJI y Air Units empuja a la gente a instalar apps por sideloading. Se explica que la razón por la que DJI no puede publicar su app en Play Store es que permite modificar su propio código. Se advierte que, si surgiera un conflicto político, eso podría abrir la puerta a malware controlado por un Estado capaz de tomar el control del dron, y se remarca que millones de personas instalaron la app sin entender bien la situación.
Se sostiene que la solución a este problema no es que Google finja analizar malware, sino introducir controles más fuertes sobre qué permisos y funciones puede ejercer realmente la app de DJI. Desde esta óptica, la motivación principal de Google no sería la “seguridad”, sino ampliar su control.
En ese contexto, se afirma que la verdadera libertad de “hacer lo que yo quiera” también debe aplicarse al software. Se valora que la idea defendida por Richard Stallman en 1988 —la libertad de recibir el código fuente y modificarlo uno mismo— sigue plenamente vigente. Se lamenta que, en la práctica, el software cada vez controle más al usuario. También se argumenta que, cuando un gobierno nacional controla el código del software, el riesgo va mucho más allá de una simple afectación a los derechos del consumidor.
Se analiza que, en la práctica, varios gobiernos ya han incorporado este tipo de funciones a través de los OEM. Bajo esa lectura, bloquear el sideloading solo serviría para impedir que los hackers desactiven ese malware integrado.
Se dice que el hecho de que una app se auto-modifique no significa tanto, porque si integra un motor V8 puede cambiar código igualmente. Se señala la ironía de que Google no parezca tener problema con ese tipo de enfoque.
Se cuestiona por qué recibió votos negativos el comentario original que advertía sobre los riesgos de la app de drones DJI. Como ejemplo, se menciona el hallazgo reciente de un kill switch real en paneles solares chinos, y se argumenta que empresas chinas muy vinculadas al gobierno podrían incorporar funciones sospechosas a su hardware y software (https://reuters.com/sustainability/climate-energy/…, https://rickscott.senate.gov/2025/6/…)
Se comenta que instalar GrapheneOS puede resolver las restricciones al sideloading, pero que últimamente Google viene reforzando una tendencia a limitar funciones de las apps solo a instalaciones hechas desde Play Store mediante la Play Integrity API. Se señala que incluso usando Play Store en GrapheneOS con el bootloader bloqueado, Google impide el uso de APIs de certificación de hardware, por lo que apps bancarias, Google Wallet y otras funciones quedan bloqueadas. Se critica que Google tolere fabricantes deficientes que retrasan actualizaciones de seguridad, mientras excluye sistemas operativos open source con muy buena seguridad. También se considera que la colaboración con la Agencia de Ciberseguridad de Singapur funciona más bien como una justificación, y se pregunta por qué apps como Facebook o Instagram no están incluidas en estos bloqueos si de verdad se trata de seguridad (https://localmess.github.io, https://grapheneos.social/@GrapheneOS/112878070618462132)
Se piensa que Google tolera malas prácticas de seguridad en terceros, lo que refuerza la idea de que su objetivo real no es la seguridad, sino el control en sí mismo.
Se sostiene que el mayor problema de GrapheneOS es la escasez de dispositivos compatibles, y que hace falta una alternativa que mantenga cierto nivel de seguridad sin depender de hardware tan específico.
Se aclara que la API de atestación de claves de Android sí está soportada en GrapheneOS y que los desarrolladores pueden integrarla (https://grapheneos.org/articles/attestation-compatibility-guide)
Se añade que ya se había compartido una respuesta directa al argumento de que instalar GrapheneOS lo resuelve todo, junto con un enlace de referencia (https://news.ycombinator.com/item?id=32496220)
Se plantea la preocupación de que esta medida golpee seriamente a la comunidad de personas con discapacidad visual. En países donde Android es popular y el iPhone es caro, el lector de pantalla Commentary (Jieshuo) sería una alternativa mejor que TalkBack, pero al ser una app desarrollada individualmente en China no está en Play Store. Este tipo de apps necesita permisos muy amplios para leer toda la pantalla y controlar la interfaz del sistema. Si se bloquea el acceso de apps sensibles, se vuelve inútil precisamente para su propósito como lector de pantalla. También se critica que empleados de Google puedan restar importancia al tema basándose en las estadísticas de WebAIM sobre baja cuota de uso, cuando WebAIM refleja sobre todo muestras de países angloparlantes de altos ingresos y no representa el uso global real (https://webaim.org/projects/screenreadersurvey10/)
Se considera que la intención de este diseño es bastante razonable y de sentido común. Aunque sigue siendo posible instalar malware mediante
ADB, la barrera de entrada sube lo suficiente como para funcionar como tope de velocidad para el usuario promedio. Además, se dice no haber visto apps de sideloading claramente discriminadas de forma injusta por esta medida.ADBpara instalar apps quizá restringe más la libertad del usuario que la propia propuesta de sideloading de Apple. Apple fue muy criticada por algo parecido, así que esto también debería verse bajo esa misma luz.Se explica por qué es importante bloquear, en esencia, las apps que piden permisos sensibles de privacidad como SMS o accesibilidad. Con solo el permiso de SMS se puede robar información de inicio de sesión de casi cualquier servicio, incluidos los OTP, y con accesibilidad se pueden manipular funciones críticas de apps bancarias y más. También se comenta que en Singapur el comercio de datos de identidad es tan grave que hay advertencias del tipo: “si un desconocido le ofrece comprarle su número de teléfono u otros datos de identidad, puede enfrentar una pena de 5 años de prisión”. Lo mismo aplicaría a cuentas bancarias y tarjetas de crédito. En resumen, como los datos de identidad utilizados en delitos están ligados a personas concretas, cooperar con ello conlleva sanciones agravadas.