Resumen

  • RFC 3693 nombró al Target, Rule Maker, Rule Holder, Generator, Server, Recipient y Viewer, en vez de reducir la divulgación a un intercambio entre dos partes.
  • El objeto de ubicación podía transportar reglas de privacidad, pero no era obligatorio incluirlas en cada objeto ni se definió el sistema completo para gestionarlas.

Una coordenada responde «¿dónde?». No indica quién la obtuvo, a quién sitúa, quién puede verla, con qué precisión ni si el destinatario puede conservarla o reenviarla. Esa gramática ausente era lo que GEOPRIV quería volver visible.

Publicado en febrero de 2004 como documento Informational, RFC 3693 organiza el problema mediante funciones distintas. El Target es la persona o entidad cuya ubicación se comunica. El Rule Maker crea las reglas de acceso —normalmente el Target, aunque no siempre: el texto también contempla a un padre o empleador—. El Rule Holder guarda y proporciona las reglas. El Location Generator obtiene la posición y crea un objeto; el Location Server lo recibe, aplica las reglas y distribuye resultados permitidos; el Location Recipient recibe el dato, y el Viewer lo consume sin reenviarlo. Un Data Transporter puede transportarlo sin procesarlo. Un dispositivo puede cumplir varias funciones.

La distinción importa porque la privacidad depende de relaciones, no solo del cifrado. Una regla podría permitir que quien posee cierta credencial conozca una ubicación aproximada —por ejemplo, la ciudad—, pero no una posición precisa. El RFC trata por separado la recopilación, el uso, la divulgación y la retención; además pide admitir seudónimos no vinculados y credenciales que mejoren la privacidad. Saber quién recibe la ubicación también puede revelar hábitos o relaciones del Target.

El objeto de ubicación debía poder contener más que una coordenada, pero no se convertía por ello en un mecanismo de cumplimiento automático. RFC 3693 exigió que permitiera la aplicación de reglas por terceros y dijo que debería poder llevar un conjunto básico limitado. Sin embargo, lo describió como información de ubicación «y posiblemente reglas de privacidad»: cada instancia no tenía que incluirlas. La decisión del servidor de revelar datos debía basarse en reglas definidas por el Rule Maker.

Incluso un Generator sin acceso a las reglas completas debía respetar sus instrucciones; un Viewer debía recibir solo el subconjunto necesario para tratar el objeto correctamente.

Los límites son explícitos. RFC 3693 dejó fuera la gestión de las reglas y la forma en que un Server accede a ellas. No definió toda su expresividad. Una regla de retención podía tener consecuencias técnicas ambiguas y depender parcialmente de la legislación o las costumbres locales. Exigió autenticar y proteger las reglas, pero dejó fuera la distribución de claves y los mecanismos detallados. También reconoció que proteger el objeto no impide analizar el tráfico de otros encabezados y objetos.

Los documentos posteriores muestran pasos de especificación, no prueba de uso universal. RFC 4119 definió un formato de objeto de ubicación basado en PIDF; RFC 4079 describió una arquitectura de presencia. En 2011, RFC 6280, publicada como BCP 160, actualizó RFC 3693 y RFC 3694 y amplió sus requisitos en una arquitectura. HELD, la transmisión mediante SIP y la resolución de URI de ubicación concretaron después maneras de obtener o transportar datos de ubicación.

El logro histórico fue más limitado que «Internet resolvió la privacidad de ubicación». RFC 3693 hizo legible el plano de control: quién está ubicado, quién redacta las reglas, dónde se guardan, quién las aplica, qué precisión se divulga y qué puede hacer después el destinatario. Un documento de requisitos puede nombrar esos límites. No demuestra que un servicio los implementara, que un destinatario obedeciera las reglas ni que alguien permaneciera anónimo.

Fuentes