Resumo

  • RFC 3323 preservou tanto o pedido de anonimização quanto a decisão explícita de não aplicá-la; privacidade era intenção situada, não transformação automática.
  • O serviço que escondia identidade do destinatário ainda podia conhecer o originador, e critical exigia rejeição quando a proteção pedida falhava.

Quando mais privacidade seria a ação errada

Um perfil de rede poderia aplicar anonimização por padrão. Privacy: none ordenava que nenhuma função fosse usada naquela mensagem e proibia intermediários de retirar ou alterar a escolha. A regra revela uma ideia importante: o serviço não era soberano sobre a identidade. Sua função era executar a preferência específica do usuário.

Na direção oposta, header, session e user solicitavam tratamento de cabeçalhos, sessão ou dados que o terminal não conseguia limpar. critical dizia que a comunicação sem essas funções era inaceitável. Se limitações legais, implementação ausente ou configuração errada impedissem a proteção, a requisição deveria falhar fechada.

Anônimo para um, conhecido por outro

O agente podia usar Anonymous e o domínio SIP anônimo reservado no From, remover cabeçalhos opcionais e evitar um Call-ID revelador. Contact e Via continuavam sendo endereços funcionais; SDP podia revelar a origem do tráfego. Falsificá-los quebraria o diálogo.

O serviço de privacidade entrava nessa lacuna. Ele conhecia o valor original, o removia antes do destino e assumia o roteamento posterior. Para privacidade de sessão, podia retransmitir a mídia. Assim o chamador era desconhecido pelo receptor, mas não necessariamente pelo serviço, autenticação ou domínio local.

RFC 3323 descreveu privacidade diante do destino, de intermediários ou de ambos. Uma flag global apaga essa relação. TLS até o serviço reduzia vazamento anterior e remoção do pedido, mas não tornava o serviço cego. Relé de mídia escondia IP do par e podia observar mídia não cifrada.

Destinatários e proxies podiam rejeitar originadores não identificáveis. Pedir anonimato não criava direito de aceitação. RFC 3325 e documentos posteriores de identidade e histórico reforçaram que uma identidade pode ser autenticada num domínio e retida de outro observador.

A contribuição histórica foi transformar anonimato em cadeia verificável: preferência, rota, transformação, observador e falha. none e critical guardavam os dois lados da intenção. Sem eles, automação poderia esconder quando não devia ou revelar quando não podia.

A resposta precisava de planejamento anterior

Respostas SIP retornam pelo caminho percorrido pela solicitação. Depois de receber uma mensagem, o agente respondente não podia inserir um novo serviço de privacidade no trajeto já formado. Se quisesse esconder também seu Contact ou local de registro, precisava preparar a entrada: distribuir uma URI anônima de retorno, registrar um contato através do serviço ou manter conexões TLS adequadas.

Isso mostra que privacidade não era acabamento aplicado à mensagem final. Era arquitetura de rota. Um relatório que vê apenas o cabeçalho já reescrito não consegue provar por quais intermediários o original passou nem se a resposta recebeu proteção equivalente.

Duas superfícies que não se substituíam

Privacidade de cabeçalho e de sessão eram pedidos distintos. Remover From, Via ou Organization não escondia necessariamente o endereço no SDP e nos pacotes de mídia. Inserir um relay de mídia não apagava User-Agent, Call-ID ou outros sinais no SIP. Uma transformação bem-sucedida não autorizava declarar a outra concluída.

Por isso a verificação precisa separar sinalização, mídia e autenticação. Deve observar o que o destinatário recebeu, o que o serviço conheceu e o que o domínio local registrou. “Anônimo para o receptor, autenticado pelo provedor” é uma afirmação coerente quando cada relação tem evidência própria.

O custo de concentrar confiança

Um serviço central podia proteger o usuário diante de muitos destinos, mas também reunia endereços originais, rotas e possivelmente tráfego. Falha, captura, registro excessivo ou pressão jurídica nesse ponto ampliavam o impacto. A arquitetura não eliminava confiança; deslocava-a.

O serviço precisava ser identificável, substituível e testado em modo de falha. Se uma configuração deixasse de aplicar header ou session, critical precisava impedir a entrega. Sem esse teste negativo, a organização conheceria apenas o caminho feliz e não saberia se o sistema preservava privacidade justamente quando mais importava.

Sources