Cuando una app pide permisos, debería haber una opción para “proporcionar datos falsos”

 (archive.md)
1 puntos por GN⁺ 2023-07-09 | 1 comentarios | Compartir por WhatsApp
  • Cuando una app pide permisos, el sistema operativo no debería permitir solo respuestas de sí/no, sino agregar una “opción para proporcionar datos falsos” en todas las categorías de permisos
  • Si pide contactos, proporcionar contactos falsos generados; si pide acceso al micrófono, sonido ambiental aleatorio; si pide información de ubicación, coordenadas de una pequeña isla de 5×5 m
  • Si se bloquea el acceso, la app se niega diciendo “entonces no se puede usar”, pero si se le dan datos falsos, solo se castiga al servicio que pidió datos innecesarios
  • Un boicot exige un gran sacrificio personal al usuario, pero causa un impacto mínimo a las empresas; por eso, la postura es que el cumplimiento malicioso (malicious compliance) es más eficaz que un boicot
  • Esto deriva en un problema de control del usuario: los usuarios deberían poder controlar las apps y el software del sistema como administradores de los dispositivos que poseen

Propuesta clave: opción de datos falsos por permiso

  • El sistema operativo debería ofrecer, además de sí/no ante una solicitud de permisos, la opción “sí, pero proporcionar datos falsos” en todas las categorías
    • Solicitud de contactos → proporcionar contactos falsos generados aleatoriamente
    • Solicitud de micrófono → proporcionar sonido ambiental aleatorio (random ambiance)
    • Solicitud de ubicación → responder que está en una pequeña isla de 5×5 m
  • Si un servicio pide datos que no necesita, se logra el efecto de castigarlo llenando su base de datos con información inútil
  • A diferencia de bloquear el acceso, los datos falsos impiden que la app responda con “no se puede usar”, a la vez que neutralizan la recolección de datos innecesarios

Argumento de superioridad frente al boicot

  • Boicotear una app necesaria es un trato desfavorable: implica un sacrificio personal considerable y solo causa un golpe imperceptible a un multimillonario
    • Es una estructura desfavorable para el usuario, porque quien pelea es quien más pierde
  • La postura es que el método de inyectar datos falsos le da más poder al usuario
  • Se usa la expresión de que el “cumplimiento malicioso (malicious compliance)” es más divertido que un boicot

Herramientas existentes mencionadas en la discusión

  • Suplantación de ubicación (location spoofing)

    • En el pasado, la suplantación de ubicación solo era posible como configuración global, y era difícil elegirla por app
    • En las opciones de desarrollador de Android, al designar una app específica como app de ubicación simulada (mock location), se aplica de forma global
    • En Firefox existen extensiones para suplantar todo tipo de datos, incluida la geolocalización, pero sería más útil que funcionara en el teléfono
    • El uso indebido de datos de ubicación falsos en Pokémon GO confirma que técnicamente es posible

  • XPrivacyLua

    • En dispositivos rooteados hacía exactamente lo que el usuario quería, pero requería Magisk (modificación del sistema)
    • Actualmente está en estado de mantenimiento discontinuado y no es compatible con todos los dispositivos

  • Funciones básicas de permisos de Android

    • Android ya permite elegir el acceso a la información por app o configurar que pregunte cada vez
    • Sin embargo, esto solo es un método de bloqueo y no equivale a proporcionar datos falsos

Ideas de extensión y casos

  • Contaminación de datos con IA

    • Propuesta de neutralizar a los mineros de datos alimentándolos recursivamente con información sin sentido
    • Idea de contaminar incluso el contenido para entrenamiento de IA con datos generados por IA

  • Respuesta al rastreo publicitario

    • Se menciona AdNauseam (un fork de uBlock Origin), que bloquea anuncios y a la vez hace clic en todos para neutralizar los datos de segmentación
    • Se evalúa que, en intentos anteriores, consumía muchos recursos

  • Alteración de perfiles de rastreo en el navegador

    • Existen servicios que recorren rápidamente varios sitios con el navegador y cookies para alterar la huella digital y el rastreo
    • Permiten elegir patrones aleatorios o basados en perfiles (por ejemplo: “navegar como un hippie ecuatoriano de 70 años”)
    • Se menciona el caso de TrackThis, creado por Mozilla

