- A partir de abril de 2026, dispositivos não verificados não poderão enviar nem receber mensagens com criptografia de ponta a ponta (E2EE) no Element
- Essa mudança segue uma atualização da especificação do Matrix e tem como objetivo reforçar a segurança das conversas de todos os usuários
- A verificação de dispositivos é o processo de provar criptograficamente que cada dispositivo pertence de fato ao usuário, eliminando a indicação de mensagens não confiáveis
- Daqui para frente, apenas dispositivos verificados poderão participar das conversas, e os ícones de aviso ou de escudo desaparecerão
- Essa medida é uma etapa central para construir um ambiente de comunicação seguro baseado em confiança
Visão geral da atualização de segurança
- A partir de abril de 2026, o Element bloqueará o envio e o recebimento de mensagens com criptografia de ponta a ponta por dispositivos não verificados
- Isso segue a atualização da especificação do Matrix anunciada na conferência Matrix de outubro de 2025
- Para continuar trocando mensagens criptografadas em dispositivos já existentes, os usuários deverão concluir a verificação de dispositivos
- O objetivo dessa atualização é garantir que as mensagens realmente venham do remetente pretendido
- Com isso, o Element busca oferecer a tecnologia de comunicação mais segura possível
Os riscos dos dispositivos não verificados
- Dispositivos não verificados podem se tornar um vetor de ataque
- Por exemplo, quando um ícone de aviso aparece durante uma conversa, isso pode significar apenas um dispositivo não verificado ou até uma tentativa de invasão de conta
- Ignorar esses avisos pode fazer com que riscos de segurança se espalhem por toda a rede
- O Element oferece criptografia de ponta a ponta por padrão para todos os usuários e, ao tornar a verificação obrigatória, pretende eliminar incertezas e a possibilidade de atividades maliciosas
O papel da verificação de dispositivos
- A verificação de dispositivos é um “handshake” criptográfico entre cada dispositivo, que comprova que ele realmente pertence ao usuário
- Mensagens enviadas de um novo dispositivo não verificado são marcadas como mensagens não confiáveis
- Ao tornar a verificação obrigatória, os usuários podem ter certeza de que todas as mensagens estarão em um estado confiável
Confiança como princípio de design
- No futuro, os dispositivos serão classificados em apenas dois estados: “verificado” ou “incapaz de participar da conversa”
- Ícones de aviso ou de escudo não serão mais exibidos
- Isso serve para evitar que os usuários se tornem insensíveis aos alertas
- A verificação de dispositivos contribui não só para a proteção individual, mas também para fortalecer o ambiente de confiança de toda a rede
- O Element está avançando em uma arquitetura de sistema com segurança em primeiro lugar, e o processo de verificação é um elemento central disso
O que os usuários precisam fazer
- Usuários que já verificaram seus dispositivos e configuraram uma chave de recuperação (recovery key) não precisam fazer mais nada
- Quem ainda não fez isso deve seguir estas etapas
- Verificar o status de verificação de todos os dispositivos, incluindo celular, web e desktop
- Configurar o recurso de recuperação (opcional, mas fortemente recomendado)
- O recurso de recuperação simplifica a verificação de novos dispositivos e permite restaurar a verificação mesmo se todos os dispositivos forem perdidos
- Os procedimentos específicos para cada plataforma podem ser consultados na documentação de usuário do Element
Restrições para quem não verificar
- Após abril de 2026, dispositivos não verificados terão as seguintes restrições
- Não poderão enviar mensagens
- Não poderão exibir o conteúdo das mensagens recebidas (será possível apenas saber que a mensagem chegou)
- Na prática, dispositivos não verificados não poderão ser usados em conversas com E2EE
- Ainda assim, poderão participar de conversas com a criptografia desativada
Construção de confiança e suporte
- O Element destaca que garantir confiança por meio da verificação de dispositivos é um ponto central da comunicação segura
- A mudança é considerada pequena, mas eleva significativamente o nível de segurança
- Em colaboração com os usuários, a meta é fazer com que todas as mensagens sejam tão confiáveis quanto uma conversa presencial
- Durante a transição, a equipe de suporte responderá às dúvidas dos usuários e ajudará a garantir uma adoção tranquila
1 comentários
Opiniões no Hacker News
Há 3 meses, encerramos o servidor e levamos a comunidade de volta para o IRC
Ainda tínhamos o IRC rodando em um contêiner Podman, então foi fácil voltar
Todo mês sofríamos com erros de verificação de dispositivo, falhas na descriptografia de mensagens e problemas de UX
No começo evoluiu rápido, mas é uma pena que quase não tenha havido melhora de UX nos últimos anos
A relação entre Matrix e Element também está confusa agora
A equipe de desenvolvimento parece indiferente, e o “policy server” proposto ainda está inacabado
as salas estavam vazias ou o envio travava, e eu nunca consegui trocar mensagens uma única vez
Ficaram obcecados com a ideia de um “banco de dados JSON descentralizado”
e parecem ter deixado de lado a usabilidade como sistema de chat
Ainda uso, mas ainda falta muito para atrair usuários em geral
Se a ideia for modernizar uma comunidade baseada em IRC, acho Jabber (XMPP) uma alternativa mais realista
Testei com amigos, mas a UX áspera tornava tudo pior do que outros mensageiros
e, quando o suporte à bridge com IRC acabou, deixou de haver motivo para usar
Há alguns meses, meus dispositivos foram desverificados aleatoriamente, e entrei usando a chave de recuperação, mas mesmo assim continuaram não verificados
A verificação cruzada entre iOS, Linux, Windows e Android simplesmente não batia
Esse processo de verificação forçada é, na prática, um offboarding involuntário
Se existe um método de verificação problemático, isso deveria ser comunicado no blog
Gosto do Element, mas esse tipo de coisa precisa de preparação prévia
Às vezes até funciona, mas logo sou desconectado de novo, e os pop-ups antigos de verificação de dispositivo continuam aparecendo
No fim, fico com medo de perder todos os meus perfis
Às vezes, toda vez que eu abria, precisava gastar 30 minutos resolvendo problema
A ideia é boa, mas a relação esforço-retorno é ruim demais
E isso também afeta negativamente a comunicação em projetos OSS
Eu uso bastante e nunca tive esse tipo de problema
Alguns meses atrás tentei implementar um bot para Matrix, mas os SDKs open source em Python
simplesmente não suportavam E2EE e verificação de dispositivo, e a experiência foi terrível
Em vez disso, encontrei o SDK interno em Rust (matrix-rust-sdk), que era bem decente
Havia também bindings FFI para Python/Kotlin, mas faltava documentação
Com ajuda de LLMs e do código-fonte, consegui fazer funcionar por pouco, e a verificação por emoji também deu certo
Agora a documentação melhorou bastante e também há um cliente de referência disponível
Li uma crítica ao Matrix que vi no Reddit,
dizendo que, por ter uma estrutura em que os dados ficam armazenados e duplicados permanentemente, o desempenho e a privacidade são fracos
O Signal protege até os metadados, mas no Matrix nomes de salas, participantes, horários etc. ficam expostos
Queria saber se isso é verdade e se é um protocolo com futuro
Hoje o nível de proteção de metadados é inferior ao do Signal, mas isso está melhorando
O Matrix tem um modelo de ameaças diferente, e permite escolher diretamente em quem confiar
Se operado em um servidor pequeno, expõe menos dados do que o Signal
Não é perfeito, mas vejo com bons olhos a velocidade de evolução e a direção do projeto
Isso é um requisito básico de privacidade, e mesmo assim a implementação é lenta
Os problemas de descriptografia de mensagens também continuam
Ainda assim, entre os sistemas abertos, acho que continua sendo a melhor opção disponível
então é vulnerável a ataques de SIM swapping
O design modular e descentralizado é ao mesmo tempo vantagem e barreira de entrada
O Signal, por ter uma estrutura simples, tem um nível de acabamento maior nas funções centrais
No fim das contas, é uma plataforma que parte do pressuposto de servidores confiáveis
Apesar das reclamações nesta thread,
acho razoável impedir que alguém faça login sem verificação e troque mensagens criptografadas
Uso Matrix há 6 anos e o processo de verificação agora está bem fluido
Quando o login por QR code estiver pronto, vai ficar muito mais fácil
As decisões pontuais podem até ser razoáveis, mas no conjunto há falta de comunicação e
documentação insuficiente, o que gera confusão
Para quem usa sempre está ok, mas quem usa de vez em quando precisa jogar o jogo da recuperação toda vez
Isso permite descriptografar mensagens anteriores ao login
O problema de UX foi terem permitido pular a etapa de verificação
O blog deveria ter definido claramente o que é verificação
À pergunta “o que é verificação?”
ao fazer login em um novo dispositivo, você realiza uma prova criptográfica de identidade com um dispositivo existente
Isso é feito por comparação de emojis, leitura de QR code ou inserção da chave de recuperação
Na maioria dos casos é rápido e simples, mas alguns clientes têm bugs
É só o processo de aprovar um novo dispositivo usando um dispositivo já existente
Foi o método de verificação mais fácil que já vi entre mensageiros criptografados
em que a aprovação acontece se os emojis exibidos nos dois dispositivos forem iguais
Ao entrar em um novo dispositivo, basta aprovar no dispositivo antigo
Eu uso o Thunderbird como cliente Matrix, mas
quando abro o Element ou o Nheko, eles avisam mutuamente que não estão verificados
Aperto o botão de verificar e nada acontece, e nenhum QR code aparece
A UX do Matrix é realmente um pesadelo
Parei de usar porque as atualizações são lentas
Não há sinal algum de melhora
Testei um cliente alfa e o pop-up de verificação não desaparece
Alguns clientes nem implementam o fluxo de verificação,
então a barreira de entrada para novos clientes deve ficar ainda maior
Os clientes dão crash com frequência, e o atraso de sincronização também é severo
Por esses motivos, acho XMPP uma opção melhor de chat descentralizado do que Matrix
O XMPP lida com falhas de forma elegante e não tem problemas de sincronização em tempo real
Para convencer colegas de trabalho, seria preciso uma UI melhor
Mas o XMPP ainda não tem Cross Signing nem backup de chaves,
então ainda falta conveniência em comparação com o Matrix
O Element é pesado, e os outros clientes têm um desequilíbrio grande de funcionalidades
Em vez disso, tentei voltar ao XMPP com um servidor Prosody
A documentação é um pouco pouco amigável, mas a eficiência de recursos foi impressionante
É marcante ver um servidor XMPP rodar bem até em hardware fraco
Fiquei um pouco decepcionado com o lado dos clientes,
mas acho que há muito espaço para melhorar a documentação
No fim, eu só quero que o ecossistema de mensageiros livres e open source prospere
Os vídeos mais recentes da Matrix Conference estão em media.ccc.de
Tem bastante coisa interessante e,
mesmo sem operar seu próprio servidor, dá para usar hospedagem paga como a etke.cc
Eu gosto muito de Matrix/Element
Administro vários espaços para a devroom da FOSDEM, e
até as chamadas de vídeo funcionaram perfeitamente
Só queria que mais recursos fossem adicionados