2 pontos por GN⁺ 2024-12-29 | 1 comentários | Compartilhar no WhatsApp
  • O Enhanced Visual Search foi adicionado ao Photos no iOS 18 e no macOS Sequoia, e no iPhone e no Mac do autor ele estava ativado por padrão
  • Esse recurso ajuda nas buscas ao fazer uma correspondência privada de marcos e pontos de interesse nas fotos com o índice global nos servidores da Apple
  • A Apple explica que usa criptografia homomórfica, privacidade diferencial e relay OHTTP para que as informações das fotos não possam ser conhecidas, mas a própria comunicação com o servidor se torna o centro do debate sobre privacidade
  • O foco da crítica não é a má-fé da Apple, mas a possibilidade de bugs de software, tendo como base o fato de que vulnerabilidades continuam aparecendo nas notas de lançamento de segurança da Apple
  • No macOS, é possível bloquear parte da comunicação com o Little Snitch, mas no iOS não existe a mesma opção, o que dificulta que o usuário se proteja por conta própria

Ativação padrão do Enhanced Visual Search

  • Um novo item chamado Enhanced Visual Search foi adicionado às configurações do Photos no iPhone, e ele estava ativado por padrão
  • A mesma configuração também foi adicionada ao Photos no macOS Sequoia, e no Mac ela também estava ativada por padrão
  • O autor desativou manualmente essa configuração antes de tirar as capturas de tela

Como funciona segundo a documentação da Apple

  • O documento Photos & Privacy da Apple informa que o Enhanced Visual Search permite pesquisar fotos por marcos ou pontos de interesse
  • O dispositivo faz uma correspondência privada dos locais nas fotos com o índice global dos servidores da Apple
  • A Apple afirma usar as seguintes tecnologias para proteger a privacidade
    • Criptografia homomórfica

    • Privacidade diferencial

      • Relay OHTTP para ocultar o endereço IP
      • Segundo a documentação da Apple, a configuração pode ser desativada em iOS e iPadOS em Settings > Apps > Photos e, no Mac, em Photos > Settings > General
      • O artigo da Apple Machine Learning Research Combining Machine Learning and Homomorphic Encryption in the Apple Ecosystem foi publicado em 24 de outubro de 2024, enquanto o lançamento geral do iOS 18 e do macOS 15 ocorreu em 16 de setembro de 2024

Críticas à privacidade

  • O ponto de partida da crítica é que a Apple reforçou uma experiência no dispositivo com comunicação com o servidor mesmo sem solicitação do usuário
  • Pelo critério do autor, algo só é privado quando todo o processamento termina dentro do aparelho, e, se os dados vão para os servidores do fabricante, é difícil considerar isso totalmente privado
  • O autor também afirma que não pode avaliar diretamente se a implementação da Apple é tecnicamente segura
  • Ainda assim, ele considera difícil confiar integralmente nas alegações de privacidade da Apple porque vulnerabilidades continuam aparecendo nas notas de lançamento de segurança da empresa
  • A crítica é que, mesmo sem má-fé ou conspiração, apenas bugs de software já podem deixar o usuário vulnerável, e a Apple não pode garantir um software sem falhas

Escolha do usuário e ferramentas de bloqueio

  • O autor não tem interesse no Enhanced Visual Search e, por isso, entende que não há benefício que justifique assumir esse risco, mesmo que o recurso funcione perfeitamente
  • A forma de ativar o recurso sem a permissão do usuário é criticada como um desrespeito ao usuário e às suas preferências
  • Ele argumenta que o slogan publicitário da Apple, “What happens on your iPhone, stays on your iPhone.”, não condiz com esse caso
  • No macOS, é possível bloquear em grande parte a comunicação remota do software da Apple com o Little Snitch
  • No iOS, ferramentas como o Little Snitch não são permitidas, o que passa a sensação de que a Apple impede que os usuários se protejam por conta própria

Material complementar