Limitaciones y preocupaciones planteadas

  • Si se ingresa una fecha de nacimiento aleatoria, se reciben felicitaciones de cumpleaños en una fecha cualquiera, pero surge el problema de no saber qué fecha se usó en las preguntas de seguridad
    • Opinión complementaria: el sistema operativo debería poder mostrarle al usuario sus propios valores de datos falsos
  • Hace unos 10 años se evaluó esto como idea de startup, pero no se encontró un abogado que pudiera hacerlo defendible
  • La previsión es que es muy poco probable que Google lo implemente, porque los desarrolladores comerciales le tendrían mucho miedo
  • Se señala que la causa de fondo es que ni Google ni Apple quieren que los usuarios tengan control

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-07-09
Opiniones de Hacker News

  • Estoy a favor de la idea de los “datos falsos”, pero debería exigirse que las apps manejen con elegancia el caso en que el usuario niegue el permiso de acceso a los datos reales.
    Antes, cuando desarrollaba para iOS, la política de Apple era que no se debía castigar al usuario por negar permisos ni cerrar la app con exit(); la app tenía que seguir ejecutándose.
    Incluso antes, las apps ni siquiera podían exigir una “cuenta” para ejecutarse. Recuerdo que, hace más de 10 años, la empresa introdujo la obligatoriedad de tener cuenta y fue rechazada con razón en la App Store. Hoy parece que esa postura se ha suavizado, viendo que cada vez hay más apps que exigen cuenta.

    • A la frase “una app no puede exigir una cuenta para ejecutarse” le falta una salvedad importante, o no entiendo bien qué significa.
      ¿Cómo podrían funcionar sin cuenta una app bancaria, un juego en línea, la app actual de Twitter o apps como Dropbox/Nextcloud?
      Es cierto que en muchas apps exigir una cuenta es una trampa de marketing, pero no parece que una regla general así pueda funcionar.
    • WhatsApp todavía “castiga” al usuario si rechaza el acceso a los contactos. Oculta todos los nombres y muestra solo números de teléfono, incluso cuando la otra persona configuró un nombre en su propio perfil.
      Facebook/Meta es una porquería.
    • Los datos personales falsos, como contactos o fotos, están bien, pero cuando se trata de ubicación la cosa se vuelve ambigua.
      Si es para mostrar mi ubicación en un mapa o buscar negocios cercanos, está bien dar datos falsos.
      Pero si una app de prueba de velocidad de internet mapea las velocidades por operador, o si una app mejora el pronóstico con reportes del clima local de los usuarios, creo que debería poder decir: “dame una ubicación precisa o no me des nada; no quiero una ubicación falsa”.
      La plataforma tendría que decidir si concede excepciones a las apps que reciben datos aportados por usuarios y que afectan a otras personas.
      Apple parece haber encontrado un punto medio bastante bueno en esto. No hace falta permitirle a una app la “ubicación precisa”, y con las fotos también se puede mostrarle a la app solo las que el usuario eligió mediante el selector de imágenes provisto por el sistema.
    • En iOS, lo peor es Google Photos. Si no permites el acceso a todas las fotos, ni siquiera puedes abrir la app, y tampoco acepta que permitas solo las fotos seleccionadas.
      Lo mismo pasa aunque solo quieras ver fotos que ya están guardadas en la nube.
    • Aunque uno diga “las apps deben manejar con elegancia que el usuario niegue el acceso a los datos reales”, ¿qué haces si no lo cumplen?
      Es proponer una solución organizacional a un problema técnico, así que es difícil que funcione; la única solución práctica son los datos falsos. Desde el punto de vista de la app, debe parecer que el permiso fue concedido aunque en realidad no lo haya sido.

  • En Android rooteado, XPrivacy podía hacer esto desde hace 7 años, y también existen alternativas modernas. Aunque hace mucho que no rooteo un teléfono, así que no puedo garantizarlo: https://github.com/M66B/XPrivacy
    Claro que no es el enfoque mayoritario, y estoy de acuerdo en que debería venir integrado por defecto. Pero como tanto Android como iOS permiten tonterías como apps con restricciones regionales o bloquear capturas de pantalla de contenido con DRM, no será fácil.

    • Al usarlo de esa forma, sentí directamente lo desfavorable que está diseñado para el usuario, y dejé de creer que el teléfono es una computadora.
      El teléfono es un dispositivo de entrega de contenido del proveedor, y el usuario queda a merced de ellos.
    • XPrivacy era realmente genial, pero rootear e instalar Xposed en teléfonos modernos se volvió mucho más complicado, o directamente quedó bloqueado.
      GrapheneOS no funcionaba bien con apps bancarias, Google rompió varias veces el rooteo mediante Magisk en Android Beta, y en algún momento dejé de preocuparme por eso.
      Quizá GrapheneOS o proyectos similares podrían implementar una función así.
    • XPrivacy era excelente, pero al negar algunos permisos las apps se cerraban con frecuencia. Al final, no ofrecía datos falsos lo suficientemente bien.
      Era tan grave que nunca tocaba “denegar” de entrada; siempre empezaba con “denegar temporalmente”. Si la app funcionaba, lo denegaba de forma permanente; si se cerraba, tenía que encontrar el conjunto mínimo de permisos que debía permitir.
    • Es poco probable que esta función llegue a la imagen de fábrica o al upstream de Android, pero si hay suficiente demanda de usuarios, podría entrar en proyectos como LineageOS.
    • Lo de “apps con restricciones regionales” en realidad no es eso, sino permitir que cada tienda de apps distribuya una app solo en las regiones que elija.
      Una app podría no ofrecer una buena experiencia en todos los países, no estar localizada a todos los idiomas, no contar con moderadores de contenido para ese idioma, tener que cumplir leyes de distintos países, o tener licencias de distribución de contenido con copyright limitadas a ciertos países; por eso es una función importante para las tiendas de apps.
      La prevención de capturas de pantalla en contenido con DRM es una función que los desarrolladores de apps solicitan por requisitos legales de las licencias de contenido, como películas. Los estudios no quieren que la gente streamee o grabe películas, así que las plataformas de apps necesitan una forma de mostrar ese contenido de manera segura.

  • “Si alguien hace una pregunta que no tiene derecho a hacer, no tienes la obligación de decir la verdad”.
    — Leonard Schiffman
    Fuente: “Blend me in: Privacy-Preserving Input Generalization for Personalized Online Services” https://drive.google.com/file/d/10OmoqMmHFcb7PsQtaU_GW4aCAJe...

  • Hay un problema con el argumento de que, en las solicitudes de permisos de las apps, el sistema operativo debería ofrecer no solo sí/no, sino también “sí, pero alimentar a la app con datos falsos”.
    Muchos usuarios ni siquiera saben cómo reenviar un correo electrónico.
    Imaginen la confusión que podría surgir si esas personas usan la navegación de Google Maps y eligen datos falsos sin entender lo que significa.
    Google Maps: “Gire a la derecha”.
    Conductor manejando por una carretera costera: “Bueno”.
    Auto: chapuzón

    • Eso es enteramente un problema de experiencia de usuario.
      Basta con esconder la función de falsificación de datos bien adentro de la configuración, explicarla con claridad y en palabras simples antes de activarla, y mostrar claramente en pantalla que, debido a una función de privacidad que el usuario activó manualmente, se le está dando información alternativa a la app y que puede desactivarla fácilmente.
      Aun así habrá gente que la active por error, pero puede aportar mucho valor a muchos otros usuarios que no lo harán.
    • Eso parece una oportunidad de aprendizaje. O quizá una oportunidad darwinista.
      De cualquier modo, es un problema que se resuelve solo.
    • Entonces basta con convertir esa configuración en una opción para usuarios avanzados. Los usuarios que no estén familiarizados con esto no verían la opción en absoluto.
    • En ese caso, el conductor no estaba mirando correctamente la dirección en la que avanzaba, y eso es otro problema.
      Parece mejor que el sistema operativo ofrezca “sí”, “no” y “personalizar”. Si se elige “personalizar”, dentro de ese menú se pueden mostrar advertencias si hacen falta, pero no se debería impedir que el usuario lo ajuste como quiera.
    • Me pregunto cuánta gente usa Google Maps en iOS. La opción de “proporcionar datos falsos” suena a algo que Apple podría hacer, pero me cuesta muchísimo creer que Google lo haga.
      Apple Maps no tendría este problema. Se pueden descargar los mapas al dispositivo, así que puede funcionar offline sin conexión de datos.

  • Me sorprende que no esté en el comentario principal el hecho de que en iOS no se puede distinguir si se obtuvo un permiso o no.
    Por ejemplo, cuando una app solicita acceso a las fotos, siempre recibe un arreglo. Solo que, si se deniega el permiso, ese arreglo está vacío, así que no se puede saber si la biblioteca del usuario realmente está vacía o si se denegó el acceso. Me gusta porque es simple y elegante.
    Claro que, en el caso de las fotos, casi todo el mundo tiene al menos algunas, así que se puede usar una heurística. Pero en otros tipos de datos, como los de salud, no es tan claro.

  • Creo que “proporcionar datos falsos” es el enfoque equivocado. Un enfoque mejor sería proporcionar datos de una fuente alternativa, y esa fuente alternativa debería poder ser cualquier otro programa.
    La fuente alternativa podría ser lo que el usuario quiera: datos vacíos, datos aleatorios, datos falsos pero consistentes, datos de archivos alternativos (por ejemplo, una lista de contactos aparte o fotos de un archivo en lugar de la cámara), datos transformados (por ejemplo, invertir una foto de la cámara), filtrado, registro, preguntar al usuario por cada dato individual, entregar códigos de error en lugar de datos y permitir que el usuario especifique esos códigos de error, etc. También debería incluir por completo el acceso a la fecha/hora actual.
    Esto aumenta el control del usuario y también es útil para pruebas y accesibilidad.
    Una de mis ideas sobre diseño de sistemas operativos es la de permisos proxy. Incluir permisos proxy en la seguridad basada en permisos, hacer que toda entrada y salida los use, y que también puedan usarse desde un shell de comandos de una forma mejor que los pipes de UNIX, además de otras formas. También incluye fecha/hora. Salvo Yield y Quit, ninguna llamada al sistema puede usarse sin una clave de permiso.

    • Creo que este es el mejor enfoque y, de hecho, el único que realmente podría funcionar.
      Para los desarrolladores de apps es muy difícil manejar bien permisos que no pueden usar, y como el alcance de pruebas se vuelve mucho más grande y difícil para una cantidad relativamente pequeña de usuarios, la mayoría de las apps comerciales pequeñas no van a intentar manejarlo correctamente.
      Permitir el permiso pero alimentar a la app con una fuente de datos alternativa es lo más fácil tanto para desarrolladores como para usuarios.
      Claro que también podría facilitar el fraude. Por ejemplo, los bancos probablemente usarían procedimientos de registro de dispositivos más complejos.

  • No hace falta ponernos difíciles entre nosotros. La regla simple es: “no también es una opción, salvo cuando realmente no sea una opción”.
    Si no es una opción, debería quedar muy claro por qué, y probablemente tendría que declararse durante el proceso de revisión de la app; de lo contrario, la app debería rechazarse.
    Por ejemplo, si TikTok/Instagram pide permisos de cámara y micrófono, ninguno de los dos es indispensable para usar la app, así que no es una opción. Si es posible usar parte de la app sin un permiso específico, es responsabilidad de la app diseñarse para funcionar así. Si la cámara o el micrófono están desactivados, basta con deshabilitar condicionalmente solo las funciones que requieran ese permiso.
    Dicho de forma más simple: la carga recae en quien solicita. Si no está claro, o si intenta escaparse con alguna viveza, la respuesta es no. Puede sonar estricto, pero los creadores de apps pueden evitar por completo este paso adicional haciendo que los permisos sean opcionales.
    Enfocarse en hacer cumplir esto elimina la necesidad de una pequeña carrera armamentista, y también es una mejor opción para las personas.

    • Suena bien, pero ¿cómo se haría cumplir?
      Los únicos actores que pueden imponerlo aquí son las tiendas de apps de Google/Apple/Microsoft. Es difícil estar seguro de que tengan suficientes incentivos para aplicarlo de forma consistente y amigable para el usuario. Si los tuvieran, ya lo habrían hecho.

  • Los teléfonos Samsung tienen un interruptor para el acceso a la cámara y otro para el acceso al micrófono.
    Si lo desactivas, aparece este mensaje:

    Turn off Camera access?  
