A varredura no lado do cliente examina o conteúdo no dispositivo do usuário, onde ele já pode estar legível antes do envio ou após o recebimento. Portanto, ela pode criar um caminho de divulgação fora do canal de entrega criptografado. Comparar a soma de verificação de um APK não prova que o aplicativo não contém código de varredura. Isso responde a uma pergunta mais restrita: se os bytes selecionados correspondem a um determinado resumo criptográfico.
Manter essas afirmações separadas torna tanto a criptografia quanto a verificação de software mais úteis.
Por que a varredura no dispositivo muda o limite de privacidade
Um aplicativo precisa lidar com texto claro para mostrar uma mensagem ou preparar uma foto para envio. Uma função de varredura pode atuar nesse ponto, mesmo que a mensagem transmitida posteriormente pela rede seja criptografada de ponta a ponta. O que sai do dispositivo depende do projeto do mecanismo de varredura: ele pode relatar uma correspondência, enviar conteúdo selecionado ou transmitir outras informações derivadas.
O artigo de pesquisa Bugs in our Pockets examina riscos como abuso, falsos positivos e superfície de ataque adicional. Esses são motivos para inspecionar os fluxos de dados e a governança de um sistema de varredura proposto. Não demonstram que toda função no dispositivo seja vigilância nem que uma lei específica tenha imposto uma exigência universal de varredura.
Uma função local sob controle do usuário não equivale automaticamente a uma comunicação obrigatória. Pergunte quem escolhe a análise, o que a aciona, quem pode atualizar suas regras e quais dados podem sair do dispositivo.
Quatro formas diferentes de evidência sobre software
| Verificação | O que pode demonstrar | O que não pode demonstrar sozinha |
|---|---|---|
| Soma de verificação SHA-256 | O arquivo corresponde a um resumo de referência confiável | Que o programa de referência é seguro ou corresponde ao código-fonte |
| Verificação de assinatura de APK | A assinatura do pacote é válida e identifica um certificado de assinatura | Que o signatário é confiável ou o código não apresenta comportamentos indesejados |
| Compilação reproduzível | O código-fonte e as entradas de compilação especificadas podem produzir os artefatos esperados | Que o código-fonte não contém vulnerabilidades ou lógica prejudicial |
| Revisão e testes independentes | Constatações sobre uma versão e um escopo definidos | Uma garantia permanente que cubra todas as atualizações futuras |
A documentação do apksigner do Android explica a verificação de pacotes e a apresentação de certificados. A definição de Reproducible Builds explica por que o código-fonte, o ambiente de compilação e as instruções são todos importantes para reproduzir um artefato.
Um arquivo de código-fonte e uma soma de verificação impressa ao lado não constituem, por si só, um resultado de compilação reproduzível. Da mesma forma, uma assinatura válida em uma versão maliciosa continua sendo uma assinatura válida.
Como verificar um download sem extrapolar o resultado
Primeiro, identifique a versão pretendida e obtenha seu APK e o resumo esperado por um caminho de distribuição confiável. Calcule o resumo localmente. Se ele for diferente, não instale o arquivo enquanto a divergência não for explicada: outra versão, um download incompleto ou uma adulteração podem causar a diferença.
Se corresponder, registre a versão e o resultado. Você demonstrou igualdade de bytes em relação àquela referência, não a ausência de varredura no lado do cliente. Se o mesmo invasor puder substituir o download e a soma de verificação exibida, a comparação ainda poderá ser aprovada. Referências independentes, continuidade da chave de assinatura e transparência das versões ajudam a tratar diferentes partes desse problema de confiança.
Para uma alegação de correspondência entre código-fonte e binário, procure instruções documentadas de compilação e resultados reproduzidos de forma independente para a versão real. Não deduza essa propriedade das palavras “código aberto”.
As atualizações continuam importantes
A distribuição de software pode sofrer ataques, mas evitar atualizações de segurança indefinidamente não é uma defesa geral sensata. As atualizações também corrigem vulnerabilidades exploráveis. Use um canal de atualização confiável, leia avisos de segurança relevantes e verifique evidências de versão quando seu risco justificar isso. Uma versão antiga com uma falha conhecida não é mais segura apenas porque sua soma de verificação correspondeu no passado.
O que o Proof Lab da Livara demonstra
O Proof Lab da Livara oferece uma comparação local de resumo de APK e demonstrações criptográficas no navegador. A página afirma que não executa os mecanismos de ratchet completos de LVR1/LGS1 e não constitui uma auditoria de protocolo. Seu modelo de ameaças também explica a limitação quando um invasor pode substituir tanto um arquivo quanto seu resumo esperado.
Essas verificações são úteis dentro de seu escopo. Não provam que um telefone com o aplicativo instalado esteja livre de malware, que a Livara tenha versões reproduzíveis de forma independente ou que seu aplicativo não possa conter comportamentos não divulgados. Leia a documentação de segurança separadamente para conhecer os limites declarados da proteção de mensagens.
A pergunta certa não é se um selo diz “verificado”. É qual alegação foi testada, em relação a qual referência confiável e para qual versão exata.
