Última atualização: 24 de agosto de 2026
Esta página existe pra descrever, com o máximo de precisão técnica possível, o que a Linka realmente faz por baixo do capô pra proteger suas conversas e seus dados — sem promessa vaga de "levamos segurança a sério". Onde dá pra verificar de fora (como a nota de segurança de rede abaixo), deixamos o link pra você conferir com suas próprias mãos.
Chamadas de voz e vídeo são ponta a ponta por construção: qualquer conexão de chamada na Linka usa WebRTC, e o WebRTC exige DTLS-SRTP em toda mídia trafegada — isso não é uma escolha de configuração da Linka, é uma exigência do próprio padrão web, presente em qualquer navegador compatível com a especificação. Isso vale mesmo quando a chamada passa por um servidor de retransmissão (TURN, via Cloudflare) em redes mais restritivas: o servidor de retransmissão encaminha os pacotes cifrados sem nunca ter acesso às chaves de sessão, então ele não consegue decifrar o conteúdo.
Mensagens de texto usam um modelo de chave mantida no aparelho, no mesmo espírito do que apps como Signal fazem: cada dispositivo gera seu próprio par de chaves ECDH sobre a curva P-256 diretamente no navegador/app (Web Crypto API), a chave privada nasce marcada como não-extraível e nunca sai do aparelho — só a chave pública é enviada pro servidor. Cada mensagem é cifrada por dispositivo destinatário com ECDH + HKDF-SHA256 + AES-256-GCM antes de sair do aparelho de quem envia. O servidor da Linka nunca vê o conteúdo em texto claro, nunca guarda a chave privada de ninguém, e não tem como decifrar as mensagens — mesmo sob ordem judicial, o máximo que existe pra entregar é texto cifrado.
Os cabeçalhos de segurança HTTP da Linka são avaliados publicamente pelo HTTP Observatory da Mozilla/MDN, uma ferramenta independente que qualquer pessoa pode rodar contra qualquer site. A nota atual é A+ (120 de 100 pontos base), com Content-Security-Policy estrita — sem unsafe-inline nem unsafe-eval, ou seja, o navegador recusa executar script ou estilo que não venha explicitamente autorizado — HSTS pré-carregado nos navegadores, e os demais cabeçalhos padrão de proteção (X-Frame-Options, Referrer-Policy restritivo, X-Content-Type-Options, Cross-Origin-Opener-Policy). Clique no link acima a qualquer momento pra ver a nota de hoje, não a nossa palavra.
Além da autorização feita pela aplicação, o banco de dados da Linka aplica controle de acesso por linha (Row-Level Security) diretamente no Postgres: cada consulta já chega no banco com a identidade de quem está perguntando, e o próprio banco — não só o código do servidor — decide quais linhas essa identidade pode ver ou alterar. É uma camada a mais, redundante de propósito: mesmo que uma consulta no código da aplicação tivesse uma falha, a política do banco ainda barra o acesso indevido.
A segurança da Linka não é um item que se marca como "pronto" uma vez e se esquece — é revisada em rodadas estruturadas, com descoberta de problemas, correção, teste e nova rodada. Isso já encontrou e corrigiu problemas reais antes que afetassem alguém — é assim que qualquer sistema sério funciona: presumindo que sempre existe algo pra achar, não anunciando perfeição.
Pesquisadores de segurança podem reportar vulnerabilidades de forma responsável em /.well-known/security.txt (padrão RFC 9116) ou diretamente em safety@linkanetwork.app.
A Linka não vende dados de comportamento pra anunciantes nem opera um feed algorítmico otimizado pra maximizar tempo de tela — o modelo de negócio é assinatura e personalização visual (skins), não atenção. Isso importa pra segurança porque significa que não existe incentivo interno pra coletar mais dados do que o necessário pra rede funcionar.
Padrões de Segurança Infantil
Política de Privacidade
Termos de Uso
Ajuda & Suporte