Descoberta de agentes revela intenção antes da escolha

Summary

A descoberta de agentes pode expor a intenção de uma organização antes da seleção: filtros de capacidade, jurisdição, confiança, horário e refinamentos sucessivos descrevem o trabalho planejado mesmo quando o conteúdo da consulta está cifrado.
O draft-iannone-dawn-privacy-considerations-00 identifica vigilância, armazenamento, correlação e identificação, mas continua sendo um Internet-Draft individual e incompleto, com a comparação com DNS, o conflito entre privacidade e auditabilidade, o questionário do RFC 6973 e várias ameaças marcados como TBD.
Daniel Kade propõe um orçamento de divulgação da seleção que reúna granularidade, piso para o conjunto de candidatos, janela de vinculação, separação de papéis, caminho de inicialização, público dos resultados e retenção. É uma proposta editorial, não uma exigência do DAWN ou do IETF.

A primeira revelação acontece antes do primeiro contato

É comum representar descoberta como uma seta inofensiva entre intenção e execução. Um cliente sabe do que precisa, pergunta a um diretório quem pode fornecer, compara respostas e escolhe. Confiança, autorização e execução vêm depois, o que faz a descoberta parecer apenas infraestrutura.

A terminologia proposta para o DAWN dá muito mais conteúdo a essa seta. Uma entidade descobrível pode ser um agente, uma carga de trabalho ou um recurso nomeado. Suas propriedades podem descrever função, capacidades, protocolos, proprietário, operador, localização, jurisdição e indicadores de confiança. A promessa da interoperabilidade é permitir que software reduza milhares de opções sem relação prévia. Essa mesma estrutura transforma a consulta em uma versão condensada da política de decisão do solicitante.

“Tradução” é uma necessidade ampla. Acrescente um par de idiomas, uma restrição sobre dados médicos, um esquema de atestação raro, jurisdição europeia, teto de latência e disponibilidade imediata, e a busca talvez revele um fluxo clínico específico. Retire a latência numa segunda tentativa e altere a jurisdição numa terceira: a sequência mostra qual requisito é negociável. Não é preciso observar a escolha final. O percurso até ela já fala.

O rascunho de requisitos do DAWN deixa mecanismos e políticas de seleção fora de escopo. É uma fronteira razoável para um documento que não escolhe protocolo. Não é, porém, uma fronteira de observabilidade. Um serviço que enxerga os atributos testados, a ordem em que são relaxados, os candidatos devolvidos e o horário das consultas consegue inferir a política que a especificação decidiu não definir.

Cifrar a frase não apaga a forma da procura

Publicado em 22 de maio de 2026, o draft-iannone-dawn-privacy-considerations-00 dá nome direto ao problema. A infraestrutura pode observar que organizações consultam determinadas capacidades, reconhecer interesses, carga de trabalho e comportamento operacional. Históricos armazenados expõem rotinas. Consultas repetidas permitem correlação. Nome, propriedade, operador e metadados de capacidade podem identificar quem publica ou quem procura.

Isso não torna o texto uma política concluída do IETF. Trata-se de um rascunho individual em andamento, sem fluxo RFC, Area Director responsável ou agenda de telechat do IESG. Intrusão, atribuição incorreta, uso secundário, divulgação e exclusão ainda não estão desenvolvidos. A comparação com DNS, a seção “Privacy vs Auditability”, o questionário do RFC 6973, as medidas específicas do DAWN e as considerações de segurança permanecem como trabalho futuro. Seu valor atual está em expor decisões abertas, não em encerrá-las.

Criptografia pode esconder o significado de uma mensagem de certos observadores. Ela não elimina destino, tamanho, horário, repetição, falha nem cardinalidade da resposta. O RFC 7258 lembra que características externas e correlação também constituem matéria de vigilância, independentemente da motivação declarada pelo observador. Perguntar apenas se há TLS reduz privacidade a transporte; a pergunta de governança é quais participantes podem juntar quais fragmentos e por quanto tempo.

O RFC 9458, sobre Oblivious HTTP, oferece uma comparação útil. O relay pode ver o cliente sem ler a requisição; o gateway pode ler a requisição sem ver diretamente o cliente. Ainda assim, tamanhos, sincronização, identificadores de chave, reutilização de conexão e tratamento diferenciado criam pistas. Um conjunto de anonimato pequeno enfraquece a separação, e a proteção depende de não conluio. Um diagrama com duas caixas não prova que logs, nuvem e analytics estejam separados na operação.

O conjunto de candidatos pode responder mais do que a consulta

Proteger o texto da busca é insuficiente quando o resultado contém uma única entidade. O candidato único passa a explicar a intenção. Um conjunto amplo e variado é, portanto, uma propriedade de privacidade, não só de disponibilidade. Em sentido inverso, um sistema que aceita combinações muito raras e informa imediatamente quantos resultados existem pode virar um oráculo de presença sobre seu banco de propriedades.

O Oblivious DoH do RFC 9230 separa, sob determinadas premissas, quem conhece o cliente de quem conhece a consulta DNS em claro. O RFC 9156 ajuda a pensar em minimização e granularidade. A descoberta de agentes é mais difícil porque a combinação de atributos, e não apenas um nome, produz valor. Consultas progressivas, de categorias amplas para detalhes necessários, evitam depositar todo o plano num único pedido. Mas etapas vinculadas pelo mesmo identificador, conexão ou relógio reconstroem o plano. Granularidade e vínculo precisam ser governados juntos.

