joerghuelsermann.de P3P elektronische Datenschutzerklärung

P3P elektronische Datenschutzerklärung

Mit P3P werden Datenschutzinformationen durch eine oder mehrere XML Dateien übermittelt, welche die Richtlinien des Datenschutzes beinhalten. Das World Wide Web Consortium hat diesen Standard einer elektronischen Datenschutzerklärung entworfen. Ausgehend von diesem Stand der Spezifikation ist diese Seite entstanden. Ich versuche an dieser Stelle den komplexen Aufbau einer solchen Datei möglichst genau zu erklären. Die komplette Spezifikation des W3C werde ich aber nicht abbilden und sehe es als Einführung in diese Thematik an.

Aufbau einer P3P

Der Aufbau einer P3P besteht aus der Referenz einer Richtlinie und der Richtlinie zum Datenschutz. Diese können in einem Dokument oder auch getrennt in mehreren Dateien angelegt sein. Im letzten Abschnitt geht es darum wie man auf die P3P Datei einen Verweis aufbaut.

Referenz der Richtlinie

Die Referenz besteht aus folgenden einzelnen Punkten die teilweise optional sein können.

1. Kennzeichnung als XML Dokument

Am Anfang des Dokumentes steht eine Angabe, <?xml version="1.0" encoding="utf-8"?> die es als XML Dokument kennzeichnet und den verwendeten Zeichensatz angibt.

2. Verweis auf das P3P Datenshema

Darauf folgt in der Referenz die Angabe des P3P Datenshemas. Dadurch wird erreicht das das Dokument als P3P erkannt wird.<META xmlns="http://www.w3.org/2002/01/P3Pv1">

3. Einleitung der Referenzen

Nun folgt die Angabe der Referenzen. Es sind mehrere Referenzen möglich anzugeben. Dabei muss dann innerhalb der Punkte 3 und 9 für jede Referenz die Punkte 5 bis 7 durchgeführt werden.<POLICY-REFERENCES>

4. Gültigkeitsdauer

Optional ist dieser Punkt eine Gültigkeitsdauer für die Referenzen anzugeben. Der Standardwert für diesen Punkt wird mit 86400 Sekunden was einem Tag entspricht angegeben.<EXPIRY max-age="86400" />

Alternativ ist auch die Angabe eines fixen Datums möglich.<EXPIRY date="Thu, 31 Dec 2020 12:00:00 +0200" />

5. Start einer einzelnen Referenz und Quellangabe der Richtlinie

Mit dem Element POLICY-REF leitet man die Referenz ein. So sieht ein interner Verweis auf die Richtlinie in einer P3P Datei aus.<POLICY-REF about="#Datenschutz">

Möchte man hingegen die Richtlinien separat aufbauen kann man extern auf sie verweisen.<POLICY-REF about="http://example.com/w3c/policy.xml#Datenschutz">

6. Geltungsbereich der Referenz

Für welche Bereiche die Referenz anwendbar ist, wird mit diesen Angaben angegeben.

Verzeichnisse

