Zusammenfassung

  • RFC 3693 unterschied Target, Rule Maker, Rule Holder, Generator, Server, Recipient und Viewer, statt die Weitergabe als Austausch zwischen nur zwei Parteien zu behandeln.
  • Ein Location Object konnte Datenschutzregeln mitführen. Vorgeschrieben war das nicht für jedes Objekt; auch die vollständige Regelverwaltung blieb außerhalb des Dokuments.

Koordinaten beantworten die Frage „Wo?“. Sie sagen nicht, wer sie erhoben hat, wessen Standort sie beschreiben, wer sie sehen darf, in welcher Genauigkeit und ob ein Empfänger sie speichern oder weiterleiten darf. Diese fehlenden Verben wollte GEOPRIV sichtbar machen.

RFC 3693 erschien im Februar 2004 als Informational-Dokument. Es zerlegt einen Standortdienst in verschiedene Rollen. Das Target ist die Person oder Entität, deren Standort übermittelt wird. Der Rule Maker legt Zugriffsregeln fest – meist das Target selbst, aber nicht immer; das Dokument nennt auch Eltern und Arbeitgeber. Der Rule Holder speichert und liefert Regeln. Der Location Generator ermittelt den Standort und erstellt ein Objekt. Der Location Server nimmt es entgegen, wendet Regeln an und verteilt erlaubte Ergebnisse. Der Location Recipient erhält die Daten; ein Viewer nutzt sie, ohne sie weiterzuleiten. Ein Data Transporter kann sie unverändert weiterbefördern. Ein Gerät kann mehrere Rollen gleichzeitig ausfüllen.

Die Trennung ist wichtig, weil Datenschutz von Beziehungen abhängt, nicht allein von Verschlüsselung. Eine Regel könnte einem Inhaber bestimmter Zugangsdaten erlauben, die Stadt zu erfahren, nicht aber die genauere Position. RFC 3693 behandelt Erhebung, Nutzung, Offenlegung und Aufbewahrung als getrennte Regelungsgegenstände. Außerdem fordert sie Unterstützung für nicht verknüpfbare Pseudonyme und datenschutzfördernde Zugangsdaten. Schon die Kenntnis darüber, wer Standortdaten erhält, kann Gewohnheiten oder Beziehungen des Targets offenlegen.

Das Location Object sollte also mehr als Koordinaten transportieren können, war damit aber kein selbstvollstreckendes Regelwerk. RFC 3693 verlangt, dass es die Durchsetzung durch Dritte ermöglicht, und sagt, es sollte einen begrenzten Kern von Regeln aufnehmen können. Zugleich definiert sie das Objekt als Standortinformation „und möglicherweise Datenschutzregeln“: Nicht jede Instanz muss sie enthalten. Die Offenlegungsentscheidung des Servers muss auf Regeln des Rule Makers beruhen.

Auch ein Generator ohne Zugang zu den vollständigen Regeln muss dessen Vorgaben befolgen; ein Viewer soll nur die für regelkonforme Verarbeitung erforderliche Teilmenge erhalten.

Die Grenzen stehen ausdrücklich im Text. Verwaltung der Regeln und der Zugriff des Servers darauf sind nicht spezifiziert. Auch die Ausdrucksmöglichkeiten einer Regelsprache bleiben offen. Eine Aufbewahrungsfrist kann technisch unklare Folgen haben und teilweise vom örtlichen Recht oder den Gepflogenheiten abhängen. Regeln müssen authentifiziert und geschützt werden; Schlüsselverteilung und genaue Mechanismen bleiben aber außerhalb des Umfangs. Die Sicherung des Location Objects verhindert zudem keine Verkehrsanalyse anderer Header und Objekte.

Spätere Dokumente zeigen weitere Spezifikation, nicht den Beleg universeller Nutzung. RFC 4119 definiert ein PIDF-basiertes Format für Location Objects; RFC 4079 beschreibt eine Presence-Architektur. RFC 6280 erschien 2011 als BCP 160, aktualisierte RFC 3693 und 3694 und erweiterte deren Anforderungen zu einer umfassenderen Architektur. HELD, SIP-Standortübermittlung und das Auflösen von Standort-URIs legten danach konkrete Wege fest, Standorte abzurufen oder zu transportieren.

Der historische Beitrag war kleiner als „das Internet löste Standortdatenschutz“. RFC 3693 machte die Kontrollfläche sichtbar: Wer wird lokalisiert, wer schreibt Regeln, wo liegen sie, wer wendet sie an, welche Genauigkeit wird offengelegt und was darf der Empfänger anschließend tun? Ein Anforderungsdokument kann Grenzen benennen. Es beweist nicht, dass ein Dienst sie umgesetzt hat, ein Empfänger sie befolgte oder eine Person anonym blieb.

Quellen