- Após a HSBC determinar por meio de um pixel de rastreamento se os clientes recebiam e-mails, enviou por engano um aviso de “e-mail devolvido” a clientes que na verdade estavam recebendo normalmente
- O banco exigiu que os clientes atualizassem o endereço de e-mail, mas a conta do cliente já tinha o endereço correto cadastrado
- A análise mostrou que os e-mails da HSBC continham pixels de rastreamento baseados em HTTP, o que pode expor informações pessoais como horário de recebimento, frequência e endereço IP
- Como pixels de rastreamento não funcionam quando há bloqueio configurado, usar isso como base para concluir que o “e-mail não foi recebido” foi apontado como mau uso técnico
- A HSBC deve migrar para o fim do rastreamento não criptografado, respeito à privacidade e comunicação clara com os clientes
Aviso incorreto de devolução de e-mail pela HSBC
- A HSBC enviou aos clientes uma notificação por carta pedindo atualização do endereço, alegando que “o e-mail foi devolvido”
- O cliente, na realidade, estava recebendo e abrindo normalmente os e-mails da HSBC
- Ao verificar a conta online, o endereço de e-mail cadastrado estava correto
- No atendimento via chat, repetia-se apenas a resposta protocolar de que “se o banco enviou a carta, o endereço precisa ser alterado”
- Só depois, por telefone, veio a resposta de que “se o endereço estiver correto, a carta pode ser ignorada”
- O autor sugeriu à HSBC trocar a frase “ação necessária” por “necessário confirmar o endereço”
Estrutura e problemas dos pixels de rastreamento em e-mail
- Na parte inferior dos e-mails da HSBC havia dois códigos de imagem de 1×1 pixel
- Esses pixels são usados como mecanismo de rastreamento que acessa um servidor quando o destinatário abre o e-mail, registrando a abertura
- A HSBC estava transmitindo esses pixels pelo protocolo HTTP, o que cria uma vulnerabilidade de segurança ao permitir que terceiros na rede saibam que o e-mail foi aberto
- Em redes Wi‑Fi públicas, existe a possibilidade de outros usuários da mesma rede detectarem essa informação
- Também foi mencionado o risco de um atacante inserir imagens no rodapé do e-mail para falsificá-lo como mensagem de phishing
Falta de confiabilidade e mau uso dos pixels de rastreamento
- O autor usa configuração de bloqueio de pixel de rastreamento, portanto não envia informações de abertura do e-mail
- Esse é o funcionamento original previsto do e-mail, em que o destinatário pode escolher divulgar ou não a leitura
- Ao não receber sinal do pixel, a HSBC aparentemente interpretou isso de forma equivocada como “e-mail não recebido” e tratou o caso como devolução
- Trata-se de um caso de mau uso do pixel de rastreamento como ferramenta de identificação individual do cliente, e não de análise estatística
- Como resultado, a HSBC acabou enviando uma notificação falsa de que “o e-mail foi devolvido”
Sugestões de melhoria apresentadas à HSBC
- Encerrar o rastreamento não criptografado (HTTP): é necessário usar HTTPS para evitar exposição na rede ao abrir e-mails
- Não tratar bloqueio de rastreamento como recusa de recebimento: a falha no pixel pode ocorrer por vários motivos técnicos
- Parar de monitorar os hábitos de e-mail dos clientes: um banco que já possui dados pessoais suficientes não precisa de vigilância adicional
- Validar endereços de e-mail por verificação direta: recomenda-se um processo baseado em consentimento explícito, como “clicar em um link de confirmação”
- Seguir princípios de ética de dados: conforme os ‘princípios para o uso ético de dados e IA’ divulgados pela HSBC, é preciso garantir adequação de propósito e transparência
Conclusão
- A HSBC entendeu mal os limites de confiabilidade dos pixels de rastreamento e, com isso, julgou incorretamente o e-mail dos clientes
- Este caso mostra que práticas de coleta de dados típicas do capitalismo de vigilância penetraram até a operação de instituições financeiras
- O autor enfatiza que a HSBC deve reconhecer o erro técnico e reforçar o uso transparente de dados e a proteção da privacidade dos clientes
1 comentários
Comentários no Hacker News
Chamou atenção o fato de ainda estarem servindo conteúdo por HTTP em 2026
Isso teria sido pego se tivessem feito uma revisão de segurança minimamente decente; parece que pularam essa etapa por completo
Eu trabalho com dados bancários, e os sistemas internos também são uma verdadeira bagunça
Até dentro do mesmo banco, os formatos de data em CSV variam, e as descrições das transações são strings truncadas sem padronização
Mesmo com tanta pressão regulatória, ainda estar assim mostra que a maioria dos bancos trata a infraestrutura digital como encanamento velho
Mas cada banco corta o tamanho dos campos de memo de um jeito diferente, ou faz bagunças como a AMEX, que inverte os campos NAME e MEMO
Ainda assim, pelo menos existe um padrão mínimo
Documentação relacionada: Open Financial Exchange, Financial Data Exchange
Até as telas de ATM passam a mesma sensação de coisa ultrapassada
Por exemplo, ACME HTTP-01 challenge, emissão de certificados e respostas CRL/OCSP ainda usam HTTP
Veja RFC8555 e a documentação do Let's Encrypt
Portanto, generalizar dizendo que “HTTP não serve mais para nada” está errado
HTTPS também troca SNI, então dá para saber quem está se comunicando com o HSBC
O restante da URL parece ser só um ID de rastreamento anonimizado, então a ameaça real não parece tão grande
Afinal, usar HTTPS torna a configuração e a gestão de certificados mais complicadas
Fiquei pensando por que isso aconteceu
Em TI bancária, implementar até uma única função de rastreamento de e-mail envolve dezenas de pessoas e leva pelo menos um ano
Com certeza houve algum desenvolvedor que disse “em 2026 HTTP é arriscado”, mas no fim os gerentes intermediários provavelmente ignoraram isso
A diretoria continuava perguntando por que algumas pessoas abriram e não havia registro, ou por que outras não abriram e mesmo assim havia registro
Como os redatores viam que a taxa de abertura era maior que a taxa de cliques, usavam isso como métrica de desempenho
No fim, todo mundo usa métricas imprecisas para sentir que está indo bem
A liderança toma todas as decisões, e os desenvolvedores só fazem o que mandam
Eu mesmo já trabalhei em um grande banco, e quem não sai depois de alguns anos vira só alguém que “aperta botão e recebe salário”
É muito melhor do que aquelas mensagens do tipo “você tem uma mensagem importante, faça login”
Recursos de conveniência, como apps de condomínio, vão aos poucos se tornando obrigatórios, até todos os usuários terem que se adaptar
Nesse processo, o controle individual diminui
Nem o salário nem o ambiente são bons, e quase não há espaço para inovação
O NAB Australia faz exatamente a mesma coisa
Se você não carregar imagens remotas no e-mail, eles mandam uma carta dizendo que “o e-mail não está sendo entregue” e mudam você para extrato em papel
Na prática, os e-mails estavam chegando normalmente
Eles desativaram automaticamente os alertas de saldo porque concluíram que eu não lia os e-mails
Só que eu apenas tinha desativado a confirmação de leitura e bloqueado recursos remotos
Acabei mudando de banco
Caixas de correio de apartamento costumam receber entregas erradas, ser furtadas ou até pegar fogo
Anos atrás eu recebia spam de marketing do Bank of America, e não havia opção de cancelamento
Então desativei aquele endereço de e-mail, e eles mandaram uma carta pedindo correção porque “o e-mail estava retornando”
No fim, deixei aquilo desativado por anos, até que mais tarde surgiu uma função de preferências de e-mail
Minha esposa ainda recebe spam postal do Citi, e lá também não existe jeito de cancelar
Vendo isso, é realmente idiota que a equipe de TI do HSBC tenha concluído, com base em um tracking pixel, que “o e-mail não foi lido”
Hoje em dia, a maioria dos clientes de e-mail já bloqueia imagens por padrão
A capacidade técnica do HSBC é realmente péssima
O app de internet banking parece coisa do começo dos anos 2000, e um familiar meu ainda usa; vive dando erro
Não é erro do usuário, é problema do sistema
Se quiser fazer o banco ouvir o cliente, o mais eficaz é encerrar a conta
Claro, você tem que estar disposto a realmente mudar de banco
Se o problema ficar registrado oficialmente, dá para agir quando ele se repetir
Veja a matéria do The Guardian
Eu mesmo fui afetado na época e depois migrei para a Wise
O Capital One faz algo parecido
Pelo menos deixa claro que o problema é “você não abriu e-mails recentes”, então dá para entender o que querem dizer
Na prática, eu abri os e-mails, só bloqueei o tracking pixel
Não tenho motivo para resolver o problema deles
O Gmail baixa imagens antecipadamente, então na prática o tracking pixel é chamado mesmo que o usuário não abra
Não testei diretamente, mas outros serviços de e-mail provavelmente fazem algo parecido
Como a maioria dos serviços de e-mail pré-carrega imagens no lado do servidor para verificar malware,
na prática o pixel tracking quase sempre acaba sendo processado por um provedor externo de serviços de e-mail
Também passei exatamente pela mesma situação com o HSBC
O processo era excelente: consegui abrir a conta em 10 minutos com identidade digital e recebi um cartão Apple Pay em um dia
Só que, quando recusei receber e-mails de marketing, eles enviaram um e-mail de “boas-vindas com upsell”; quando ele retornou, bloquearam a conta
Acabei passando pela mesma situação que o OP
O Charles Schwab também é assim
Os e-mails chegam normalmente, mas eles dizem que “não estão sendo entregues” e mudam para extrato em papel
O problema real é o bloqueio do tracking pixel
E-mails em domínio personalizado dão erro, mas o endereço do ProtonMail funciona normalmente
Provavelmente porque o ProtonMail não bloqueia tracking pixel
Agora simplesmente parei de me importar
Como correio em papel custa dinheiro para eles, uma hora devem perceber