All apps will be blocked from using the camera. Apps  
will still work, but they will only be able to access an  
empty black screen. For example, you can still make  
and receive video calls, but the other person won't be  
able to see you.
    • Para el acceso al micrófono: 
      Turn off Microphone access?  
All apps will be blocked from using the microphone  
Apps will still work, but they won't be able to access  
any sounds from the microphone. For example, you  
can still make and receive calls, but the other person  
won't be able to hear you.

  • En vez de “sí, pero proporcionar datos falsos a la app” para todas las categorías, sería mejor una configuración por app.
    Puede que no quieras darle datos de ubicación a casi ninguna app, pero sí a Google Maps y a una app de llamadas de emergencia. Lo mismo aplica para contactos y datos personales.
    Sin embargo, esas apps enfrentarían una fuerte resistencia de Google y otras empresas que se benefician del perfilado de usuarios.

    • Estoy de acuerdo, pero debería ser por app y, al mismo tiempo, por categoría de permiso.
      Por ejemplo, deberías poder darle datos reales a un permiso en una app, datos falsos o datos personalizados/ingresados manualmente a otro permiso, y denegar un tercer permiso.
      También podrías querer cambiar la configuración temporalmente, ya sea para pruebas o como cuando una app que muestra el clima de tu ubicación actual te permite ver por un rato el clima de otro lugar y luego volver a tu ubicación real.

  • Si una app necesita mis datos para mejorar mi experiencia, y solo mi experiencia, entonces al alimentarla con datos falsos solo debería empeorar mi experiencia. Al desarrollador o dueño de la app no debería importarle.
    Pero si el objetivo es minar mis datos, como en la mayoría de los casos, los datos falsos servirían bien para entorpecerlo.
    Claro que en casos como WhatsApp no sirve de mucho, porque la gente sincroniza felizmente toda su lista de contactos con Facebook/Meta con tal de obtener una experiencia de mensajería ligeramente mejor.

    • Yo también tuve que hacerlo y me resultó muy desagradable, pero no era solo una “experiencia ligeramente mejor”.
      Al menos en móvil, la app y el servicio apenas son utilizables hasta que sincronizas los contactos.