Quando um app pede permissões, deveria existir a opção de "fornecer dados falsos".

 (archive.md)
1 pontos por GN⁺ 2023-07-09 | 1 comentários | Compartilhar no WhatsApp
  • Quando um app pede permissões, o sistema operacional não deveria permitir apenas respostas de sim/não; ele deveria adicionar a opção de "fornecer dados falsos" a todas as categorias de permissão
  • Se pedir contatos, fornecer contatos falsos gerados; se pedir acesso ao microfone, sons ambientes aleatórios; se pedir localização, coordenadas de uma pequena ilha de 5×5 m
  • Ao bloquear o acesso, o app pode recusar com um "então não dá para usar", mas ao fornecer dados falsos, a punição recai apenas sobre o serviço que pediu dados desnecessários
  • Como o boicote exige um grande sacrifício pessoal do usuário, mas causa pouco impacto às empresas, a posição defendida é que a conformidade maliciosa (malicious compliance) é mais eficaz do que o boicote
  • Isso leva à questão do controle do usuário: o usuário deveria poder controlar apps e o software do sistema como administrador do dispositivo que possui

Proposta central — opção de dados falsos por permissão

  • O sistema operacional deveria oferecer, além de sim/não para pedidos de permissão, a opção "sim, mas fornecendo dados falsos" em todas as categorias
    • Pedido de contatos → fornecer contatos falsos gerados aleatoriamente
    • Pedido de microfone → fornecer ruído ambiente aleatório (random ambiance)
    • Pedido de localização → responder que está em uma pequena ilha de 5×5 m
  • Se um serviço pedir dados de que não precisa, o efeito é punir esse banco de dados ao preenchê-lo com informações inúteis
  • Diferentemente de bloquear o acesso, os dados falsos impedem que o app reaja com "indisponível para uso", ao mesmo tempo em que neutralizam a coleta desnecessária de dados

Argumento de superioridade em relação ao boicote

  • Boicotar um app necessário é uma troca desfavorável: o usuário faz um sacrifício pessoal considerável, enquanto o bilionário do outro lado mal sente o impacto
    • É uma estrutura em que quem luta é quem mais tem a perder, o que desfavorece o usuário
  • A posição defendida é que a injeção de dados falsos dá mais poder ao usuário
  • Usa-se a expressão "conformidade maliciosa (malicious compliance)" como algo mais divertido do que o boicote

Meios já existentes mencionados na discussão

  • Falsificação de localização (location spoofing)

    • No passado, a falsificação de localização só era possível como configuração global, e era difícil escolher por app
    • Nas opções de desenvolvedor do Android, ao definir um app específico como app de localização simulada (mock location), isso se aplica globalmente
    • O Firefox tem extensões para falsificar geolocalização e vários outros dados, mas seria mais útil se funcionasse no celular
    • Houve casos de uso indevido no Pokémon GO com dados falsos de localização, confirmando que isso é tecnicamente possível

  • XPrivacyLua

    • Em dispositivos com root, fazia exatamente o que o usuário queria, mas exigia Magisk (modificação do sistema)
    • Atualmente está sem manutenção e não é compatível com todos os dispositivos

  • Recursos nativos de permissões do Android

    • O Android já permite escolher por app o acesso a informações ou configurar para perguntar sempre
    • Ainda assim, isso é apenas uma forma de bloqueio, e não de fornecimento de dados falsos

Ideias e casos de expansão

  • Poluição de dados com IA

    • Foi sugerido inutilizar mineradores de dados fornecendo-lhes informações sem sentido de forma recursiva
    • Também surgiu a ideia de poluir até mesmo conteúdo para treinamento de IA com dados gerados por IA

  • Reação ao rastreamento publicitário

    • Foi citado o AdNauseam (um fork do uBlock Origin), que bloqueia anúncios e ao mesmo tempo clica em todos eles para inutilizar os dados de segmentação
    • Avalia-se que, em tentativas anteriores, o consumo de recursos era alto

  • Perturbação de perfis de rastreamento no navegador

    • Existem serviços que percorrem rapidamente vários sites com navegador e cookies para perturbar fingerprinting e rastreamento
    • É possível escolher padrões aleatórios ou baseados em perfis, por exemplo: "navegar como um hippie equatoriano de 70 anos"
    • Foi citado o caso do TrackThis, criado pela Mozilla