1 comentários

 
GN⁺ 2024-12-29
Opiniões do Hacker News
  • O que eu quero é muito simples: quero software que não envie nada pela internet antes de haver uma intenção explícita
    O trabalho de engenharia para tornar esse recurso plausivelmente privado é legal, e implementar esse tipo de recurso em si não é um problema, mas ele precisa ser necessariamente opt-in
    Enquanto o software tratar o usuário final e recursos como seus dados e sua conexão de rede como um playground do fornecedor, a confiança continuará sendo corroída. Dados de dispositivos locais não devem vazar inesperadamente para fora de uma interface sem fio, e recursos que fazem dados locais saírem pela rede precisam estar necessariamente ligados à intenção do usuário
    Acho que a resposta cínica para por que a Apple simplesmente não perguntou aos usuários se queriam ativar esse recurso é que a Apple sabe que alguns usuários recusariam imediatamente se fossem perguntados, mas sente que sabe mais do que esses usuários. Não gosto dessa atitude, e acho que é pelo mesmo motivo que cresce a insatisfação com telemetria opt-out

    • Esse tipo de mentalidade gerou os terríveis banners de cookies
      Aumentar o número de caixas de diálogo nas quais a maioria dos usuários vai clicar em “permitir” sem pensar não resolve o problema
      A sociedade basicamente aceitou como normal entregar acesso a dados a terceiros, e adicionar atrito a isso acaba punindo 98% das pessoas por causa dos 2% que de qualquer forma não usariam esses serviços
      Com um público mais educado, talvez o equilíbrio pudesse mudar, mas a realidade não é essa, e uma boa experiência de usuário precisa refletir a realidade
    • Opt-in não funciona, e para começo de conversa nunca funcionou
      A esmagadora maioria dos usuários, mais de 95%, não entende o que um pop-up quer dizer, parece nem ter a capacidade de lê-lo, e sempre aceita, sempre recusa ou clica no botão que estiver mais chamativo
      Observe familiares que não são da indústria de tecnologia nem da classe de gestores profissionais, e pergunte a eles o que era o pop-up que acabaram de fechar e por que o fecharam; você terá a melhor lição sobre a interação entre tecnologia e privacidade
    • O Fotos do iOS há muito tempo permite pesquisar fotos pelo endereço em que elas foram tiradas
      Para isso, é preciso pegar a latitude/longitude da localização da foto e transformá-la em um endereço compreensível por humanos, o que quase sempre é feito consultando um serviço global de geocodificação reversa
      Fico curioso se você também considera esse recurso uma violação de privacidade e acha que ele precisa ser opt-in. Se não, não entendo por que um serviço de geocodificação reversa seria mais privado do que um serviço de consulta de pontos de referência
    • O resultado é algo como https://chromewebstore.google.com/detail/i-still-dont-care-a...
      Pessoalmente, não acredito que esses pop-ups cumpram algum propósito. No fim, não há como provar de forma razoável que um site está agindo de boa-fé. O fato de um app perguntar se pode contatar um servidor não garante que clicar em “não” vá realmente impedir o rastreamento
      Continua me surpreendendo ver as pessoas se convencendo de que privacidade em escala vai funcionar com várias combinações de botões sim/não. Só há duas formas de confiar em software: 1. ingenuamente verificar onde está escrito “privacy first” 2. entender até quais instruções o software em execução pode executar
      Pop-ups de permissão também não têm granularidade suficiente. Ao permitir acesso à lista de contatos, quais contatos exatamente são acessados? Dá para permitir só nomes e bloquear números de telefone? O processamento é offline ou online? Se for online, deve aparecer outro pop-up de acesso à internet? Então também deveríamos conseguir filtrar que tipo de atividade na internet ele faz? Descendo por esse caminho, no fim se chega a um sistema de permissões Turing-completo; caso contrário, a “privacidade” fica com buracos
    • Mesmo com opt-in, os fornecedores vão continuar importunando o usuário até ele clicar em “sim” em um momento de descuido
      Tenho certeza de já ter visto caixas que eu não marquei aparecerem marcadas. Eu queria desativar essas coisas e nunca mais deixá-las serem reativadas, mas os fornecedores jamais permitiriam isso. É por isso que uso Linux
  • Os usuários do meu app gratuito e open source parecem se surpreender com o fato de não termos absolutamente nenhum insight sobre padrões de uso
    Há situações em que uma pequena quantidade de telemetria anônima ajudaria enormemente, mas não pretendo mexer nisso
    O opt-in não só reduz muito o volume de dados, como também introduz um grande viés nos dados selecionados, tornando-os inúteis. As pessoas que fariam opt-in provavelmente não são uma boa amostra do “usuário típico”
    O opt-out, mesmo que ofereça quaisquer proteções ou garantias, é inaceitável para alguns usuários, e eles vão deixar isso bem claro
    Entendo que é fácil para agentes mal-intencionados abusarem da telemetria e que “dados anônimos” podem se revelar, de uma variedade surpreendente de maneiras, nada anônimos. Ainda assim, fico com aquela sensação de “é por isso que não podemos ter coisas boas”

    • Não lembro onde vi isso antes, mas havia um site que coletava dados de analytics no lado do cliente em algo como um buffer circular e, no menu de configurações, permitia enviá-los uma única vez, enviá-los sempre ou baixá-los manualmente
      Quando ocorria um erro, aparecia um toast pedindo para compartilhar os dados de analytics para ajudar na solução do problema e, claro, era possível recusar. Foi provavelmente o melhor sistema que já vi, mas não lembro qual era o site
    • O ponto central se resume a consentimento. Sem opt-out, não há consentimento algum; se o padrão é opt-out, a qualidade do consentimento cai bastante. A confiança é o único caminho para o consentimento
      1. Para criar confiança, é preciso um tripé: opt-in, consentimento em formato de pesquisa e opt-out. A pesquisa é uma validação ativa da confiança e ajuda na comunicação de baixa largura de banda. A pergunta deve ser feita quando o usuário usa o app pela primeira vez ou na próxima inicialização do app depois que esse recurso for adicionado
      2. É preciso fornecer ao usuário final exatamente as informações analíticas desejadas, de modo que ele também consiga analisá-las. Oferecer um relatório ou visualização para que ele avalie por conta própria quais informações podem ser compartilhadas melhora a confiança
      3. Permissões confiáveis levam a mais consentimento. Também é possível direcionar suporte prioritário a recursos e bugs para usuários que fizeram opt-in. O histórico de analytics e as informações de desempenho podem ajudar a resolver um bug recém-reportado
        Apple, Microsoft, Google etc. tratam o compartilhamento de analytics de forma vaga, sem detalhes, e não deixam claro como isso pode ser usado ou abusado. A maioria nem sequer oferece opt-out. Não confio nessas organizações, mas preciso lidar com elas na minha vida. Não preciso usar Facebook ou Twitter e, de fato, não uso. Aceito a pesquisa da Steam
        Para resolver a falta de informações analíticas de que a comunidade open source se beneficiaria, um RFC de padrão de analytics consensual poderia ser um passo. Seria uma forma de as duas partes consentirem em uma comunicação acordada
        Do meu ponto de vista, metadados também são dados pessoais. Sem o usuário, não há dados nem metadados. Como o usuário final é a entropia dos metadados, o proprietário dos metadados e dos dados é o usuário
    • Talvez fosse possível fazer a coleta de estatísticas no dispositivo e, a cada alguns meses, mostrar um pop-up exibindo essas estatísticas
      Não sei bem que tipo de viés isso acrescentaria
      Por exemplo, algo como perguntar: “Nós criamos este app e levamos privacidade a sério. Estas são as informações coletadas durante o uso no último mês. Podemos enviar essas informações para nós para melhorar o app?”, mostrando os dados coletados em um formato legível por humanos
    • Não é óbvio por que o opt-in torna os dados inúteis. Isso também pode depender de como o opt-in é apresentado
      Em geral, eu esperaria que fosse uma solução viável. Mesmo que o grupo que faz opt-in seja diferente do “usuário típico”, são os melhores dados que se pode obter de forma honesta e ética. Com certeza deveria ser melhor do que não ter dado nenhum, não?
      Em todos os sites e apps que exibem banners de consentimento de cookies com opt-in, esse estado já se aplica implicitamente
    • Esse é um dos principais motivos pelos quais as pessoas geralmente criam coisas na Web
      É muito difícil melhorar software de desktop, e usuários de Linux em particular tendem a ser hostis a padrões que possibilitam melhorias
  • Concordo 100%:
    “A única maneira de garantir privacidade na computação é não enviar dados para fora do dispositivo”
    “Cabe a cada usuário decidir quanto risco de violação de privacidade está disposto a aceitar. [...] Ao ativar um ‘recurso’ sem sequer perguntar, a Apple não respeita o usuário nem suas preferências. Eu nunca quis que meu iPhone entrasse em contato com servidores da Apple.”
    Não importa o quanto o recurso seja ofuscado, “seguro” ou tenha outras características de “proteção de privacidade”: isso não muda o fato de que alguma informação derivada de conteúdo pessoal é transmitida sem consentimento prévio.
    Mesmo que a informação esteja protegida, toda consulta de rede é informação. Um timestamp de que determinada ação foi feita em determinado momento; por exemplo, se algo é enviado a esse serviço logo após adicionar uma nova foto, isso pode revelar o fato de que uma foto foi tirada, um local específico correlacionado com a informação de localização daquele horário, e por aí vai; isso é só a ponta do iceberg. Transmitir informações do dispositivo do usuário sem consentimento explícito é uma violação de privacidade.

    • Então isso quer dizer que mensagens do Signal também não são seguras porque são transmitidas, e que “ofuscação” não basta para proteger dados? Fico me perguntando se a pessoa leu o que a Apple diz que realmente faz com os dados antes da transmissão, algo que ela citou e depois admitiu não ter entendido.
      Acho possível levantar o argumento sobre metadados, mas ele também envolve várias suposições. Em especial, a suposição de que a Apple na prática não usa OHTTP e conspira para descobrir quando o usuário tirou uma foto. Se você basicamente não confia na matemática, não sei onde a incerteza e a desconfiança terminam.
    • A premissa “supondo que, assim que uma nova foto é adicionada, como quando se tira uma foto, algo seja enviado a esse serviço” está errada, e a conclusão saltou em cima dela.
      É fácil verificar que isso não acontece imediatamente após tirar uma foto. Primeiro, o tráfego de rede mostraria isso, e na prática não mostra. Segundo, criptografia homomórfica é cara demais para fazer isso. O Photos normalmente não sincroniza imediatamente; dá para perceber isso porque a maioria dos usuários de iPhone vê o app Photos indicar quando a sincronização acontece. Operações caras em geral ficam na fila até o dispositivo estar ligado à tomada e no Wi-Fi.
    • Quanto espaço seria necessário para armazenar modelos de todos os lugares conhecidos do mundo e de objetos comuns?
      Por exemplo, enviei a uma amiga uma foto de um cachorro dentro de uma banheira, e os AirPods dela, via iPhone, anunciaram “alguém enviou uma foto de um cachorro na banheira”. Ela também achou legal, e pessoalmente acho um recurso útil. Só não sei até que ponto isso exige processamento fora do dispositivo.
    • Todos esses problemas são tratados no post do blog da Apple sobre a implementação desse recurso. Duas etapas são aplicadas para reduzir o risco:
      1. o iOS cria consultas falsas adicionais, e todas as consultas passam por um escalonador que impede distinguir consultas reais de falsas pelo horário da consulta ou identificar o momento em que a foto foi tirada.
      2. Todas as consultas são feitas anonimamente usando um serviço de retransmissão de terceiros. Assim, a Apple não consegue vincular uma consulta específica a um dispositivo ou endereço IP específico.
        Considerando essas duas mitigações, para obter dados pessoais por meio desse recurso seria preciso primeiro comprometer o telefone do alvo para desativar as consultas falsas e, em seguida, comprometer o retransmissor para correlacionar as consultas com um endereço IP específico.
        Se você consegue fazer tudo isso, honestamente é um desperdício idiota de esforço. Bastaria usar a invasão do iOS para fazer o dispositivo enviar dados de localização diretamente. Não haveria necessidade de esperar o alvo tirar uma foto, rastrear várias consultas a pontos de referência e juntar um pouco de dados extras a cada consulta para no fim identificar a localização do alvo.
        Isso tudo me lembra o XKCD 538.
        https://machinelearning.apple.com/research/homomorphic-encry...
  • Tenho a impressão de que isso é uma cortina de fumaça para reintroduzir aos poucos a varredura de CSAM depois da reação negativa anterior. O comportamento de vir ativado por padrão é suspeito.
    [1] https://www.wired.com/story/apple-photo-scanning-csam-commun...

    • Pensei exatamente a mesma coisa. Parece algo como: “Temos uma tecnologia sofisticada de fingerprinting de imagens, mas seu uso para detectar CSAM é polêmico demais para lançar; então vamos colocar o fluxo central em algo que pareça útil para o usuário, mantendo o código vivo, melhorando e pronto para expansão futura.”
      É uma pergunta interessante se esse fingerprinting pode ser limitado de forma confiável apenas a pontos de referência públicos, e isso depende de detalhes de implementação que não estão claros.
      Mesmo que a busca visível ao usuário seja limitada a ‘pontos de referência’, será que, nesse processo, ainda que apenas no dispositivo, ela cria previamente fingerprints de muitas outras coisas? Se for o caso, um malware não persistente ativado por pouco tempo conseguiria encontrar imediatamente imagens de interesse sem o acesso mais amplo e o processamento adicional que originalmente seriam necessários.
    • Sim. É uma forma de introduzir um elemento de contato com servidor sob o pretexto de um “matching de localização” aparentemente inofensivo.
      O índice global naturalmente também fará matching com outros marcadores que a Apple considere valiosos, mesmo que não os retorne ao usuário.
    • É exatamente a mesma forma como a Microsoft “recuou” no Recall. Depois, no fim, enfiou de volta e tornou impossível de remover.
    • Também penso assim. A tecnologia era cara demais, então parece que eles precisavam testá-la ou executá-la para provar que era privada.
      Acho que um modelo para encontrar pontos de referência em fotos também poderia rodar localmente, mas não tenho 100% de certeza aqui.
    • Não. Quaisquer que sejam os outros defeitos da Apple, não acho que seja isso.
      Pelo lado cínico: uma funcionalidade de engenharia nessa escala não pode ser planejada sem documentação, e essa documentação inevitavelmente apareceria em tribunal.
      Pelo lado superficial: a Apple quer sinceramente oferecer recursos úteis que exigem participação de servidores.
  • Sobre a parte de não entender a maioria dos detalhes técnicos do post no blog da Apple: eu entendi o trecho citado e, desculpe, mas este texto poderia ter sido otimista. Algo como “olhem esta nova tecnologia incrível!”
    Eu detesto as práticas da Apple que vão contra hackers no sentido de HN tanto quanto qualquer um e, por motivos assim, nem tenho dispositivos Apple, mas dizer “não importa como eles resolveram a questão de privacidade, eu sinto que não é privado” não transforma isso em fato.
    Como a maioria das outras pessoas provavelmente também não entende as palavras citadas, e nem é certo que tenha lido até ali, isso parece uma crítica injusta.

    • Ouvi falar de criptografia homomórfica há alguns anos por meio de artigos de pesquisa.
      Pelo que entendi na época, operações como SUM podiam calcular a soma de uma lista de números criptografados. Graças ao método de criptografia, era possível somar todos os valores sem descriptografá-los, e o resultado também permanecia criptografado; quando o proprietário o descriptografava, obtinha um número com uma precisão conhecida.
      Se a Apple estiver usando criptografia homomórfica corretamente, ela não deveria ter como ver os dados recebidos do telefone. As outras coisas mencionadas no texto são medidas para impedir vazamentos de informação por metadados ou canais laterais.
      Não é muito bom que esse recurso venha ativado por padrão. Deveria ser um recurso que, após a atualização, perguntasse ao usuário se ele quer ativá-lo.
    • A crítica central é que dados privados e sensíveis são enviados à Apple sem consentimento e sem aviso.
    • Como confiar em algo que você não entende? No fim, a confiança precisa vir de alguma pessoa ou organização que se acredita entender esse tipo de problema, ou seja, de uma autoridade.
      Para muita gente, essa autoridade não é a Apple. Eu confio com cautela nas políticas de privacidade da Apple, mas muita gente não confia na Apple, e há motivos para isso.
      Então, quando um recurso da Apple que você não optou por usar compartilha dados pessoais e você também não entende a explicação técnica da Apple, a sensação de ter sofrido uma violação de privacidade aumenta, o que leva a uma desconfiança ainda maior. Dá para chamar isso de crítica injusta?
    • Você está criticando alguém que tem interesse direto mesmo sem ter dispositivos Apple?
      Meu post no blog foi escrito da perspectiva de um usuário da Apple cuja confiança foi traída. É ótimo achar a tecnologia interessante a uma distância segura, e ela pode mesmo ser, mas isso não tem relação com o problema central: a ausência de consentimento do usuário.
  • Para mim, no geral, parece um recurso razoável, implementado levando bastante em conta a privacidade do usuário. Mas talvez eu esteja confiando demais na explicação.
    O texto, no geral, parece feito para provocar indignação, e acho que precisamos tomar cuidado para não “morder a isca” de posts assim no Hacker News. É parecido com o cuidado que devemos ter quando aparecem textos indutores de raiva em tabloides ou no Facebook.
    Algumas preocupações do texto ou desta thread parecem ter pouca probabilidade de afetar muito a receita da Apple. Uma preocupação que alguns clientes reais poderiam ter é o uso de dados; imagino que, no modo de baixo consumo de dados, esse recurso provavelmente fique desligado.
    Fico pensando se esse tipo de problema poderia ser resolvido com uma configuração como padrões de privacidade. Algo que permitisse a jornalistas, ativistas, certos departamentos de TI corporativos e pessoas que escrevem textos como o original escolherem uma configuração em que, ao atualizar o OS, ele se comunique menos com a rede. Criar uma UI fácil de entender parece difícil. O iOS já tem o “Modo de Isolamento”, mas não sei se ele afeta essa configuração.

    • O que a Apple deveria ter feito era simplesmente não deixar isso ativado por padrão. Enviar qualquer coisa pela rede sem perguntar reduz cada vez mais a confiança na Apple.
    • É um recurso razoável, mas ainda assim precisa de opt-in do usuário. Para reduzir a fricção, os opt-ins poderiam ser agrupados e perguntados durante a instalação ou atualização.
    • O que não está especialmente claro é se o iOS escaneia todos os dados dentro do telefone e envia parte deles para um índice público.
      Pelo modo como o recurso aparece na UI, não parece ser o caso. Se o recurso é ativado pela ação do usuário, fico me perguntando se isso também deveria ser considerado contato com o servidor.
    • Se outra empresa tivesse feito isso, talvez desse para ver como um recurso razoável implementado de forma razoável. O problema é que a Apple gastou dezenas a centenas de milhões de dólares anunciando que não faz esse tipo de coisa.
      A narrativa era que essas coisas ficam dentro do iPhone, ao contrário daquele outro OS desagradável operado por uma empresa de publicidade. Que a Apple nunca extrai seus dados, que você não é o produto e que a Apple se importa com você.
      Algo assim, seja razoável isoladamente ou não, destrói completamente essa narrativa. Se eles estão dispostos a mentir de forma tão explícita em outdoors gigantes, não dá para saber o que mais farão quando os interesses pedirem.
  • Acho que acabei de ver uma configuração parecida relacionada a busca que parece não existir antes do iOS 18.
    Em Ajustes -> Busca, há uma opção “Help Apple Improve Search”, ativada por padrão.
    “Permita que a Apple armazene buscas digitadas no Safari(!!), Siri e Spotlight de uma forma que não seja associada a você, para ajudar a melhorar a Busca. As buscas incluem consultas de conhecimento geral e solicitações como tocar música e obter rotas.”
    Se isso já existia antes, foi ativado de novo.

    • A parte “armazenar buscas digitadas no Safari [...] de uma forma que não seja associada a você” ignora que, já há 10 anos, pesquisas sobre desanonimização deixavam claro que o histórico de buscas revela completamente o usuário.
      Eu precisaria de muitos detalhes para acreditar que a forma como a Apple armazena isso protege minha privacidade de maneira confiável. É claro que a citação não afirma isso.
    • Isso é mais grave que o post original. Em que universo paralelo a Apple vive para achar aceitável coletar histórico de buscas das pessoas por padrão, sem consentimento?
    • Droga, é verdade. Também estava ativado por padrão no meu dispositivo, e não acho que eu jamais teria consentido com isso.
    • Sim. Essa também é mais uma configuração ativada por padrão.
  • Como referência, no macOS o serviço photoanalysisd roda em segundo plano e vasculha as fotos mesmo que você nunca tenha aberto o Apple Photos
    Não dá para desativá-lo sem desligar o SIP, isto é, a Proteção de Integridade do Sistema; para isso, é preciso passar por um procedimento complicado, com várias reinicializações e alertas. Se você religar o SIP, ele é reativado
    Por algum motivo, a Apple parece bastante entusiasmada com a análise de fotos, quer o usuário queira ou não

    • Talvez você também se surpreenda ao saber que o Spotlight vasculha todos os arquivos do Mac
    • Ainda assim, isso não roda localmente no Mac?
    • Em tese, CSAM já poderia fazer parte de algum serviço local. A partir do momento em que passou a ser necessária uma conta vinculada ao dispositivo, a privacidade acabou. Não estou falando só do iCloud, mas de uma conta vinculada ao próprio dispositivo. Não é preciso uma conta para usar um computador Linux
    • Ele contata o servidor? Não me importo que meus arquivos sejam escaneados. O que me incomoda é que detalhes dos meus dados privados saiam do dispositivo
    • A parte “por algum motivo, a Apple parece bastante entusiasmada com a análise de fotos, quer o usuário queira ou não” não ficaria vulnerável se fosse contaminada pelos usuários finais?
      E se todo mundo rodasse um gerador local de imagens treinado com suas próprias fotos, mas levemente corrompido, e depois enchesse de lixo a coleta de hashes de fotos da Apple?
      E depois?
      Seria uma ótima ação de limpeza. Dá para aprender muito observando quem fica irritado e o quanto
  • Isso me lembra a indignação, na época da Covid, com o sistema de notificações de exposição da Apple e do Google, que preservava a privacidade
    Parece contraintuitivo que seja possível avisar sobre exposição sem rastrear, mas a tecnologia de fato tornou isso possível
    Aqui também, o autor parece se apoiar numa reação imediata a uma violação de privacidade, sem tentar avaliar adequadamente o efeito de tecnologias como vetorização no lado do cliente, privacidade diferencial, retransmissão OHTTP e criptografia homomórfica
    Dito isso, concordo 100% que a Apple deveria primeiro pedir consentimento do usuário para esse tipo de recurso

    • Eu gostaria de avaliar a privacidade dessas tecnologias
      Se alguém colocasse links para o código-fonte, eu poderia ver exatamente o que elas fazem, em vez de acreditar em algum desconhecido na internet
      Melhor ainda seria se me deixassem compilá-las eu mesmo
    • Aquele recurso da COVID era opt-in. O autor agora está reclamando justamente da falta de opt-in
  • Sobre a parte “não entendo a maior parte dos detalhes técnicos do post do blog da Apple”, eu entendo
    Vetorização no lado do cliente: a foto é processada localmente para preparar, antes do envio, uma representação vetorial irreversível. Pense em algo como um hash baseado em significado
    Privacidade diferencial: antes do envio, acrescenta-se bastante ruído ao vetor. O suficiente para tornar inviável a busca reversa do vetor. Aqui, o nível de ruído é ε = 0,8, o que é bastante bom em termos de privacidade
    Retransmissão OHTTP: a transmissão passa por um terceiro, então a Apple não consegue saber o endereço IP. O conteúdo é criptografado, de modo que o terceiro também não aprende nada. Há o risco de vazar algo como “o IP X é usuário do Apple Photos”, mas não o conteúdo da biblioteca
    Criptografia homomórfica: a operação de consulta é executada no servidor sobre dados criptografados. A Apple não consegue descriptografar o conteúdo do vetor nem o conteúdo da resposta, e só o cliente consegue descriptografar o resultado da consulta
    É assim que se parece um bom desenho de privacidade. Há várias camadas de segurança de privacidade, e qualquer uma das três últimas, sozinha, deveria ser suficiente para proteger a privacidade
    Quanto à afirmação de que “o nível de tolerância de cada pessoa ao risco de violação de privacidade deve ser decidido pelo usuário individual”, o autor, embora pareça um pesquisador de segurança da Apple, está basicamente dizendo que aqui não consegue fazer uma escolha informada
    Não tenho certeza de qual é o julgamento correto. Mas a conclusão “portanto, a única forma de garantir privacidade computacional é não enviar dados para fora do dispositivo” não é verdadeira. Existem ferramentas que oferecem privacidade mesmo usando serviços, como privacidade diferencial e criptografia homomórfica. Elas são muito complexas, e o usuário não consegue avaliar realisticamente o risco, mas, se você quer recursos que exigem conjuntos de dados maiores que o disco ou conteúdo que muda com frequência, precisa dessas ferramentas

    • Obrigado pela explicação, mas acho que ela não aborda o problema central. Meus dados estão sendo enviados para fora do dispositivo por padrão, sem um aviso razoável
      Muitos usuários poderiam concordar com esse recurso. Como você disse, ele pode até ser muito seguro. Mas o problema é presumir que todos concordaram por padrão
    • Um “bom desenho de privacidade” é minhas fotos não serem enviadas, de forma alguma, para lugar nenhum sem permissão opt-in explícita
    • Você está apresentando uma falsa dicotomia entre “compreensão perfeita do usuário” e “nenhuma escolha para o usuário”. A questão não é se o usuário consegue entender completamente criptografia homomórfica ou privacidade diferencial, mas sim consentimento e transparência básicos
      O usuário não precisa de um doutorado para entender “este recurso envia dados sobre suas fotos aos servidores da Apple para melhorar a busca”
      O fato de as proteções de privacidade serem complexas não justifica remover a escolha do usuário. Por essa lógica, nenhum recurso técnico deveria jamais ser perguntado ao usuário
      Muitos usuários com alta consciência de privacidade seguem um princípio simples: querem controlar o que sai do dispositivo, independentemente de como isso é protegido
      O argumento de que “é complicado demais de explicar” poderia justificar qualquer configuração padrão invasiva à privacidade. Você aplicaria o mesmo critério ao argumento de que tudo bem deixar serviços de localização ativados por padrão porque explicar a tecnologia de GPS é complexo demais?
      A solução real é simples: explicar o recurso em linguagem fácil, destacar os benefícios, resumir as medidas de proteção de privacidade e deixar o usuário escolher. A Apple já faz isso em muitos outros recursos. Padrão desligado e opt-in são princípios centrais de um design que respeita a privacidade, por mais robustas que sejam as proteções nas camadas inferiores
    • Um bom desenho de privacidade, na prática, é não enviar nenhuma informação a ninguém, para lugar nenhum, em momento algum
    • O autor não é pesquisador de segurança da Apple
      Jeff Johnson desenvolve apps para plataformas da Apple, especialmente extensões do Safari, e escreve com frequência em seu blog sobre incômodos com a Apple, mas não é pesquisador de segurança