Olá, Habr!
Primeiro, o mais importante: eu não sou advogado. Sou um engenheiro que trabalha em um resolvedor DNS próprio nas madrugadas e precisei ler leis não por prazer, mas porque é o meu negócio e eu precisava entender o que podia ou não podia prometer aos usuários. Tudo o que está abaixo é a minha interpretação após a leitura das fontes primárias, e não um aconselhamento jurídico. Se você está construindo um negócio ou uma estratégia de compliance com base nessas conclusões, contrate um advogado especializado em privacidade da UE. É para isso que eles existem.
As formulações legais foram escritas por advogados para advogados, e lê-las é quase tão prazeroso quanto decifrar a letra de um médico. No entanto, na indústria de DNS, há muitas promessas de 'nós somos privacy-first' e pouca concretude sobre o que um provedor pode fisicamente e é obrigado a fazer em cenários específicos. Vamos analisar o CLOUD Act, FISA 702, GDPR e Schrems II, e ver como essas leis transformam 'privacidade' em uma palavra de marketing ou em uma proteção real.
Eu desenvolvo o VantageDNS, um resolvedor DNS recursivo com filtragem, incorporado na Finlândia. Eu tenho 'skin in the game': eu mesmo preciso entender o que posso e o que não posso fazer. Sem declarações grandiosas como 'temos o único DNS seguro do mundo'. Somos uma das opções da UE, e o objetivo deste artigo é explicar como as opções da UE se diferenciam das opções dos EUA.
O que é o CLOUD Act
Adotado nos EUA em 2018. A sigla é curiosa: Clarifying Lawful Overseas Use of Data Act. A palavra 'clarifying' aqui é um eufemismo, pois a lei não esclareceu a posição existente, mas a expandiu. A essência chave em uma frase: um provedor americano é obrigado a entregar dados mediante solicitação das autoridades dos EUA, mesmo que os dados estejam fisicamente localizados fora dos EUA. A jurisdição se estende não pelos servidores, mas pela corporação. Ou seja, se o NextDNS (uma corporação americana com sede em Delaware) armazena logs de consulta em um servidor na Alemanha, esses dados ainda estão sujeitos ao CLOUD Act. E o argumento de 'mas nossos servidores estão na UE' aqui não é válido.
Há uma nuance que gostam de mencionar em marketing: o CLOUD Act permite que o provedor conteste uma solicitação se ela conflitar com leis estrangeiras (por exemplo, com o GDPR). No papel, é encorajador. Na prática, o procedimento é raro, caro, e o provedor precisa ter advogados sérios e vontade de processar o governo dos EUA. A maioria cumpre, pois é mais barato e seguro para o negócio. Não vi casos públicos em que um provedor de DNS contestou com sucesso uma solicitação do CLOUD Act com base na lei de privacidade da UE. Se você conhece algum, compartilhe nos comentários.
O texto completo do 18 USC § 2713 (seção chave do CLOUD Act): "A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider’s possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States."
Tradução para o bom português: "entregue os dados, não importa onde eles estejam."
O que é a Seção 702 da FISA
Se o CLOUD Act trata de solicitações direcionadas com alguns procedimentos, a FISA 702 trata de coleta em massa. O Foreign Intelligence Surveillance Court (FISC, o 'tribunal secreto' em linguagem comum) emite autorizações de vigilância sob parâmetros gerais, sem processo público. O alvo deve ser um 'estrangeiro fora dos EUA', mas a coleta frequentemente inclui incidentalmente cidadãos americanos e não-alvos. Isso foi documentado pelas divulgações de Snowden e relatórios subsequentes do PCLOB (Privacy and Civil Liberties Oversight Board); recomendo a leitura dos relatórios públicos deles, que são surpreendentemente francos para um órgão governamental.
A FISA 702 não fala explicitamente sobre resolvedores DNS, mas há precedentes de aplicação a ISPs, empresas de telecomunicações e provedores de nuvem. Os logs de consulta DNS são um tesouro de metadados: mostram a quais domínios uma pessoa acessou, quando e de onde. Se um provedor tem a capacidade técnica de transmitir esse fluxo, é legalmente obrigado a fazê-lo e tem uma corporação nos EUA, formalmente nada impede que o FISC emita uma diretiva apropriada.
Aqui, geralmente se objeta: 'mas isso é para estrangeiros, não afeta cidadãos americanos'. Para o público do Habr, a maioria são justamente 'estrangeiros fora dos EUA', o alvo direto da FISA 702. Se o seu resolvedor DNS está nos EUA, todo o seu fluxo de consultas é formalmente estrangeiro para os EUA, independentemente da sua cidadania.
O que é o GDPR do ponto de vista de um provedor
O GDPR é um documento enorme, e para um provedor de dados, os artigos mais relevantes são:
- Artigo 6 (base legal): Qualquer processamento de dados pessoais deve ter uma base legal. Para DNS, geralmente é o legitimate interest (devemos resolver a consulta para fornecer o serviço) ou contract (o usuário assinou um plano pago). Marketing não se enquadra em legitimate interest.
- Artigo 17 (direito de apagamento): O usuário pode solicitar a exclusão de seus dados, e o provedor é obrigado a fazê-lo em um prazo razoável, geralmente 30 dias. Se sua política de retenção é de '90 dias de logs de consulta' e um usuário solicita a exclusão no 10º dia, você é obrigado a excluir, não a esperar o fim da retenção.
- Artigo 32 (segurança): Criptografia em repouso (at rest), criptografia em trânsito (in transit), controle de acesso, registro de acesso: tudo isso é exigido. Não é um 'seria bom', é exigido.
- Artigo 33 (notificação de violação): 72 horas para notificar o regulador em caso de violação (breach). Não uma semana, não um mês. 72 horas.
O principal para DNS: o legitimate interest cobre o funcionamento básico (resolução de consulta), mas NÃO cobre retenção para marketing, profiling ou venda a terceiros. E o usuário tem o direito de saber o que exatamente é armazenado sobre ele, bem como solicitar a exclusão.
O GDPR não é algo que pode ser 'aplicado parcialmente'. Se você processa dados de residentes da UE, você está totalmente sob o GDPR. Eu os adoro como se adora um gato velho: são resmungões, mas honestos, e trazem benefícios concretos.
Schrems II e transferências UE↔EUA
Em 2020, o CJEU (Tribunal de Justiça da União Europeia) no caso Schrems II anulou o EU-US Privacy Shield, um mecanismo pelo qual empresas americanas podiam receber dados de cidadãos da UE com base em autocertificação. O argumento do CJEU: os EUA não garantem um 'nível de proteção equivalente' devido à FISA 702 e outros regimes de vigilância.
Desde então, para transferir dados da UE para os EUA, são necessárias Standard Contractual Clauses (SCCs), mais uma Transfer Impact Assessment (TIA), e 'medidas suplementares', geralmente criptografia, para que o parceiro americano tecnicamente não possa ler os dados.
Aqui começa o interessante. Se um provedor de DNS tem uma controladora americana ou é uma corporação americana, ele é, por definição, obrigado a receber dados nos EUA (para conformidade com o CLOUD Act), e as SCCs sozinhas não são suficientes para legalizar isso. Por isso, muitos serviços 'amigáveis à UE' com corporação nos EUA estão tecnicamente em um limbo jurídico: formalmente as SCCs foram assinadas, mas Schrems II não foi cumprido. Os reguladores sabem disso, mas a aplicação pontual ainda é rara, e a indústria vive nesse regime cinza. A realidade, como sempre, me atingiu com força quando comecei a investigar isso.
Em 2023, surgiu o EU-US Data Privacy Framework, uma tentativa de substituir o Privacy Shield. Muitos advogados (e Max Schrems pessoalmente) acreditam que o DPF não resolve os problemas fundamentais e que ele também será anulado em uma terceira iteração.
Jurisdições de provedores de DNS específicos
Este é o ponto mais desagradável do artigo, pois inevitavelmente simplificarei. Cada um desses provedores tem sua própria estrutura corporativa complexa, e uma única tabela não transmite as nuances. No entanto:
| Provedor | Corporação em | Datacenters | Risco CLOUD Act | Jurisdição GDPR |
|---|---|---|---|---|
| NextDNS | EUA (Delaware) | Global | Sim | via SCC + Risco Schrems II |
| Cloudflare | EUA (Delaware) | Global anycast | Sim | via SCC + Risco Schrems II |
| AdGuard DNS | Chipre + Equipes RU | Global | Chipre = UE, Conexões RU nebulosas | Tecnicamente UE |
| Control D | Canadá | Global | Canadá Five Eyes, MLA com EUA | Específico do Canadá |
| Quad9 | Suíça | Global | Não | via SCC, mas CH = adequação |
| VantageDNS | Finlândia | UE + 3 PoPs não-UE | Não | GDPR completo |
Alguns comentários. O Quad9 é uma fundação suíça, tem uma boa posição, e a Suíça tem uma decisão de adequação da UE, o que simplifica as transferências. O Control D é canadense, e o Canadá faz parte do Five Eyes, o que significa cooperação de inteligência com os EUA (mas não tão intensa quanto uma corporação americana). O AdGuard é uma empresa cipriota com equipes na Rússia e Armênia, e a parte cipriota é formalmente da UE, mas eu pessoalmente faria uma TIA mais cuidadosa para eles do que para o Quad9. NextDNS e Cloudflare são ambos de Delaware, e eu os respeito como produtos de engenharia, mas juridicamente eles estão naquela zona cinza de Schrems.
Eu não estou nesta lista para autopromoção (ou melhor, não apenas para autopromoção), mas porque escolhi a jurisdição especificamente, e toda a arquitetura se baseia nisso.
O que o 'Risco CLOUD Act' significa na prática para o usuário
Cenários concretos para ser mais específico.
- Subpoena em um caso criminal: Um promotor dos EUA quer saber quem, do provedor X, assinou o endpoint
config_id=ABC123. O provedor é obrigado a entregar tudo o que tiver: e-mail, IP de faturamento, logs de consulta do período, horários. O usuário não é notificado, geralmente há uma ordem de sigilo (gag order) durante o período de investigação. - National Security Letter (NSL): O FBI solicita dados mais uma ordem de sigilo, ou seja, proibição de falar com qualquer pessoa sobre o recebimento da NSL. O provedor não pode nem mesmo atualizar seu warrant canary sem violar formalmente a ordem de sigilo, e é por isso que os warrant canaries estão em uma zona cinza jurídica (mas falaremos disso abaixo).
- Coleta em massa da FISA: O fluxo de dados é coletado para análise, sem direcionamento no momento da coleta. Isso poderia ser formalmente aplicado a tabelas de consultas de provedores de DNS dos EUA: veja as divulgações de Snowden sobre coleta upstream e cooperação com ISPs de nível 1.
Nenhum desses cenários significa que o NextDNS está vazando seu log de consulta para a NSA neste exato momento. A maioria dessas solicitações é direcionada e rara. A questão é que o provedor tem a capacidade física e jurídica de fazê-lo se a solicitação chegar. E para usuários críticos de privacidade, 'não fará na prática' é muito mais fraco do que 'não pode arquiteturalmente'.
O que a 'Jurisdição da UE' significa na prática
Um conjunto simétrico de cenários para um provedor com corporação na UE. Se o regulador finlandês Liikenne- ja viestintävirasto (Traficom) ou um órgão da UE quiser dados:
- Solicitação criminal via MLA: O processo de Mutual Legal Assistance Treaty é lento, requer justificativa, requer sanção judicial, e a notificação ao usuário é obrigatória por lei da UE (com atraso, mas não um gag-forever, como nos EUA). Para solicitações de países não-UE, o mesmo processo de MLA através do Ministério da Justiça finlandês, ainda mais lento.
- Solicitação relacionada ao GDPR de uma Autoridade de Proteção de Dados: Geralmente para verificar a conformidade, não para vigilância. O regulador pode exigir que você mostre como organiza o processamento de dados, qual a retenção, como implementa o direito de apagamento. Isso é sobre auditoria, não sobre entregar dados do usuário.
- Solicitação russa ou chinesa: A Finlândia não entrega dados sem MLA, e o MLA com a Rússia está congelado desde 2022. Portanto, para usuários russos, a jurisdição da UE é, paradoxalmente, uma proteção real contra o próprio Estado. O mesmo para usuários chineses: existe MLA com a China, mas é restrito e dados de DNS não podem ser extraídos por ele.
A jurisdição da UE não torna um provedor impenetrável. Se a polícia finlandesa estiver investigando CSAM ou terrorismo grave com uma sanção apropriada, os dados serão extraídos. Mas o procedimento é lento, transparente (pós-fato) e com alvo específico, ao contrário da coleta em massa.
O que a jurisdição da UE não protege
A transparência é mais importante que manipulações. Sobre fronteiras:
- Controladora americana ou investidor americano com controle do conselho: O CLOUD Act pode ser aplicado através do véu corporativo, se uma entidade americana tiver 'posse, custódia ou controle'. Eu sou o único proprietário, na Finlândia, sem investidores americanos. Isso foi feito propositalmente e está escrito em meus documentos constitutivos.
- Provedor de nuvem americano para armazenamento: Se um serviço com corporação na UE armazena dados na AWS, GCP ou Azure, é formalmente um serviço americano atuando como processador, e os dados ficam sujeitos ao CLOUD Act. Eu uso Hetzner (DE+FI) e servidores dedicados na UE.
- Backups no US-S3 ou US-CDN: O mesmo. Meus backups estão no Hetzner Storage Box na UE, e os logs são descartados no ClickHouse em Helsinque, sem CDN americano em nenhuma camada.
- CDN antes do site: Aqui há um compromisso parcial: um landing page estático através de PoPs da UE, mas se amanhã eu conectar o Cloudflare para proteção DDoS, isso precisará ser documentado honestamente.
A arquitetura de privacidade é um sistema com furos, e é importante não fingir que não há furos. É mais útil listá-los.
Warrant Canary
Uma vez por semana, eu assino com minha chave PGP um arquivo que diz 'no período tal, não recebi NSLs nem solicitações secretas similares'. O arquivo é publicado em vantagedns.com/canary. Se a assinatura parar de ser atualizada a tempo, o usuário tira suas conclusões.
Juridicamente, o warrant canary é uma zona cinza. Um tribunal pode me proibir de atualizar a assinatura, mas não pode me forçar a assinar um canary falso retroativamente, pois isso seria obstrução da justiça. Portanto, a ausência de atualização é um sinal, não mais forte do que 'algo está errado', mas também não mais fraco. Mullvad, IVPN, Riseup fazem isso. Eu também. Não porque seja uma bala de prata, mas porque é uma das poucas maneiras disponíveis para um provedor sinalizar um problema sem violar diretamente a ordem de sigilo.
Importante: o warrant canary só faz sentido em jurisdições onde ordens de sigilo existem. Na Finlândia, uma ordem de sigilo em nível nacional é um mecanismo raro e limitado no tempo, portanto, nosso canary é mais sobre proteção contra possíveis solicitações de outros países que passem pelo MLA.
Checklist: o que perguntar a um provedor de DNS
Esta é provavelmente a parte mais prática do artigo. Independentemente de você me escolher, NextDNS ou nenhum, aqui estão as perguntas cujas respostas você deve obter antes de confiar seus logs de consulta a um provedor:
- Em qual país a entidade legal está sediada?
- Quem são os proprietários beneficiários e há entidades americanas entre os investidores?
- Onde fisicamente estão os servidores que processam as consultas?
- Onde fisicamente são armazenados os logs e backups?
- A nuvem americana (AWS/GCP/Azure) é usada em qualquer camada?
- Um CDN americano é usado antes dos recursos públicos do provedor?
- Existe um warrant canary, com que frequência é atualizado, qual o formato da assinatura?
- Um relatório de transparência foi publicado (quantas solicitações de LE, em qual período)?
- O software de ponta (edge-soft) do provedor é open-source?
- Qual a retenção para logs de consulta, como é aplicada, é possível configurar um valor menor?
- A política de resposta a solicitações legais (law enforcement response policy) foi publicada?
- Qual o processo para uma solicitação de direito de apagamento, quão rápido eles excluem os dados?
Se as respostas para 1-6 forem 'EUA' ou 'não diremos', isso não significa 'provedor ruim', significa 'você tem risco Schrems II, avalie você mesmo se isso é importante para você'. Para a maioria dos usuários domésticos que bloqueiam anúncios, talvez não seja importante. Para um jornalista, ativista, pesquisador de segurança ou simplesmente um paranoico, é importante.
Em resumo
Se simplificarmos para uma única fórmula: privacidade em DNS é o produto de três fatores.
Privacidade = Jurisdição × Arquitetura × Transparência.
Jurisdição é onde você está legalmente. Arquitetura é onde os dados estão fisicamente e através de quais sistemas eles passam. Transparência é o que você documenta publicamente e se suas afirmações podem ser verificadas.
Se pelo menos um dos três for próximo de zero, a privacidade é falsa, não importa quão bons sejam os outros dois. Uma corporação americana com servidores na UE e um belo landing page sobre privacidade é uma arquitetura forte e transparência com uma jurisdição furada. Uma corporação da UE com backend na nuvem americana é o oposto. Uma corporação da UE em servidores dedicados sem políticas públicas é a terceira versão do mesmo problema.
Eu me esforço para que todos os três sejam maiores que zero. Se estou conseguindo, julgue você mesmo pela documentação pública, não pela minha palavra.
Links
- vantagedns.com — produto
- vantagedns.com/try — experimentar
- vantagedns.com/canary — warrant canary
- vantagedns.com/security — políticas de transparência, política de resposta a LE
- vantagedns.com/press-kit — press kit
Se houver advogados nos comentários que vejam imprecisões, serei grato por correções. Sou um engenheiro que lê leis, não o contrário, e erros de interpretação aqui são normais. O importante é corrigi-los.
