Eu nunca autorizei uma integração que verifica os meus segredos
Um projeto de automação residencial está sendo criticado por verificar silenciosamente, por padrão, senhas armazenadas contra o banco de dados de vazamentos do “Have I Been Pwned”, enviando os primeiros cinco caracteres do hash SHA‑1 de cada senha a um serviço de terceiros. Muitos usuários argumentam que mesmo esse compartilhamento limitado de dados viola as expectativas de um sistema local e focado em privacidade, e que deveria exigir consentimento explícito opt-in, especialmente diante de preocupações com confiança, GDPR e possíveis vazamentos de informação. A controvérsia é intensificada por uma resposta do maintainer percebida como desdenhosa — seguida de um pedido de desculpas e de medidas em direção a uma documentação melhor e a um modelo opt-in — o que levou alguns usuários a reconsiderar sua dependência da plataforma.
Funcionalidade e Comportamento
- O supervisor do Home Assistant inclui uma verificação de “senha comprometida”: ele faz o hash de segredos (por exemplo, senhas na configuração do HA) com SHA‑1 e envia apenas os primeiros 5 caracteres hexadecimais ao Have I Been Pwned (HIBP), depois faz a correspondência localmente usando k-anonimato.
- Esse comportamento existe há anos, mas uma mudança recente exibiu avisos, então os usuários perceberam.
- Há um sinalizador de linha de comando para desativá-lo, mas ele não estava documentado; uma PR agora visa torná-lo opt-in.
Privacidade, Consentimento e Expectativas
- Muitos comentadores dizem que o problema central é privacidade e consentimento, não criptografia:
- Os usuários não esperavam que um sistema local de automação residencial, “focado em privacidade”, contatasse serviços de terceiros sobre seus segredos por padrão.
- Vários argumentam que qualquer tráfego de saída não solicitado — “até mesmo um único byte” — é uma quebra de confiança e viola o princípio da menor surpresa.
- Alguns citam a própria comunicação de privacidade do projeto e um princípio de nuvem “opt-in por padrão” e dizem que esse recurso contradiz isso.
Debate sobre Segurança e k-Anonimato
- Um lado argumenta que o esquema é, na prática, seguro:
- Apenas 5 caracteres hexadecimais de um hash são enviados; o tamanho mediano do bucket é grande.
- Atacantes já precisariam de senhas fracas ou conhecidas; muitos outros gerenciadores de senha usam verificações semelhantes.
- Outro lado aponta pesquisas sobre ataques contra o uso do HIBP no estilo k-anonimato:
- Prefixos podem ajudar em força bruta e adivinhação de senhas.
- As requisições vazam metadados (IP, provável presença de certas senhas, uso de software).
- Eles enfatizam modelos de ameaça desconhecidos e defendem minimizar qualquer vazamento de informação.
- Alguns dizem que enquadrar isso principalmente como um problema de segurança é enganoso; trata-se principalmente de um problema de privacidade/confiança e de “telefonar para casa”.
Questões Legais e Regulatórias
- Alguns comentadores sugerem possíveis problemas com o GDPR devido a endereços IP e ao reuso de dados pessoais para uma nova finalidade.
- Outros questionam se o prefixo do hash, por si só, é Dado Pessoal Identificável (PII); a legalidade geral é descrita como incerta.
Resposta do Desenvolvedor e Confiança da Comunidade
- As respostas iniciais do maintainer são amplamente descritas como desdenhosas, sem sensibilidade e desnecessariamente confrontacionais (por exemplo, chamando as preocupações dos usuários de “ameaças” e sugerindo que eles façam um fork).
- Um acompanhamento posterior inclui um pedido de desculpas, esclarecimento do recurso e uma promessa de melhorar a documentação; alguns veem isso como genuíno, outros como controle de danos.
- Disputas passadas em outros projetos são mencionadas como contribuindo para preocupações sobre julgamento e cultura.
- Vários usuários dizem que esse incidente os faz reconsiderar adotar ou recomendar o Home Assistant; outros ainda o veem como superior às alternativas centradas na nuvem, mas consideram isso um sério erro de confiança.