O RFC 9540 também mostra que a inicialização pode vazar antes do canal protegido. Busca de chaves, URL de configuração, redirecionamentos e um caminho de rede exclusivo podem indicar qual serviço de descoberta o cliente pretende usar. Auditar apenas o interior do túnel ignora a caminhada até sua entrada.

Há ainda públicos diferentes para o resultado. Dados públicos, dados restritos a solicitantes autorizados e respostas personalizadas não têm a mesma superfície. Restringir pode proteger informações do fornecedor, mas liga com mais força a identidade autenticada aos filtros. Personalizar melhora a utilidade, mas diferenças entre respostas revelam classes de clientes ou regras internas. Mudar quem é protegido desloca o vazamento; não o elimina automaticamente.

Privacidade e auditoria não precisam formar uma falsa escolha

O título inacabado “Privacy vs Auditability” do rascunho aponta para a decisão institucional mais delicada. Operadores querem investigar abuso, raspagem, exclusão indevida e degradação. Contratos ou supervisores podem exigir explicações. Se a resposta for guardar cada consulta, a lista completa de candidatos e um identificador duradouro, o sistema de auditoria se torna um arquivo das intenções de seus usuários.

Eliminar todo registro tampouco resolve o problema. Sem evidência, fica difícil demonstrar tratamento diferenciado, falha sistemática ou uso de uma exceção. O desenho adequado limita prova a cada finalidade: quem pode acessá-la, com que resolução e até quando. Contagens locais e breves podem registrar faixas de cardinalidade, taxa de falha, distribuição de latência, frequência de filtros raros, versão de política e vencimento de exceções sem conservar a frase buscada ou a identidade de cada candidato.

O RFC 9576, na arquitetura Privacy Pass, separa contextos de emissão, atestação e resgate para evitar vínculos desnecessários. O RFC 9614 distribui entre participantes o conhecimento de quem se conectou e a que destino. Nenhum deles é uma garantia mágica. Conluio, conjuntos pequenos, horários coincidentes e identificadores persistentes recompõem os fragmentos. Para auditoria, também é preciso testar as condições de recomposição, não apenas declarar separação.

Um orçamento de divulgação da seleção

A proposta de Daniel Kade é um orçamento de divulgação da seleção, não um registro central de todas as buscas. O orçamento define antecipadamente quanto da política de escolha pode ficar visível numa consulta ou sequência, mede o resultado operacional e trata exceções com prazo e revisão.

O primeiro item é a granularidade máxima de atributos. Uma combinação de propriedades raras funciona como identificador mesmo que cada campo isolado pareça banal. A etapa inicial pode usar classes amplas de capacidade ou faixas jurisdicionais e permitir detalhe apenas quando necessário. O segundo é um piso para o conjunto de candidatos e um comportamento explícito abaixo dele. Em vez de devolver uma única entidade, o sistema pode engrossar o critério, atrasar a resposta ou informar somente que não há conjunto suficientemente amplo.

O terceiro item é a janela de vinculação: por quantos minutos, horas ou dias consultas sucessivas podem ser atribuídas ao mesmo solicitante? Lotes, arredondamento temporal, rotação de identificadores e padding fazem sentido quando acompanhados de limite institucional. O quarto é uma matriz de visibilidade. Para solicitante, relay, índice, fornecedor, distribuidor de chaves e auditor, ela informa quem vê identidade, atributos, candidatos, horário e resultado.

O quinto item registra pressupostos de não conluio e o caminho de bootstrap. Empresas juridicamente distintas podem usar a mesma conta de nuvem, coletor de logs ou provedor de analytics. Nesse caso, a separação nominal vale pouco. O sexto define se resultados são públicos, restritos ou específicos do solicitante, além de retenção, eliminação, correção, autoridade de exceção, vencimento e reavaliação.

Esse orçamento não deve receber consultas brutas, credenciais, conteúdo da tarefa, dados pessoais, pesos proprietários nem a identidade de todos os candidatos. Agregados grosseiros, contadores locais de curta duração, consultas sintéticas e inspeções independentes de configuração atendem boa parte da necessidade. Não possuir o dado desnecessário é um controle mais robusto que prometer não usá-lo.

O que os documentos ainda não permitem afirmar

As fontes examinadas não demonstram implementação do DAWN em produção, adoção, desempenho, incidente real de privacidade ou resultado jurídico. PIR aparece como possível componente, não como escolha do grupo nem como técnica comprovada nessa escala. Tampouco se pode deduzir conformidade com uma lei específica a partir desses textos técnicos.

O orçamento aqui proposto não é consenso do IETF, requisito de implementação ou obrigação legal. É uma forma de transformar uma lacuna visível em perguntas operacionais verificáveis. A observação firme é mais simples: a utilidade da descoberta vem da capacidade de comparar atributos, e essa combinação, junto com a ordem da comparação, expressa intenção.

Enquanto o desenho ainda está aberto, é possível tratar cardinalidade, tempo, separação, bootstrap, retenção e exceções como partes da privacidade, em vez de empurrar tudo para uma camada de criptografia posterior. “Ainda não escolhemos” não significa “ainda não revelamos”. Na descoberta, procurar já é começar a decidir em público.

A descoberta de agentes revela a intenção antes de qualquer escolha

Por que isso importa

Summary

A primeira revelação acontece antes do primeiro contato

Cifrar a frase não apaga a forma da procura

O conjunto de candidatos pode responder mais do que a consulta

Privacidade e auditoria não precisam formar uma falsa escolha

Um orçamento de divulgação da seleção

O que os documentos ainda não permitem afirmar

Sources

Contexto aprofundado do perfil

Strategic Circle

Leadership Alliance

Briefing do Strategic Circle

Briefing da Leadership Alliance