- Desde Android 11, Google restringió las consultas entre apps, pero varias apps podían consultar la lista de apps instaladas solo con declararlas en
AndroidManifest.xml
- La política de visibilidad de paquetes exige ver solo las apps necesarias para funciones esenciales, pero las declaraciones de paquetes individuales y el filtro
ACTION_MAIN se usaron como una vía alternativa
- Swiggy declaró 154 apps; Zepto, 165; KreditBee, 860; y Moneyview, 944, lo que les permitía consultar si determinadas apps estaban en el dispositivo del usuario
- De 47 apps indias revisadas al azar, 31 usaban el intent filter
ACTION_MAIN, lo que permite ver la mayoría de las apps instaladas que tienen pantalla, incluso sin QUERY_ALL_PACKAGES
- Los datos de apps instaladas y el permiso
READ_SMS pueden derivar en perfilado, precios diferenciados y evaluaciones de crédito o elegibilidad, pero para el usuario es difícil saber cuándo y qué lee una app
La brecha en la política de visibilidad de apps de Android
- Antes, en Android, una app podía ver otras apps instaladas en el teléfono del usuario sin un permiso especial
- Desde Android 11, Google introdujo la política de visibilidad de paquetes para restringir este acceso
- Una app solo debería poder ver otras apps instaladas cuando sea esencial para su funcionalidad principal
- Los desarrolladores deben especificar las apps que quieren consultar en
AndroidManifest.xml, el archivo de configuración obligatorio de toda app de Android
- En casos de uso concretos, como gestores de archivos, navegadores y antivirus, se permite excepcionalmente el permiso
QUERY_ALL_PACKAGES
- Casos como mostrar apps de pago UPI o detectar clonación de apps y apps de múltiples cuentas pueden ser motivos legítimos para consultar apps
- Muchos de los manifiestos investigados también incluían consultas de apps con fines de pago, seguridad y detección de fraude
Las consultas amplias de apps de Swiggy y Zepto
- Swiggy enumeró 154 nombres de paquetes en su manifiesto, lo que le permitía verificar si esas apps estaban en el teléfono
- La lista incluía apps como Xbox, PlayStation, Naukri y Upstox
- Las categorías eran muy amplias, por lo que hay una alta posibilidad de que la recolección de datos se usara para perfilar usuarios y construir perfiles de comportamiento
- Google considera la lista de apps instaladas como datos de usuario personales y sensibles
- Zepto registró en su manifiesto 165 apps para verificarlas en el dispositivo
- Incluía apps populares de varias categorías, como Netflix, Bumble y Binance
- Hubo un reporte de que Zepto mostraba precios distintos a usuarios de iOS y Android, y algunos clientes reportaron diferencias de precio entre teléfonos Android
- Cuando un usuario instala una app desde Play Store, no puede ver qué lista de consultas de apps contiene el manifiesto de esa app
Alcance de las consultas en apps para repartidores y apps de préstamos personales
- Las apps de Swiggy y Zepto para repartidores tenían listas de consulta de apps distintas a las de consumo
- Ambas apps incluían elementos que permitirían verificar para qué otras empresas trabaja el repartidor
- Swiggy incluso verificaba apps de préstamos personales, apps de finanzas personales y juegos como Ludo King y Carrom Pool
- Las prácticas predatorias de apps de préstamos personales en India están documentadas, y hace algunos años, tras una gran ofensiva, miles de apps fueron eliminadas de Play Store
- KreditBee es una de las principales apps de préstamos personales en Play Store, con más de 50 millones de descargas, y verificaba 860 apps en su manifiesto
- También incluía elementos como Tamil Calendar, Odia Calendar, Qibla Direction Finder, apps de templos y apps de astrología
- También aparecen como ejemplos la app matrimonial para personas que no terminaron la preparatoria
Jodii for Diploma, +2,10 below y la app de compraventa de vacas y búfalos Comprar y vender vacas y búfalos Animall; ambas tienen más de 10 millones de descargas
- Moneyview también es una app de préstamos personales con más de 50 millones de descargas e incluía 944 apps en su manifiesto
- La política de Play Store restringe explícitamente el uso de
QUERY_ALL_PACKAGES por parte de apps de préstamos personales, pero KreditBee y Moneyview eluden esta restricción enumerando una por una las apps que quieren consultar en el manifiesto
Cómo ver la lista de apps sin QUERY_ALL_PACKAGES
- Entre las apps investigadas, el único caso que incluía en el manifiesto el permiso de alto riesgo y sensible
QUERY_ALL_PACKAGES fue Cred
- Play Store permite una “excepción temporal” para este permiso en apps que tengan un propósito principal verificable de facilitar transacciones financieras relacionadas con productos financieros regulados
- Los manifiestos de PhonePe o PayTM, del mismo sector, no tenían este permiso
- Cred también ofrece préstamos personales y, según la política de préstamos personales de Play Store, no parece estar dentro de esta excepción
- Algunos manifiestos de apps incluían un intent filter
ACTION_MAIN como el siguiente
<queries>
[...]
<intent>
<action android:name="android.intent.action.MAIN" />
</intent>
[...]
</queries>
- El filtro
ACTION_MAIN ofrece visibilidad sobre la mayoría de las apps instaladas que tienen pantalla, y permitía ver la lista de apps del teléfono incluso sin el permiso QUERY_ALL_PACKAGES
- Al consultar las apps instaladas con una app básica de Android que incluía la misma configuración, se devolvió la lista de todas las apps del teléfono
- De 47 apps indias analizadas al azar, 31 usaban este filtro, es decir, aproximadamente 2 de cada 3
- Apps que lo usaban: Astrotalk, Axis Mobile, Bajaj Finserv, BookMyShow, Cars24, Cure.fit, Fibe, Groww, Housing, Instamart, Ixigo, JioHotstar, KreditBee, KukuTV, LazyPay, Ludo King, Meesho, MoneyTap, Moneyview, Navi, NoBroker, Nykaa, Ola, PhonePe, PhysicsWallah, Slice, Spinny, Swiggy, Swiggy Delivery, Tata Neu, Zomato
- Apps que no lo usaban: Airtel Thanks, Blinkit, Byju’s, MyGate, Dream11, Flipkart, HDFC Mobile, Healthify, INDmoney, MyJio, Paytm, PaisaBazaar, ShareChat, Unacademy, Vedantu, Zepto
- Swiggy también tenía el filtro
ACTION_MAIN, pero además enumeraba explícitamente la lista de apps a consultar, lo que deja ver parte de sus prácticas de recolección de datos
- Los archivos de manifiesto leídos están publicados en android-manifest-files, y la mayoría se descargó el 18 o 19 de marzo
- Esta configuración no se limitaba a apps de empresas indias
- Facebook, Instagram, Snapchat, Subway Surfers y Truecaller tenían la misma configuración
- Amazon, Spotify, X, Discord y WhatsApp no la tenían
Sensibilidad de los datos de apps instaladas y del permiso SMS
- Los datos de apps instaladas son datos personales sensibles
- En 2022, Vice reportó que, poco después de conocerse que Roe v. Wade podía ser revocado, un marketplace de datos llamado Narrative estaba vendiendo datos de usuarios que habían descargado apps de seguimiento menstrual
- Además de las consultas de apps instaladas, el manifiesto de una app puede incluir una amplia gama de permisos que parecen ir más allá de lo necesario
- Zepto solicita el permiso
READ_SMS
- El usuario puede rechazarlo, pero es obligatorio al registrarse en Zepto Postpaid
- Si se concede el permiso, también se incluyen como objetivos de verificación muchos sender ID de TRAI de bancos y SMS de Blinkit, Swiggy, Bigbasket y Flipkart
- Parece que lee SMS bancarios para verificar la elegibilidad para el plan Postpaid, pero puede leerlos aunque el usuario no elija esa función
- Después de conceder a una app un permiso como
READ_SMS, el usuario no puede ver cuándo ni a qué accede la app
- La información de apps instaladas en Android puede usarse para perfilado por desarrolladores de apps y brokers de datos, cruce con datos de redes publicitarias y fijación de precios
1 comentarios
Opiniones en Hacker News
La vulnerabilidad de ACTION_MAIN ya se había tratado antes: https://commonsware.com/blog/2020/04/05/android-r-package-vi...
Google no intenta parchear esto. Me pregunto qué pasaría si se enviara al Android VDP como una omisión de permisos.
También hay una pregunta en SO del autor sobre la omisión: https://stackoverflow.com/q/79527331
En ese punto, el flujo en el que Android pregunta si quieres establecer como launcher predeterminado un juego cualquiera que acabas de descargar se vuelve, para una app sospechosa, una interacción bastante riesgosa. Es muy probable que el usuario abandone y la denuncie, o que un usuario con menos conocimiento la elija como launcher predeterminado, arruine su pantalla de inicio y la reporte en Play Store. En la práctica, distribuirse como una app de nivel launcher también implicaría pruebas automatizadas y requisitos adicionales, lo que sería una carga para el desarrollador.
Me cuesta creer que los ingenieros de Google no conozcan esta vulnerabilidad tan usada, pero me pregunto si hay alguna fuente que indique que Google se negó a corregirla.
Todavía no entiendo en absoluto por qué hacen falta “apps” nativas. Hasta ahora no he visto ninguna “app” para la que no bastara un sitio web o una web app, y la mayoría probablemente habría sido mejor como web app.
La única ventaja de una “app” parece ser que el desarrollador puede acceder a información personal que en realidad no necesita.
También está la ventaja de poder estar en la “App Store”, pero la App Store es un concepto innecesario creado para que Apple/Google se queden con un gran porcentaje de las ventas.
Los navegadores web ofrecen un sandboxing decente, no tienen cuotas de “envío” y son accesibles para todos en cualquier teléfono.
En la práctica, la mayoría de las web apps móviles son pésimas. La experiencia de usuario no se acerca en absoluto a la de una app nativa. No me gusta que se seleccione el texto, no me gusta que todas las páginas tengan pull-to-refresh, y no me gusta que deslizar hacia la izquierda vuelva a la página anterior.
Probablemente se puedan encontrar formas de sortear estos problemas, pero la nueva biblioteca Silk (https://silkhq.co/) parece ser el primer caso que se acerca mucho a una experiencia nativa. Y el solo hecho de que sea una biblioteca de pago muestra que este problema no es para nada trivial.
Hay muchas cosas que las apps nativas pueden hacer y que el navegador no puede hacer bien, o directamente no puede hacer. Por ejemplo, edición pesada de video/audio, acceso a grandes cantidades de RAM, uso de cómputo en GPU y tareas cercanas al hardware siguen estando fuera del alcance de un navegador por sí solo.
No digo que la forma en que Apple y Google lo implementaron realmente sea buena, pero no veo que vayamos hacia un futuro en el que solo usemos web apps. Por la misma razón, no voy a cambiar mi computadora real por un Chromebook en el corto plazo.
Pero siguen siendo buenas las apps que funcionan offline en el dispositivo y que no esparcen mis datos entre servicios que no controlo. Tampoco quiero depender de una conexión a Internet esté donde esté.
Me gustan las apps offline OsmAnd/Organic Maps que muestran el camino cuando estás en un bosque o en la montaña, y también las apps que comparten datos conectándose directamente a mi dispositivo local en vez de a servidores de terceros.
Si fuera posible, todas las apps deberían desarrollarse con prioridad offline y pedir Internet solo cuando sea necesario. Una app que no puede funcionar sin Internet basta con que sea una web app y no necesita estar en mi dispositivo.
Me pregunto cuándo fue la última vez que reservaste un boleto de avión en la web móvil. Tampoco sé cómo soportas el espacio de pantalla que ocupa el navegador. Las apps pueden cachear la autenticación y manejarla con FaceID; tener que iniciar sesión cada vez también es un problema.
Por eso me gusta Hacker News
Ayer encontré este artículo y lo publiqué en el tablero de Android de Reddit: https://old.reddit.com/r/Android/comments/1jmwg4w/everyone_k...
Tuvo 0 votos a favor, y los comentarios estaban llenos de reacciones de gente deprimida o bots, no sé
Aquí está cerca del segundo lugar, y la mayoría de los comentarios son interesantes
Hay muchos subreddits muertos, pero r/android está entre los peores
Además, los subreddits temáticos en general parecen estar moderados por personas con intereses en ese tema, y eso perjudica a la comunidad. Publiqué un texto detallado sobre bajo qué licencia propietaria está Llama de Meta y qué significa exactamente esa licencia, pero los moderadores de r/LocalLlama lo borraron manualmente sin motivo, y cuando pregunté para entender mejor las reglas, no respondieron por qué lo habían eliminado
En la última “purga de Reddit”, cuando reemplazaron a muchos moderadores de comunidades por empleados de Reddit, me quedé pensando si gran parte de la plataforma no terminó vendiéndose para que cada empresa moderara directamente su propio espacio
Si haces clic en el enlace “past” debajo del título, hay un hilo de hace 2 días que está completamente muerto
Hacker News entiende el concepto de crítica constructiva
La parte clave es: “Más allá de las categorías generales, revisa incluso cosas como Tamil Calendar, Odia Calendar, Qibla Direction Finder, apps de mandir y apps de astrología. Sabe lo que hace”
Esta app de préstamos está perfilando a las personas según identidad étnica/regional (Tamil, Odia) y religión (Qibla Direction Finder para musulmanes, apps de mandir para hindúes)
La app de HSBC UK para Android revisa las apps instaladas y se niega a ejecutarse si hay apps con ciertos permisos. Por ejemplo, no puedes tener un launcher alternativo, y ahora se niega a ejecutarse si tienes siquiera una app instalada fuera de la tienda de apps de Google
Ya me había quejado de esto aquí antes, pero al final terminé pidiendo un dispositivo de seguridad de hardware y usando el sitio web en su lugar
Me pregunto si al menos dicen que esos datos no se envían a la empresa
La respuesta a la pregunta “¿Por qué es necesario para la funcionalidad principal de Swiggy saber si tengo instaladas las apps de Xbox o Playstation en mi teléfono? ¿En qué ayuda saber si tengo Naukri o Upstox para entregar víveres en mi casa?” es: para fingerprinting
Lo mismo con las apps bancarias: si eres estafador, saber de antemano qué banco usa el objetivo es realmente útil
Sobre todo si se puede asociar con un número de teléfono, habría bastantes grupos interesados en esta información
En la parte que dice: “Para casos de uso muy específicos, como administradores de archivos, navegadores y apps antivirus, Google concede excepciones al permiso QUERY_ALL_PACKAGES para que puedan ver todas las apps instaladas”, no entiendo por qué un navegador tendría que enumerar las apps instaladas
¿¡Por qué!?
Es decir, échale la culpa a gestión de producto de Google
Por ejemplo, Obsidian pide permiso para todo el sistema de archivos, pero en realidad le bastaría con acceder a los archivos que el usuario le haya permitido ver
Es una función muy útil, y no me gustaría que desapareciera
“Que todos sepan todas las apps de tu teléfono” se refiere a teléfonos Android. El iPhone no tiene esta falla de privacidad
https://blog.verichains.io/p/technical-analysis-improper-use...
En Android, si usas el perfil de trabajo, que hoy es el método estándar, solo pueden ver las apps dentro del perfil de trabajo
Uno de los mayores incentivos para crear una app es extraer toda clase de datos del usuario. Basta ver cuántas apps piden acceso a los contactos y cuántas realmente necesitan contactos para su funcionalidad. Por eso todavía me sorprende un poco que a tanta gente le sorprendan hallazgos como este
Antes se podía intentar comunicarse con una app mediante un esquema URI personalizado y, si tenía éxito, saber que esa app estaba instalada. Twitter usaba esto para fingerprinting
Ahora una app tiene que aceptar intents especiales y declarar la lista de apps que usará para ese propósito
Hace poco sus funciones de LLM se actualizaron mucho, así que instalé la app para probarlas. Mientras la app estuvo instalada, cada vez que veía el sitio móvil aparecía un gran banner que me mandaba a la app, y no se podía eliminar ni con bloqueadores de anuncios ni con bloqueadores de molestias. Cuando volví a borrar la app, desapareció
¿Por qué pasa esto? Me pregunto cómo sabe el sitio móvil si la app está instalada. Cuando la app no está instalada puedo bloquear todas las invitaciones a usarla con bloqueadores de contenido/molestias, pero cuando está instalada no entiendo por qué no puedo
Requiere root, pero se puede bloquear o falsear esto con algo como XPrivacyLua[2], un módulo de LSPosed[1]. También escuché que existe AppOps[3], de código cerrado, aunque no lo he probado
[1]: https://lsposed.org
[2]: https://github.com/M66B/XPrivacyLua / https://github.com/0bbedCode/XPL-EX
[3]: https://appops.rikka.app
Curiosamente, XPrivacyLua ya no tiene soporte, y Google va a retirar de Play Store su app complementaria pro porque usa el permiso QUERY_ALL_PACKAGES
[0]: https://github.com/M66B/NetGuard
[1]: https://xdaforums.com/t/closed-app-xposed-6-0-xprivacylua-an...
Me pregunto si las apps de Windows, especialmente las que no se instalan desde la MS Store, pueden enumerar los títulos de todas las ventanas abiertas. ¿Qué tan difícil sería que una app monitoreara todo el tráfico web solo con los títulos?
Es una pregunta real. ChatGPT solo me da la razón en todo y no ayuda mucho; necesito que alguien me diga por qué no sería viable en el mundo real
Existen las funciones EnumWindows() y EnumChildWindows() para este propósito
Como ejemplos de esta funcionalidad están la utilidad “Windows Modifier v2.00” y Spy++ (SPYXX.EXE) de Microsoft. Cuando la obtuve por primera vez hace años había muchas páginas relacionadas, pero ahora casi no aparece nada ni buscando el nombre exacto, lo que se siente como una señal de lo bien que Internet ha aprendido a olvidar
La solución para apps en las que no confías es no usarlas, o usarlas en una VM
Al menos esto es cierto en Windows y en la mayoría de los sistemas *nix tradicionales, especialmente X11
En este punto hay algo que Android hizo bien: por defecto ejecuta cada aplicación como un usuario distinto. Es decir, tienen carpetas home distintas y no pueden ver otras apps
Aun así, herramientas como ManicTime o ActivityWatch rastrean el historial del navegador mediante títulos de ventanas si no instalas un plugin del navegador
https://www.manictime.com/
https://activitywatch.net/
En particular, es correcto decir que “UAC [todavía] no es una barrera de seguridad”. Si aceptas elevar un proceso o ingresas una contraseña, en la práctica estás elevando todo el escritorio y todo lo que se está ejecutando junto con él