Limites e preocupações levantados

  • Se você inserir uma data de nascimento aleatória, pode acabar recebendo parabéns em uma data qualquer, mas surge o problema de não saber qual data foi usada em uma pergunta de segurança
    • Como complemento, argumenta-se que o sistema operacional deveria poder mostrar ao usuário os seus próprios valores de dados falsos
  • Cerca de 10 anos atrás, isso foi avaliado como uma ideia de startup, mas não se encontrou um advogado capaz de torná-la juridicamente defensável
  • A previsão é que o Google quase certamente não implementaria isso, porque os desenvolvedores comerciais temeriam muito a ideia
  • Aponta-se que a causa fundamental é que nem Google nem Apple querem que o usuário tenha controle

Leituras relacionadas

1 comentários

 
GN⁺ 2023-07-09
Comentários do Hacker News

  • Sou a favor da ideia de “dados falsos”, mas os apps também deveriam ser obrigados a lidar com isso de forma elegante mesmo quando o usuário nega acesso aos dados reais
    Quando eu desenvolvia para iOS antigamente, a política da Apple dizia que você não podia punir o usuário nem encerrar o app com exit() por ele negar uma permissão, e o app tinha que continuar funcionando
    Há ainda mais tempo, nem sequer se podia exigir uma “conta” para executar o app. Lembro que, mais de 10 anos atrás, a empresa introduziu a exigência obrigatória de conta e foi justamente rejeitada pela App Store. Hoje em dia, vendo cada vez mais apps que exigem conta, parece que essa posição foi flexibilizada

    • Na afirmação de que “um app não pode exigir uma conta para funcionar”, está faltando uma ressalva importante, ou então eu não entendi o sentido
      Apps bancários, jogos online, o app atual do Twitter, ou apps como Dropbox/Nextcloud, como poderiam funcionar sem conta?
      É verdade que em muitos apps exigir conta é uma manobra de marketing, mas não parece que uma regra geral dessas possa funcionar
    • O WhatsApp ainda “pune” o usuário se ele negar acesso aos contatos. Ele esconde todos os nomes e mostra só os números de telefone, mesmo quando a outra pessoa definiu o nome no próprio perfil
      Facebook/Meta é um lixo
    • Dados pessoais falsos como contatos ou fotos tudo bem, mas quando entra em localização a coisa fica mais ambígua
      Se for para mostrar minha posição no mapa ou buscar estabelecimentos próximos, dá para fornecer dados falsos
      Mas se for um app de teste de velocidade da internet que mapeia velocidades por operadora, ou um app em que os usuários reportam o clima local para melhorar a previsão, acho razoável que ele possa dizer “ou me dê a localização exata, ou não me dê nada; eu não quero localização falsa”
      A plataforma teria que decidir se daria exceções para apps que recebem dados contribuídos por usuários e que afetam outras pessoas
      A Apple parece ter encontrado um meio-termo bem bom nisso. Não é necessário permitir “localização exata” para um app, e no caso de fotos também dá para mostrar ao app apenas as imagens escolhidas pelo usuário por meio do seletor de imagens fornecido pelo sistema
    • No iOS, o pior é o Google Photos. Se você não der acesso a todas as fotos, nem consegue abrir o app, e ele também não aceita a opção de permitir só as fotos selecionadas
      Isso vale até quando você só quer ver fotos que já estão salvas na nuvem
    • Mesmo que se diga que “os apps devem lidar de forma elegante quando o usuário negar acesso aos dados reais”, o que fazer se eles não cumprirem isso?
      Isso equivale a propor uma solução organizacional para um problema técnico, então é difícil fazer funcionar; a única solução prática é dados falsos. Para o app, tem que parecer que a permissão foi concedida, mesmo que na realidade não tenha sido

  • Em Android com root, o XPrivacy já conseguia fazer isso há 7 anos, e existem alternativas mais modernas também. Mas faz tanto tempo que não faço root no celular que não posso garantir: https://github.com/M66B/XPrivacy
    Claro, isso não é o caminho principal, e eu concordo que deveria vir embutido por padrão. Mas tanto Android quanto iOS permitem absurdos como apps com restrição regional ou bloqueio de captura de tela para conteúdo com DRM, então não vai ser fácil

    • Usando isso desse jeito, senti na prática como tudo foi projetado contra o usuário, e deixei de acreditar que celular é computador
      O celular é um dispositivo de entrega de conteúdo do fabricante, e o usuário fica à mercê deles
    • O XPrivacy era realmente incrível, mas em celulares modernos fazer root e instalar o Xposed ficou muito mais complicado, ou foi totalmente bloqueado
      O GrapheneOS não se dava muito bem com apps bancários, o Google quebrou várias vezes o root via Magisk no Android Beta, e em algum momento eu simplesmente parei de me importar
      Talvez o GrapheneOS ou projetos parecidos consigam oferecer esse tipo de recurso
    • O XPrivacy era excelente, mas ao negar algumas permissões os apps travavam com frequência. No fim, ele não conseguia fornecer dados falsos bem o bastante
      Era tão ruim que eu nunca apertava “negar” de cara, sempre começava com “negar temporariamente”. Se o app funcionasse, eu negava em definitivo; se travasse, precisava descobrir o conjunto mínimo de permissões que tinha que liberar
    • Essa função não deve entrar numa imagem de fábrica nem no Android upstream, mas se houver demanda suficiente dos usuários, há chance de aparecer em projetos como o LineageOS
    • “Apps com restrição regional” na verdade não são bem isso, e sim um mecanismo que permite distribuir um app apenas nas regiões escolhidas por cada loja de aplicativos
      É uma função importante para as app stores, porque um app pode não oferecer uma boa experiência em todos os países, pode não estar localizado em todos os idiomas, pode não haver moderadores para conteúdo naquele idioma, pode haver exigências legais locais, ou as licenças de distribuição de conteúdo protegido por direitos autorais podem se limitar a países específicos
      A prevenção de captura de tela em conteúdo com DRM é um recurso solicitado pelos desenvolvedores por causa de exigências legais das licenças de conteúdo, como filmes. Os estúdios não querem que as pessoas transmitam ou gravem filmes, então as plataformas de apps precisam de um jeito de exibir esse conteúdo com segurança

  • “Se alguém faz uma pergunta que não tem o direito de fazer, você não tem obrigação de dizer a verdade”
    — Leonard Schiffman
    Fonte: “Blend me in: Privacy-Preserving Input Generalization for Personalized Online Services” https://drive.google.com/file/d/10OmoqMmHFcb7PsQtaU_GW4aCAJe...

  • Há um problema com a ideia de que, ao pedir permissões, o sistema operacional deveria oferecer não só “sim/não”, mas também “sim, mas forneça dados falsos ao app”
    Muitos usuários nem sabem como encaminhar um e-mail
    Imagine a confusão se essas pessoas escolhessem dados falsos ao usar a navegação do Google Maps sem entender o que isso significa
    Google Maps: “Vire à direita”
    Motorista numa estrada à beira-mar: “Beleza”
    Carro: splash

    • Isso é inteiramente um problema de experiência do usuário
      Basta esconder a função de falsificação de dados nas configurações avançadas, explicá-la claramente em linguagem simples antes de ativá-la e deixar óbvio na tela que o app está recebendo informações alternativas por causa de um recurso de privacidade ativado pelo próprio usuário, e que isso pode ser desativado facilmente
      Ainda haverá quem ative por engano, mas isso pode trazer muito valor para muitos outros usuários
    • Isso parece uma oportunidade de aprendizado. Ou talvez uma oportunidade darwinista
      De qualquer forma, é um problema que se resolve sozinho
    • Então basta tornar essa configuração uma opção para usuários avançados. Usuários não familiarizados nem precisam ver a opção
    • Nesse caso, o motorista não estava vendo direito para onde estava indo, e isso é outro problema
      Parece melhor que o sistema operacional ofereça “sim”, “não” e “personalizar”. Ao escolher “personalizar”, pode haver mensagens de aviso dentro desse menu, se necessário, mas não se deve impedir o usuário de ajustar como quiser
    • Fico me perguntando se muita gente usa o Google Maps no iOS. “Fornecer dados falsos” parece o tipo de coisa que a Apple até poderia fazer, mas é difícil acreditar que o Google faria isso
      O Apple Maps não teria esse problema. Dá para baixar mapas no dispositivo, então ele pode funcionar offline sem conexão de dados

  • Surpreende que ninguém no comentário mais votado tenha mencionado que, no iOS, não dá para distinguir se a permissão foi concedida ou não
    Por exemplo, quando um app pede acesso às fotos, ele sempre recebe um array. Se a permissão for negada, esse array vem vazio, então não dá para saber se a biblioteca do usuário está realmente vazia ou se o acesso foi negado. É simples e elegante
    Claro, no caso de fotos quase todo mundo tem pelo menos algumas, então dá para usar heurísticas. Mas em outros tipos, como dados de saúde, isso não é tão óbvio

  • Acho que “fornecer dados falsos” é a abordagem errada. A melhor abordagem deveria ser fornecer dados de uma fonte alternativa, e essa fonte alternativa deveria poder ser qualquer outro programa
    A fonte alternativa pode ser dados vazios, dados aleatórios, dados falsos mas consistentes, dados de um arquivo alternativo (por exemplo, uma lista de contatos separada ou fotos de um arquivo no lugar da câmera), dados transformados (por exemplo, inverter as fotos da câmera de cabeça para baixo), filtragem, registro, perguntar ao usuário sobre cada dado individualmente, fornecer códigos de erro em vez de dados e permitir que o usuário defina o código de erro, e qualquer outra coisa que o usuário quiser. Isso deveria incluir até o acesso à data/hora atual
    Isso aumenta o controle do usuário e também é útil para testes e acessibilidade
    Uma das minhas ideias de design de sistema operacional é permissões por proxy. Incluir permissões por proxy na segurança baseada em permissões, usar isso para toda entrada e saída, poder usar isso no shell de comando de uma forma melhor do que pipes UNIX, e também de outras formas. Incluindo data/hora. Fora Yield e Quit, nenhuma chamada de sistema poderia ser usada sem uma chave de permissão

    • Essa é a melhor abordagem e, na prática, a única que pode funcionar
      É muito difícil para desenvolvedores de apps lidar bem com permissões indisponíveis, e como isso amplia e dificulta muito o escopo de testes para um grupo relativamente pequeno de usuários, a maioria dos apps comerciais pequenos provavelmente nem tentaria tratar isso direito
      Permitir a permissão, mas fornecer uma fonte alternativa de dados, é o mais fácil tanto para desenvolvedores quanto para usuários
      Claro, também pode facilitar fraudes. Por exemplo, bancos passariam a usar procedimentos de registro de dispositivo mais complexos

  • Não há necessidade de tornar isso hostil. A regra simples é: “não também é uma opção, exceto quando realmente não for”
    Se não for uma opção, isso precisa estar muito claro e provavelmente deve ser demonstrado no processo de revisão do app; caso contrário, o app deveria ser rejeitado
    Por exemplo, se TikTok/Instagram pedirem permissões de câmera e microfone, não é uma opção para ambas, porque nenhuma das duas é essencial para usar o app. Se parte do app puder ser usada sem uma determinada permissão, é responsabilidade do app ser projetado para funcionar assim. Se a câmera ou o microfone estiverem desativados, basta desabilitar condicionalmente apenas os recursos que exigem essa permissão
    Em termos mais simples, o ônus está em quem faz o pedido. Se não estiver claro ou se estiver tentando ser esperto, a resposta é não. Pode soar rígido, mas os desenvolvedores de apps podem evitar completamente essa etapa extra tornando as permissões opcionais
    Se o foco fosse obrigar isso, não haveria necessidade de uma pequena corrida armamentista, e essa também seria a melhor escolha para as pessoas

    • Parece bom, mas como isso seria imposto?
      Os únicos que podem impor isso aqui são as lojas de apps do Google/Apple/Microsoft. É difícil ter certeza de que eles têm incentivo suficiente para aplicar isso de forma consistente e amigável ao usuário. Se tivessem, provavelmente já teriam feito isso

  • Os celulares da Samsung têm botões de alternância para acesso à câmera e ao microfone
    Ao desligar, aparece esta mensagem:

    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.
    • No caso do acesso ao microfone: 
      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.

  • Em vez de “uma opção de ‘sim, mas fornecer dados falsos ao app’ para todas as categorias”, o ideal seria configuração por app
    Você pode não querer dar dados de localização para quase nenhum app, mas pode querer concedê-los ao Google Maps e a apps de chamada de emergência. O mesmo vale para contatos e dados pessoais
    No entanto, apps assim enfrentariam forte resistência do Google e de outras empresas que lucram com o perfilamento de usuários

    • Concordo, mas tem que ser por app e ao mesmo tempo por categoria de permissão
      Por exemplo, em um app você deveria poder fornecer dados reais para uma permissão, dados falsos ou dados personalizados/inseridos manualmente para outra, e negar uma terceira permissão
      Também pode haver casos em que você queira alterar temporariamente essas configurações para teste ou para algo como ver temporariamente o clima de outro lugar em um app de clima com localização atual e depois voltar para sua localização real

  • Se um app precisa dos meus dados para melhorar a minha experiência, e só a minha experiência, então, ao receber dados falsos, apenas a minha experiência deveria piorar. Isso não deveria importar para o desenvolvedor ou para o dono do app
    Mas, se o objetivo for minerar meus dados, como na maioria dos casos, então dados falsos funcionariam bem para atrapalhar isso
    Claro, em casos como o WhatsApp isso não ajuda muito. As pessoas sincronizam de bom grado toda a lista de contatos com Facebook/Meta em troca de uma experiência de mensagens um pouco melhor

    • Eu também tive que fazer isso e achei extremamente desagradável, mas isso não era só uma “experiência um pouco melhor”
      Pelo menos no celular, o app e o serviço mal ficam utilizáveis antes de sincronizar os contatos