Die Richtlinie gilt für die gesamte Webpräsenz.<INCLUDE>/*</INCLUDE>

Mit Ausnahme des angegebenen Verzeichnis. Dabei sind auch mehrere Angaben von Verzeichnissen möglich. Sollte so eine Ausnahme nötig sein, werden weitere Referenzen nötig.<EXCLUDE>/verzeichnis/*</EXCLUDE>

Cookies

Um die Gültigkeit bei Verwendung von Cookies zu erklären gibt es die Elemente COOKIE-INCLUDE und COOKIE-EXCLUDE. Eine weitere Definition der Cookies ist über die Attribute name / value / domain / path möglich. Dabei würde <COOKIE-INCLUDE /> gleichbedeutend mit <COOKIE-INCLUDE name="*" value="*" domain="*" path="*" /> sein und aussagen das diese Angabe für alle Cookies gilt. Als Domain wird nur die aktuelle Domain in diesem Fall als zulässig betrachtet.

Methoden

Um eine Beschränkung nur für bestimmte HTTP Abfragemethoden zu erreichen, kann man das METHOD Element hierfür einsetzen.

<METHOD>GET</METHOD>
<METHOD>HEAD</METHOD>
<METHOD>PUT</METHOD>
<METHOD>DELETE</METHOD>

7. Ende einer Referenz

Das Ende einer Referenz nimmt man so vor.</POLICY-REF>

8. Weitere Möglichkeiten

Das HINT Element dient dazu auf P3P Dateien anderer Webseiten zu verweisen auf die man auf den eigenen Webseiten verlinkt.

Das EXTENSION Element kann zur flexiblem Erweiterung einer P3P Datei benutzt werden. Dieses Element ist auch an mehreren Stellen innerhalb der Richtlinie möglich einzusetzen.

9. Ende der Referenzen

Mit dem folgenden Kode wird das Ende der Referenzen erreicht.</POLICY-REFERENCES>

10. Einfügen der Richtlinien

An dieser Stelle werden die Richtlinien eingefügt falls man diese nicht in separaten Dateien unterbringen möchte.

11. Ende der P3P Datei

Falls man die Richtlinien separat in einer externen Datei angibt folgt an dieser Stelle das Ende der P3P Datei.</META> Ansonsten fügt man zuvor noch die Richtlinien an dieser Stelle ein.

Richtlinie zum Datenschutz

Die Richtlinien können auch als eigenständige Dateien aufgebaut werden. Es ist aber auch möglich sie auch in der P3P direkt anzugeben. An mehreren Stellen kann man diese Richtlinien durch das EXTENSION Element frei erweitern. Für Interressierte in diesem Punkt verweise ich an dieser Stelle auf die Spezifikation.

A. Start der Richtlinien

Der Bereich der Richtlinien werden mit diesem <POLICIES> gekennzeichnet. Die Angabe des Datenshemas geschah unter Punkt 2 der Referenz bereits wenn Referenz und Richtlinie sich in einer Datei befinden. Dabei wird nur in einer eigenständigen Richtlinie die Angabe des Datenschemas <POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"> nötig. Bei dieser Vorgehensweise empfiehlt es sich vorher Punkt 1 der Referenz durchzuführen.

B. Erstellung eigener Datenshemas

Nach dem Start der Richtlinien ist optional eine Angabe von eigenen Datenshemas möglich. Dadurch kann man eigene Datenarten definieren und diese auch schon bereits kategorisieren. Es ist als eine Vorbereitung für die Punkte O bis S zu verstehen.

Grundsätzlich gibt es bei einer Übertragung von Daten maximal 4 Beteiligte die dann den entsprechenden Datenarten zugeordnet werden können.

C. Gültigkeitsdauer

An dieser Stelle ist wieder möglich, wie bei Punkt 4 der Referenz, eine Gültigkeitsdauer anzugeben.

D. Start einer Richtlinie

Beim Start einer Richtlinie wird auf die Datenschutzerklärung durch das Attribut discuri für einen Benutzer verwiesen. Dabei wird die Sprache der Datenschutzerklärung durch das Attribut xml:lang mit angegeben. Durch das name Attribut wird eine Sprungmarke von der Referenz zu der Richtlinie erreicht. Das POLICY Element muss das Attribut opturi mit einer Angabe der Webseite enthalten, falls beim Verwendungszweck der Daten der Nutzer diesen widersprechen kann. Dieses wird durch das Setzen von required="opt-in" oder required="opt-out" innerhalb des PURPOSE Elementes notwendig.

<POLICY name="Datenschutz" discuri="http://freihandelswelt.de/datenschutz.php" xml:lang="de">

E. Kennzeichnung eines Test

Um die Richtlinie als Test zu kennzeichnen sollte man an diesem Punkt <TEST /> einfügen. Für dieses Element lautet der Kompaktcode TST.

F. Ansprechpartner für die Datenschutzrichtlinie

Mit diesem Bereich legt man die Person oder Instanz fest die verantwortlich für die Datenschutzbestimmungen ist. Kontaktmöglichkeiten müssen hierbei genannt werden.

<ENTITY>
<DATA-GROUP>
<DATA ref="#business.name">Bezeichnung</DATA>
<DATA ref="#business.contact-info.telecom.telephone.intcode">Internationale Vorwahl</DATA>
<DATA ref="#business.contact-info.telecom.telephone.loccode">Ortsvorwahl</DATA>
<DATA ref="#business.contact-info.telecom.telephone.number">Telefonnummer</DATA>
<DATA ref="#business.contact-info.online.email">Email Adresse</DATA>
<DATA ref="#business.contact-info.online.uri">Kontaktformular</DATA>
<DATA ref="#business.contact-info.postal.organization">Post Addressant</DATA>
<DATA ref="#business.contact-info.postal.street">Strasse und Hausnummer</DATA>
<DATA ref="#business.contact-info.postal.city">Ort</DATA>
<DATA ref="#business.contact-info.postal.stateprov">Bundesland</DATA>
<DATA ref="#business.contact-info.postal.postalcode">Postleitzahl</DATA>
<DATA ref="#business.contact-info.postal.country">Staat</DATA>
</DATA-GROUP>
</ENTITY>

G. Zugang zu den erhobenen Daten

Innerhalb des ACCESS Elementes gibt man in der P3P Datei an welchen Zugang Benutzer der Webseite zu den Daten besitzen. Aus der folgenden Liste kann man eine Angabe auswählen die dann auch wieder einem Kompaktcode entspricht. Beispiel; <ACCESS><none /></ACCESS>

H. Unstimmigkeiten zwischen der Richtlinie und Ausführung

Hiermit teilt man in der P3P Datei mit wie Unstimmigkeiten zwischen den Datenschutzbestimmungen und ihrer Ausführung umgegangen wird. Mehrere DISPUTES Elemente sind innnerhalb dieses Bereiches zwischen <DISPUTES-GROUP> und dem Ende der Gruppierung </DISPUTES-GROUP> möglich anzugegeben. Zu jedem DISPUTES Element wird ein REMEDIES Element dann noch angelegt.

DISPUTES

Durch die DISPUTES Elemente werden die Stellen angegeben an die man sich bei den Unstimmigkeiten wenden kann. Alleine das Vorhandensein dieses Elementes entspricht wieder einem Kompaktcode. Für das DISPUTES Element existieren 4 mögliche Attribute. Beispiel: <DISPUTES resolution-type="service" service="http://joerghuelsermann.de/kontakt/" short-description="Kontakt">

Reicht die kurze Beschreibung nicht aus kann man eine längere Beschreibung mit <LONG-DESCRIPTION>Text der Beschreibung</LONG-DESCRIPTION> vornehmen. Auch ist das einfügen eines Logos analog dem Plazieren von Bildern in einer Webseite möglich.

REMEDIES

Es stehen drei Möglichkeiten zur Auswahl <correct /> bedeutet das der Service eine Korrigierung vornimmt. <law /> strebt dagegen eine juristische Einigung an. <money /> löst die Differenzen dann auf einem finanziellen Weg.

Beispielsweise wird die Angabe <REMEDIES><correct /></REMEDIES> dann vor Beendigung eines DISPUTES Elementes durch </DISPUTES> eingefügt.

I. Start des Statements Bereichs

Innerhalb dieses Bereiches werden wieder verschiedene Angaben gemacht. Eingeleitet wird er mit <STATEMENT>.

J. Erläuterung zu der Datenschutzpraktiken

An dieser Stelle kann man optional eine frei wählbare Erläuterung zu den Richtlinien des Datenschutzes angeben.<CONSEQUENCE>Text der Erläuterung</CONSEQUENCE>

K. Anonymisierung der Daten

Dieses ist wiederum ein optionaler Punkt<NON-IDENTIFIABLE />. Er kennzeichnet das sämtliche Daten keiner Person zugeordnet werden können und das alle Daten anonymisert erhoben werden. Diese Anonymisierung muss dann in der Datenschutzerklärung erläutert werden. Laut Spezifikation sind damit alle anderen Punkte innerhalb des Elementes STATEMENT als optional zu verstehen. Der Kompaktcode für dieses Element ist NID.

L. Verwendungszweck der Daten

Das PURPOSE Element muss innerhalb des STATEMENT Elementes angegeben werden falls das NON-IDENTIFIABLE Element nicht gesetzt wurde. Durch dieses Element wird angegeben zu welchem Zweck die Daten gesammelt werden. Mehrere Angaben sind möglich. Beispiel:<PURPOSE><admin required="always" /><develop required="opt-out" /></PURPOSE>. Diese Angaben entsprechen wieder einem Kompaktcode.

M. Empfänger der Daten

Das RECIPIENT Element muss innerhalb des STATEMENT Elementes angegeben werden falls das NON-IDENTIFIABLE Element nicht gesetzt wurde. Durch dieses Element wird angegeben wer Verfügung über die Daten erhält. Mehrere Angaben sind möglich. In diesem Beispiel <RECIPIENT><ours><recipient-description>Beschreibung der Empfänger</recipient-description></ours><public required="opt-out"><recipient-description>Beschreibung der Empfänger</recipient-description></public></RECIPIENT> gibt es 2 Gruppen von Empfängern der Daten, wo jede Person bei der zweiten Gruppe auf Verzicht der Übermittlung seiner Daten drängen kann. Die Empfängergruppen kann man aus den folgenden Möglichkeiten auswählen. Auch diese Liste entspricht wieder einem Kompaktcode.

N. Aufbewahrungsfrist der Daten

Pflicht ist es auch falls das NON-IDENTIFIABLE Element nicht gesetzt wurde, die Verwendung des RETENTION Elementes, welches über die Aufbewahrungsfristen der Daten informiert. Nur eine der folgenden Angaben steht zur Auswahl. Beispiel: <RETENTION><indefinitely /></RETENTION>. Dadurch erhalten wir einen weiteren Kompaktcode.

O. Start der Datengruppierung

Mit <DATA-GROUP> leitet man die Beschreibung aller Datenarten ein, die ausgewertet werden. Eigene Definitionen dieser Datenarten können über das base Attribut vorgenommen werden. Sonst werden die Definitionen standardardmässig von http://www.w3.org/TR/P3P/base übernommen. Dieser Bereich ist Pflicht wenn das NON-IDENTIFIABLE Element nicht verwendet wurde.

P. Start der Datenart

Eine Datenart deren Daten gespeichert wird muss angegeben werden. Dabei springt man zu den jeweiligen Punkten in der vorher angegebenen Definition. Beispielsweile muss das Geschlecht bei einer Anmeldung in einem Forum angegeben werden. <DATA ref="#user.gender" optional="yes">. Das Attribut optional sagt in diesen Fall aus, das man nur bei einer Anmeldung diese Angabe angeben muss. Sollte eine Datenart in jedem Fall erhoben werden, verneint man dieses Attribut. Einige dieser Datenarten sind durch die Standard Definitioen schon fest zu Kategorien zugeordnet worden. In diesen Fällen ist eine eigene Kategorisierung nicht möglich.

Q. Kategorisierung der Datenart

Diese Datenarten können nun einer Kategorie zugeordnet werden, welche die Verwendung dieser Daten den folgenden Kategorien zuordnet. Dadurch wird eine Transparenz erzeugt, wie diese Daten genutzt werden. <online /> dient beispielsweise zur Kontaktaufnahme über das Internet. Für jede dieser Kategorien existiert wieder ein Kompaktcode.

R. Ende der Datenart

Das Ende einer Datenart wird erreicht mit </DATA>. Dieser Punkt wird für jede anzugebene Datenart wiederholt.

S. Ende der Datengruppierung

Hier schliessen wir den Punkt N mit </DATA-GROUP> ab.

T. Ende des Statements Bereichs

Für den Abschluß von Punkt H fügen wir an dieser Stelle </STATEMENT> ein. Es ist möglich noch einen STATEMENT Bereich hiernach anzuschliessen.

U. Ende einer Richtlinie

</POLICY> schliesst eine Richtlinie ab. Eine weitere Richtlinie kann sich an dieser Stelle wiederholen.

V. Ende der Richtlinien

</POLICIES> kennzeichnet das Ende aller Richtlinien in diesem Dokument.

P3P-Kompaktcodes

Diese Kompaktcodes entsprechen der Anwesenheit verschiedener Elemente in den Richtlinien der P3P Datei. Einige dieser Elemente können mit einem Zusatz * gekennzeichnet werden. Kein Zusatz entspricht in diesen Fällen dem Zusatz a. Um diesen Zusatz im Element auch anzugeben wird dem Element mit dem required Attribut der entsprechende Wert zugewiesen.

Um die Kompaktcodes für die Richtlinien zu ermitteln habe ich ein Tool entwickelt.

Zuordnung zu den Elementen

Kompaktcodes beim TEST Element
Spezifikation zum Element TEST und die Übersicht der Kompaktcodes zu TEST.

Der Kompaktcode TST entspricht der Anwesenheit von <TEST />. Kennzeichnet Testversion.

Kompaktcodes beim ACCESS Element
Spezifikation zum Element ACCESS und die Übersicht der Kompaktcodes zu ACCESS.

Der Kompaktcode ALL entspricht der Anwesenheit von <all />.

Der Kompaktcode CAO entspricht der Anwesenheit von <contact-and-other />.

Der Kompaktcode IDC entspricht der Anwesenheit von <ident-contact />.

Der Kompaktcode NOI entspricht der Anwesenheit von <nonident />.

Der Kompaktcode NON entspricht der Anwesenheit von <none />.

Der Kompaktcode OTI entspricht der Anwesenheit von <other-ident />.

Kompaktcodes beim DISPUTES Element
Spezifikation zum Element DISPUTES und die Übersicht der Kompaktcodes zu DISPUTES.

Der Kompaktcode DSP entspricht der Anwesenheit von <DISPUTES>.

Kompaktcodes beim REMEDIES Element
Spezifikation zum Element REMEDIES und die Übersicht der Kompaktcodes zu REMEDIES.

Der Kompaktcode COR entspricht der Anwesenheit von <correct />.

Der Kompaktcode LAW entspricht der Anwesenheit von <law />.

Der Kompaktcode MON entspricht der Anwesenheit von <money />.

Kompaktcodes beim NON-IDENTIFIABLE Element
Spezifikation zum Element NON-IDENTIFIABLE und die Übersicht der Kompaktcodes zu NON-IDENTIFIABLE.

Der Kompaktcode NID entspricht der Anwesenheit von <NON-IDENTIFIABLE />.

Kompaktcodes beim PURPOSE Element
Spezifikation zum Element PURPOSE und die Übersicht der Kompaktcodes zu PURPOSE.

Der Kompaktcode ADM* entspricht der Anwesenheit von <admin />.

Der Kompaktcode CON* entspricht der Anwesenheit von <contact />.

Der Kompaktcode CUR entspricht der Anwesenheit von <current />.

Der Kompaktcode DEV* entspricht der Anwesenheit von <develop />.

Der Kompaktcode HIS* entspricht der Anwesenheit von <historical />.

Der Kompaktcode IVA* entspricht der Anwesenheit von <individual-analysis />.

Der Kompaktcode IVD* entspricht der Anwesenheit von <individual-decision />.

Der Kompaktcode OTP* entspricht der Anwesenheit von <other-purpose />.

Der Kompaktcode PSA* entspricht der Anwesenheit von <pseudo-analysis />.

Der Kompaktcode PSD* entspricht der Anwesenheit von <pseudo-decision />.

Der Kompaktcode TAI* entspricht der Anwesenheit von <tailoring />.

Der Kompaktcode TEL* entspricht der Anwesenheit von <telemarketing />.

Kompaktcodes beim RECIPIENT Element
Spezifikation zum Element RECIPIENT und die Übersicht der Kompaktcodes zu RECIPIENT.

Der Kompaktcode DEL* entspricht der Anwesenheit von <delivery />.

Der Kompaktcode OTR* entspricht der Anwesenheit von <other-recipient />.

Der Kompaktcode OUR entspricht der Anwesenheit von <ours />.

Der Kompaktcode PUB* entspricht der Anwesenheit von <public />.

Der Kompaktcode SAM* entspricht der Anwesenheit von <same />.

Der Kompaktcode UNR* entspricht der Anwesenheit von <unrelated />.

Kompaktcodes beim RETENTION Element
Spezifikation zum Element RETENTION und die Übersicht der Kompaktcodes zu RETENTION.

Der Kompaktcode BUS entspricht der Anwesenheit von <business-practices />.

Der Kompaktcode IND entspricht der Anwesenheit von <indefinitely />.

Der Kompaktcode LEG entspricht der Anwesenheit von <legal-requirement />.

Der Kompaktcode NOR entspricht der Anwesenheit von <no-retention />.

Der Kompaktcode STP entspricht der Anwesenheit von <stated-purpose />.

Kompaktcodes beim CATEGORIES Element
Spezifikation zum Element CATEGORIES und die Übersicht der Kompaktcodes zu CATEGORIES.

Der Kompaktcode CNT entspricht der Anwesenheit von <content />.

Der Kompaktcode COM entspricht der Anwesenheit von <computer />.

Der Kompaktcode DEM entspricht der Anwesenheit von <demographic />.

Der Kompaktcode FIN entspricht der Anwesenheit von <financial />.

Der Kompaktcode GOV entspricht der Anwesenheit von <government />.

Der Kompaktcode HEA entspricht der Anwesenheit von <health />.

Der Kompaktcode INT entspricht der Anwesenheit von <interactive />.

Der Kompaktcode LOC entspricht der Anwesenheit von <location />.

Der Kompaktcode NAV entspricht der Anwesenheit von <navigation />.

Der Kompaktcode ONL entspricht der Anwesenheit von <online />.

Der Kompaktcode OTC entspricht der Anwesenheit von <other-category />.

Der Kompaktcode PHY entspricht der Anwesenheit von <physical />.

Der Kompaktcode POL entspricht der Anwesenheit von <political />.

Der Kompaktcode PRE entspricht der Anwesenheit von <preference />.

Der Kompaktcode PUR entspricht der Anwesenheit von <purchase />.

Der Kompaktcode STA entspricht der Anwesenheit von <state />.

Der Kompaktcode UNI entspricht der Anwesenheit von <uniqueid />.

Verweis auf die P3P Datei

Man sollte auf die P3P Datei verweisen, selbst wenn man die Standardadresse /w3c/p3p.xml verwendet.

HTML

Mit HTML verweist man auf diese Weise.<link rel="P3Pv1" href="/w3c/p3p.xml" />

Header mit PHP

Dieser Header sollte normalerweise ausreichen. header('P3P: policyref="/w3c/p3p.xml"');

Man kann natürlich auch um die P3P Kompaktcodes den Header entsprechend erweitern header('P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID CUR ADM DEV OUR"');. Dabei sollte man sich aber sicher sein das die richtigen P3P Kompaktcodes angegeben werden. Je komplexer die Datenschutzerklärung aufgebaut ist umso eher würde ich davon abraten diese Kompaktcodes an dieser Stelle anzugeben.

Header mit htaccess

Alternativ kann man den Header wohl auch per htaccess Datei senden wenn man über das entsprechende Modul verfügt.

<IfModule mod_headers.c> 
Header set P3P "policyref=\"/w3c/p3p.xml\"" 
</IfModule>

Überprüfung der P3P

Mit diesem P3P Validator kann man dann die Datei überprüfen lassen. Sogar eine Zuordnung welche Datenschutzrichtlinien anzuwenden sind für eine bestimmte Seite ist über diese Abfrage gegeben. Denn die Möglichkeit ist vorhanden das für unterschiedliche Bereiche einer Domain eigenständige Datenschutzrichtlinien anzuwenden sind.