Resumo

  • A RFC 3693 deu nomes distintos ao Target, Rule Maker, Rule Holder, Generator, Server, Recipient e Viewer, em vez de reduzir a divulgação a uma troca entre duas partes.
  • O objeto de localização podia transportar regras de privacidade, mas elas não eram obrigatórias em cada objeto, e a gestão completa dessas regras ficou fora do escopo.

Uma coordenada responde “onde?”. Ela não revela quem a obteve, quem está sendo localizado, quem pode vê-la, com que precisão, nem se quem a recebe pode guardá-la ou encaminhá-la. Foi essa gramática ausente que o GEOPRIV tentou tornar visível.

Publicada em fevereiro de 2004 como documento Informational, a RFC 3693 divide o problema em papéis diferentes. O Target é a pessoa ou entidade cuja localização é comunicada. O Rule Maker cria as regras de acesso — normalmente o Target, mas não sempre: o documento também considera um pai ou empregador definindo regras para outra pessoa. O Rule Holder guarda e fornece essas regras. O Location Generator obtém a localização e cria um objeto; o Location Server o recebe, aplica as regras e distribui resultados permitidos; o Location Recipient recebe os dados; o Viewer os consulta sem repassá-los. Um Data Transporter pode encaminhá-los sem processá-los. Um mesmo dispositivo pode reunir vários papéis.

Essa separação importa porque a privacidade depende de relações, não só de criptografia. Uma regra poderia permitir que o titular de determinada credencial conhecesse a cidade, sem revelar uma posição mais precisa. A RFC trata coleta, uso, divulgação e retenção como assuntos distintos e pede suporte a pseudônimos não vinculáveis e credenciais que reforcem a privacidade. Saber quem recebeu a localização também pode revelar hábitos ou relações do Target.

O objeto de localização deveria poder carregar mais que coordenadas, mas não se tornava por isso um mecanismo automático de aplicação de regras. A RFC 3693 exige que ele permita a aplicação por terceiros e diz que deveria poder levar um conjunto central limitado de regras. Porém, define o objeto como informação de localização “e possivelmente regras de privacidade”: cada instância não precisa incorporá-las. A decisão do Server de divulgar a informação deve se basear nas regras do Rule Maker.

Mesmo um Generator sem acesso às regras completas precisa seguir suas instruções; um Viewer deveria receber apenas o subconjunto necessário para tratar o objeto em conformidade.

Os limites são explícitos. A RFC não define como as regras são gerenciadas nem como o Server as obtém. Não fecha a expressividade de uma linguagem de regras. Um limite de retenção pode ter consequências técnicas ambíguas e depender em parte da legislação ou dos costumes locais. A autenticação e proteção das regras são exigidas, mas a distribuição de chaves e os mecanismos detalhados ficam fora do escopo. Proteger o objeto tampouco impede a análise de tráfego em outros cabeçalhos e objetos.

Os documentos posteriores mostram a continuação da especificação, não uma prova de adoção universal. A RFC 4119 definiu um formato de objeto baseado em PIDF; a RFC 4079 descreveu uma arquitetura de presença. Em 2011, a RFC 6280, publicada como BCP 160, atualizou as RFCs 3693 e 3694 e ampliou os requisitos para uma arquitetura. HELD, o transporte por SIP e a resolução de URI de localização definiram depois formas específicas de obter, levar ou consultar dados de localização.

A contribuição histórica foi mais modesta que “a Internet resolveu a privacidade de localização”. A RFC 3693 tornou visível a superfície de controle: quem é localizado, quem escreve as regras, onde elas ficam, quem as aplica, que precisão é divulgada e o que o destinatário pode fazer depois. Um documento de requisitos pode nomear essas fronteiras; não prova que um serviço as implementou, que um destinatário as respeitou ou que alguém permaneceu anônimo.

Fontes