Von Browsern und Cookies

[Dieser Artikel ist die Zusammenfassung eines Vortragsabends über „Browser und Cookies“ am 7.3.2017. Hier wird mit Bildern gegeizt aber es sind Foliennummern angegeben, die sich auf die Bilder in der PDF-Datei beziehen. Online-Darstellung, Download]

Cookies

Hier geht es um Cookies! Folie 6

Amerikanische Cookies sind ein bisschen anders als die im obigen Bild; sie sind härter und mit Schokostückchen. Aber diese glatten Makronen (links von Aida, rechts von Merkur) waren für unser Bild besser geeignet. Jedenfalls haben diese Makronen unseren Gästen am Clubabend gut geschmeckt.

Für Cookies im computertechnischen Sinn gibt es keine Übersetzung. Man würde auch im Deutschen nicht auf die Idee kommen, diese Textdateien als „Kekse“ zu bezeichnen. Amerikaner sind in dieser Hinsicht deutlich kreativer.

Cookies ergeben nur im Umfeld eines Browsers einen Sinn. Und daher wollen wir die Arbeitsweise eines Browsers, besser gesagt, die Zusammenarbeit eines Browsers mit dem Server an den Anfang stellen.

Was ist ein Browser?

Browser gehören sicher zu den am häufigsten verwendeten Programmen überhaupt.

Ein Browser stellt Webinhalte dar. Das sind Texte (.html), Bilder (.jpg, .png, .gif, .svg), Stilvorschriften (.css), Skriptdateien (.js) und einige andere. Es wird Dir aufgefallen sein, dass man aber häufiger mit .php, .aspx, .aspx oder .jsp-Dateien zu tun hat. Manchmal sieht man überhaupt keinen Namen in der Adresszeile. In allen diesen Fällen übernimmt am Server ein Interpreter das Kommando und analysiert diese Sprachdateien und liefert eines der ursprünglichen Formate, also Texte (.html) oder Bilder usw. zurück. Diese werden sozusagen am Server „berechnet“ und dynamisch zusammengestellt. Folie 7

Browser hinterlassen Spuren!

Alle unsere Reisen durch das Internet hinterlassen Spuren. Server registrieren jeden einzelnen Zugriff, ganz ähnlich, wie das auch beim Telefonieren der Fall ist. Der Server speichert diese Verbindungsdaten in einer Zeile pro Zugriff. Er weiß das Datum, die Uhrzeit, seine eigene IP-Adresse, den genauen Pfad des Objekts (Bild oder Text) sowie Deine IP und Deinen Browsertyp. Den Inhalt selbst speichert er nicht, der wäre ja auf der Webseite zu sehen (vorausgesetzt, der Inhalt bleibt gleich). Hier ein Beispiel für eine solche Protokollzeile (und an jedem Tag gibt es Hunderte davon): Folie 4

2017-03-07 00:11:30 W3SVC296 194.50.115.163 GET /franz/erinnerungen/ich/kindheit/volksschule/ - 80 - 157.55.39.44 HTTP/1.1 Mozilla/5.0+(compatible;+bingbot/2.0;++http://www.bing.com/bingbot.htm) - 200 0 0 25144 307 3062

Eigentlich ist es aber der jeweilige Webmaster, der über diese Information verfügt, weil sich diese Protokoll-Dateien im Verzeichnis logs in seinem Verwaltungsbereich befinden. Der Webmaster könnte diese Dateien auch löschen. Es gibt dann noch eventuelle Backups aber nicht ewig.

Wenn also seitens einer Behörde die Anfrage an einen Provider gerichtet wird, wann von wem auf eine bestimmte Seite zugegriffen wurde, müsste der Webmaster oder wir am Server in die betreffende Protokolldatei schauen der Behörde eine Liste mit Uhrzeiten, Zugriffsobjekten und IP-Adressen aushändigen.

Man sollte aber nicht unerwähnt lassen, dass Menschen, die etwas verbergen wollen, sich vermutlich ohnehin nicht von einem registrierten Anschluss sondern von einem eher anonymen Endgerät also zum Beispiel von einem Internet-Cafe verbinden. Weiters ist es möglich, einen von vielen Diensten in Anspruch zu nehmen, die die eigene IP-Adresse anonymisieren. Man verbindet sich also nicht direkt mit der Zieladresse sondern (beispielsweise) über Cyberghost. Folie 5 Dann enthält zwar das Server-Protokoll des Zielservers alle Zugriffe aber die damit verbundene IP-Adresse liefert keine sinnvolle Spur. Dabei bin ich auf diesem Gebiet ein Laie; Profis kennen sicher viele weitergehende Verfahren, um ihre Identität zu verbergen.

Aufgrund einer solchen Rückverfolgung wird man also nur Personen finden, die über diese Spuren nicht Bescheid wissen und dadurch leicht ausgeforscht werden können. Was würde ich also tun, wenn ich wirklich anonym sein will? Ich besorge mir ein Handy ohne mich auszuweisen, vorzugsweise nicht an meinem Wohnort, eventuell kein neues Handy. Dazu verwende ich eine anonyme SIM-Karte mit Datenvolumen. Fertig. Natürlich drehe ich das Handy ab, wenn ich in der Nähe meiner Wohnung bin, damit keine örtlichen Zusammenhänge hergestellt werden können.

Das soll nun keine Anleitung sein, denn vielleicht habe ich sogar etwas Wichtiges übersehen. Aber genau diese Frage wurde mir am Clubtelefon gestellt. Die Frage war konkret, wie der PC und das Handy zu konfigurieren sein, damit einerseits nichts passieren könne (niemand soll eindringen können, keine Viren usw.)  und dass auch niemand wissen soll, wer man sei. Man kann sich genau so gut aus dem Leben verabschieden. Dann hat man alle diese Problem nicht. Das Leben ist halt einfach lebensgefährlich. Kommunikation ohne Spuren dürfte es nicht geben.

Meine Einladung zum Clubabend und der Hinweis, dass wir Das Problem in seiner ganzen Breite überhaupt nicht an einem Abend behandeln können aber immerhin könnten wir das Detail der Cookies analysieren, wurde leider nicht angenommen.

Wie arbeitet ein Browser?

Ein Browser allein kann zwar auch Dateien am Desktop (Texte, Bilder, Filme…) darstellen und hat dazu gar keinen Server als Partner, aber das ist nur eine Art Nebenerscheinung seiner eigentlich Funktion und die ist die Kommunikation mit einem Server.

Der Benutzer hat die Interaktionsmöglichkeit der Adresszeile und wie wir wissen, ist die Struktur dieser Zeile schon so universell geworden, dass man sowohl Suchbegriffe eingeben kann (und der Browser liefert dann die Ergebnisse der primär definierten Suchmaschine) oder eben eine Internet- (oder Web-)adresse.

Die Adresszeile hat die Bezeichnung URL (Uniform Resource Locator), oder auch allgemeiner URI (Uniform Resource Identifier). Folie 8 Eine solche Adresse hat folgenden Aufbau:

foo://name:pw@example.com:8042/over/there?key1=val1&key2=val2#chapter
\_/   \_____/ \______________/\_________/ \_________________/ \_____/
 |       |            |            |               |             | 
scheme ident      authority       path           query        fragment

Das Schema ganz links bestimmt, wie der formale Aufbau des Rest der Zeile ist. Hier gezeigt ist der Aufbau eines URL mit dem Schema http, also eine Kommunikation mit dem HTTP-Protokoll. In diesem Beispiel wurden alle möglichen Elemente eingesetzt, in der täglichen Praxis wird oft nur example.com eingegeben. Das vorangestellte name:pw@ zeigt, dass man sich auch automatisch auf der Seite einloggen könnte – sofern die Seite das unterstützt. Das der Domäne nachgestellte :8042 ist der Port. Die meisten Webanwendungen verwenden den Port 80 und dieser Wert muss nicht angegeben werden. Es kommt aber vor, dass Webs absichtlich oder in einer Testphase mit einem anderen Port betrieben werden, damit die Inhalte dem zufälligen Besucher der Domäne nicht sichtbar sind. Nach der Domäne:Port kommt ein Pfad, der das ist, was er ausdrückt: eine Folge von Verzeichnissen, die in exakt dieser Anordnung auch am Server existieren. Aber Achtung: ein CMS erzeugt eine solche Ordnerstruktur künstlich und diese Ordner existieren dann nicht wirklich; sie dienen nur dazu, einer Suchmaschine Informationen zu liefern. Man nennt dann den Pfad „Permalink“. Im QueryString, der dem Pfad folgt, gibt es vier besondere Zeichen: Das Fragezeichen ‚?‘ markiert das Ende des Pfades und den Beginn des Query-Strings. Das Gleichheitszeichen ‚=‘ trennt den Namen einer Kommandozeilenvariablen vom Wert. Das kaufmännische Und ‚&‘ ist das Trennzeichen zwischen Kommandozeilenvariablen und schließlich das Zeichen ‚#‘ ist das Trennzeichen zu einer Textmarke auf der betreffenden Seite.

Weitere Versionen eines solchen URL-Schemas finden sich bei den Unterlagen, die bei den Links angegeben sind. Folie 9

Rolle der Kommandozeilenvariablen

Diese Kommandozeile wird am Server einem Programm übergeben, das in der Lage ist, diese Zeichenkette in seine Bestandteile zu zerlegen und die einzelnen Variablen beim Seitenaufbau zu berücksichtigen. Um diese Funktion besser zu verstehen, betrachten wir einen typischen Aufruf der Suchmaschine Google. Die Anfangsadresse ist https://www.google.at. Sie hat keine Parameter und zeigt nur ein einfaches Suchfeld. Wenn der Benutzer einen Begriff eingibt, zum Beispiel „url“, verändert sich die Adresszeile nach einem Klick auf den Button „Google-Suche“ auf https://www.google.at/?q=url und daher weiß das serverseitige Programm über den Parameter q (für Question), was der Benutzer sucht und sendet nun nicht mehr das zentrierte Suchfeld sondern ein kleineres Suchfeld und eine Liste mit Treffern. Für den Benutzer wäre es völlig ausreichend, wenn jeder Titel mit einem Link zu dem jeweiligen Ziel hinterlegt wäre, also zum Beispiel zur Wikipedia als https://de.wikipedia.org/wiki/Uniform_Resource_Locator. Folie 10

Was für den Benutzer genügen würde, genügt Google nicht, denn Google möchte erfahren, welche Zeile der User gerade ausprobiert und daher ist dieser Link kein Link zum eigentlichen Ziel sondern wieder ein Link zurück zu Google, jetzt aber mit einer großen Zahl von Variablen, in denen auch das URL-kodierte Ziel enthalten ist (fett gedruckt). Es geht in dem Beispiel nicht darum, was diese Parameter bedeuten, sondern darum, dass diese Parameterzahl durchaus groß sein kann und auch, dass sie – wie im Beispiel – verschlüsselt sein können.

https://www.google.at/url
?sa=t
&rct=j
&q=
&esrc=s
&source=web
&cd=1
&cad=rja
&uact=8
&ved=0ahUKEwiDvpCc_MPSAhXBoRQKHUKrCtEQFggaMAA
&url=https%3A%2F%2Fde.wikipedia.org%2Fwiki%2FUniform_Resource_Locator
&usg=AFQjCNH05XKkkjItNuItqFEqibSSP3ZHpQ
&sig2=IQTlBqYeHFcD4veiejF_uA
&bvm=bv.148747831,d.bGs

Erst nachdem Google diese Parameterliste verarbeitet hat, leitet Google die Suche an das eigentliche Ziel weiter. Der Benutzer merkt diese indirekte Weiterleitung praktisch nicht. Es ist aber kein Problem, Google nicht zu informieren. Dazu muss man sich nur den Link, der als Text dargestellt wird kopieren und in einem weiteren Tab händisch öffnen; dann weiß Google nichts über das eigene Verhalten. Nur macht das niemand, weil es zu umständlich ist. Folie 11

Ein zweites Beispiel zeigt ein einfaches Formular. Zwei Textfelder, eine Auswahl für ein Rechenoperationszeichen und ein Button zum Ausführen bilden einen Rechner. Gibt der Benutzer Zahlen ein und klickt dann auf den Ergebnisbutton, müssen die Zahlenwerte zum Server gesendet werden. Das Serverprogramm wertet die Eingaben aus und sendet das Ergebnis wieder zum Browser zurück. In dieser Form funktionieren alle Formulare, aber in der Regel sind das Formularprogramm und das Auswerteprogramm dieselbe Datei und nicht wie im Beispiel zwei verschiedene Dateien. Das wurde nur wegen der Einfachheit so dargestellt. Folie 12 

GET

Diese beiden Beispiele zeigen die grundlegende Aufrufart einer Serverdatei. Immer, wenn auf einen Link geklickt wird oder wenn ein Formular ausgefüllt wird, sendet der Browser das Verb GET gefolgt von der Kommandozeile zum Server. (Beim Formular gäbe es zu GET die Alternative POST. Dabei würden die Parameterwerte nicht in der Kommandozeile sondern im Anschluss an das POST-Verb nachgesendet.)

Verben des HTTP-Protokolls

Der Browser kann an einen Server verschiedene Verben senden:

• GET Aufruf einer Datei am Server mit Parametern in der Kommandozeile
• POST Aufruf einer Datei am Server mit Parametern nach der Kommandozeile (sieht man nicht in der Adresszeile)
• HEAD Aufruf der Kopfzeilen einer Datei (aber nicht des eigentlichen Inhalts).
• PUT Senden einer Datei zum Server

Es gibt noch einige seltener benötigte Verben aber diese hier sind die wichtigsten. Folie 13

Verlauf eines HTTP-Requests

Um den Inhalt eines Objekts vom Server zu holen, sendet der Client (unsichtbar für den User) folgende Zeilen

GET <Pfad>/<Datei>?<QueryString> HTTP/1.1 CR-LF
HOST: <Server> CR-LF
CR-LF

Es sind genau zwei Zeilen mit Zeilenvorschub gefolgt von einem weiteren Zeilenvorschub. An diesem doppelten Zeilenvorschub erkennt der Server, dass das Kommando abgeschlossen ist und liefert seinerseits die Kopfzeilen und den Inhalt der Datei. Wäre statt GET das Verb HEAD verwendet worden, würden nur die Kopfzeilen gesendet worden sein. Folie 14

<Server>, <Pfad>, <Datei> und <QueryString> extrahiert der Browser aus den Angaben in der Adresszeile.

Visualisierung eines HTTP-Requests

Es ist wünschenswert, diesen Ablauf auch einmal sehen zu können. Das kann jeder mit einem Telnet-Client nachvollziehen. Telnet ist ein Terminalprogramm für das TCP/IP-Protokoll. Es sendet Zeichen von der Tastatur an eine angegeben Internet-Adresse und empfängt die Antworten von dort und zeigt sie an. Man sendet mit diesem Telnet-Programm die oben angegebenen drei Zeilen und sieht an der Antwort, welche Headerzeilen der Server dem Client mitteilt.  Folie 15

HTTP ist zustandslos (gedächtnislos)

Das bedeutet, dass das Holen eines Objekt mit dem Holen eines anderen Objekts in keinerlei Zusammenhang steht. Beispiel: Man loggt sich auf einer Seite ein und ruft danach eine zweite Seite auf. Diese zweite Seite weiß nichts davon, dass man sich auf der vorigen Seite eingeloggt hat. Wenn es daher für eine Anwendung nötig ist, dass man ein gewisser Zustand in Erinnerung bleibt, benötigt man dazu weitere Mechanismen, die in der eigenen Verantwortung liegen. Das HTTP-Protokoll unterstützt dabei kaum.

Wir sind etwa im Jahr 1991. Die Situation in der Kommunikation mit dem Server ist folgende:

Wir haben bisher gesehen, dass die Seiten über die Kommandozeilen- und POST-Variablen kommunizieren können. Zur Erinnerung: die Kommandozeilenvariablen sind die, die man in der Adresszeile sieht und die POST-Variablen haben dieselbe Funktion nur sieht man sie nicht, weil die Wertepaare nicht an die Adresse angehängt werden sondern in eigenen Zeilen im Zuge der HTTP-Kommunikation vom Client zum Server gesendet werden. Und es wäre auch kompromittierend, wenn man etwa ein Passwort im Klartext in der Kommandozeile sehen würde, nur, weil die nächste Seite das auch wissen will. Man würde also in einem solchen Fall die POST-Variante des Aufrufs wählen.

Aber bedenken wir eine komplexere Anwendung. Man müsste bei der Erstellung der Seiten immer einen Variablen-Satz von Seite zu Seite senden und dabei dürfte es keine Unterbrechung geben. Ein einfaches Beispiel wäre etwa, wenn man den Besucher erlaubt, die Hintergrundfarbe zu ändern. Man müsste die Farbe von Seite zu Seite weitergeben, weil es keinen gemeinsamen Speicherort für die Seiten gibt. Würde also etwa der Besucher zwischendurch eine andere Seite im selben Fenster aufrufen, wären alle bisher gesammelten Informationen weg und er müsste von vorne beginnen und sich einloggen. Folie 17

Die Geburtsstunde der Cookies

Wir sind etwa im Jahr 1993 und die Situation mit der Informationsweitergabe von Seite zu Seite ist höchst unbefriedigend. Das Internet ist sozusagen gedächtnislos und die GET/POST-Variablen sind wie eine Art „Stille Post“, mit der sich Seiten Informationen zuschieben. Daher wird damals angeregt, alle diese Zustände wie Login, Warenkorb, Seitenverlauf, Eingaben, persönliche Präferenzen usw. in einer Variablen zu speichern, die sich am Rechner des Benutzers befindet. Ein technisch genialer Einfall. Nehmen wir an, man wäre damals der Meinung gewesen, dass der Computer des Benutzers unantastbar sei. In diesem Fall wäre es notwendig gewesen, dass sich der Server alle diese Zustände merkt. Nun ist das bei wenigen Benutzern kein großes Problem aber bei vielen Tausend, ja Millionen Zugriffen hätte der Server nicht nur schnell sein müssen, er hätte auch einen sehr großen Speicherbedarf für diese benutzerspezifischen Daten gehabt. Und vor allem wäre es immer erforderlich gewesen, dass ein User sich einloggt, um ihm die richtigen Daten zuordnen zu können. Das ist mit der Cookie-Technologie nicht notwendig, denn wenn der Benutzer eine Seite besucht, wo er schon einmal war, wandert das Cookie vom Rechner des Benutzers zum Server und das dortige Programm weiß, wer da kommt und kann die Antwort entsprechend konfektionieren.

Was ist also ein Cookie?

Ein Cookie ist eine Textdatei, die im Zuge der Client-Server-Kommunikation auf Deinem Rechner gespeichert wird. Diese Daten können nichts auf Deinem Rechner auslösen aber sie können vom Server beim nächsten Seitenaufruf oder beim nächsten Besuch der Seite (je nach Lebensdauer) wieder gelesen werden und der Server kann Dich wieder als „alten Bekannten“ begrüßen und Deine bevorzugten Einstellungen wiederherstellen. Cookies können – wenn man es nicht abstellt – auch von Dritten gelesen werden. Auf diese Weise kommunizieren Marketing-Programme und informieren sich über Deine Interessen. Salopp gesagt unterstützen Cookies das Google-Geschäftsmodell. Aber um nicht Google allein zum „Bösen“ zu stempeln funktioniert das bei Facebook noch viel besser, weil es bei Facebook gar nicht um verschiedene Seiten geht, die sich durch Cookies wechselweise informieren, sondern immer um ein und dasselbe Programm. Der „Drittanbieter“ ist dort der „Erstanbieter“. Folie 19

Ein Cookie hat einen Namen und enthält einen Wert, also zum Beispiel heißt das Cookie „User“ und hat den Wert „Franz“. Darüber hinaus hat ein Cookie auch die optionalen Attribute DOMAIN, EXPIRES, PATH und SECURE:

• Name – Value (Beispiel: User:Franz)
• DOMAIN (default: aktuelle Domäne: hier erfolgt eventuell eine Weitergabe der Information an andere, indem nicht nur eigene sondern auch eine andere Domäne angegeben wird)
• EXPIRES (wenn nicht angegeben: SESSION-Cookie, sonst kann hier ein beliebiges Datum/Uhrzeit stehen; ein Cookie kann daher auch mehrere Jahre oder sogar unbegrenzt lag am Rechner gespeichert bleiben)
• PATH (default: aktueller Pfad)
• SECURE (nur https erlaubt)

Wenn kein „Ablaufdatum“ im Attribut EXPIRES angegeben wurde, „lebt“ das Cookie bis zum Schließen des Browsers und es heißt dann „Session-Cookie“.

Wenn also eine Seite aufgerufen wird, sendet das HTTP-Protokoll in seinem Kopfteile den Server alle Cookies der aufgerufenen Domäne und dem aufgerufenen Pfad. Folie 21,22

Ein abschließendes Beispiel für ein Login-Cookie

ClubComputer betreibt eine Buchhaltungsanwendung, die in verschiedenen Berechtigungsstufen benutzt werden kann. Anonyme User sehen nur den Kontostand, Clubmitglieder sehen auch die Ausgaben und Belege, Rechnungsprüfer und Vorstandsmitglieder sehen zusätzlich die Einnahmen und die Kontoauszüge, der Administrator kann auch Belege uploaden. Das verwendete Cookie ist ein Session-Typ, bleibt also nicht über die Betriebszeit des Browsers hinweg bestehen und man muss sich bei Neustart des Rechners neu einloggen. (Beschreibung der Buchhaltungsanwendung.) Folien 23-26

Wie behandelt ein Browser die Cookies?

Die vier am weitesten verbreiteten Browser sind Chrome (55%), IE (23 %), Firefox (11%), Edge (5%), Andere (6%). Du findest die wichtigsten Einstellseiten für Cookies wie folgt:

• Internet-Explorer 11 (ab Folie 28)
• Firefox (ab Folie 34)
• Edge (ab Folie 49)
• Chrome (ab Folie 55)

Bei unseren Vergleichen beim Clubabend am 7.3. wurde deutlich, dass Microsoft mit Edge und IE-11 die Cookies tatsächlich in kleinen Dateien speichert, während Chrome und Firefox dazu SQLlite, eine einzige Datei mit Datenbankstruktur, verwenden. Im Vergleich der Screenshots hat man den Eindruck, als wäre die Handhabung in den datenbankbasierten Cookie-Konzepten übersichtlicher.

Wann löscht man Cookies?

Ich selbst lösche Cookies nur dann, wenn bei der Benutzung einer Seite Schwierigkeiten auftreten. Es kann schon vorkommen, dass in unvorhergesehenen Situationen (Zum Beispiel bei einem Browser-Absturz) sich die Cookies in einem ungeordneten Zustand befinden und die Webseite mit diesen Cookies nicht zurecht kommt und fehlerhafte Seiten liefert. In diesen Fällen ist eine Löschung der Cookies für diese Domäne ein richtiger Schritt zur Wiederherstellung der Ordnung.

Wenn man auf einer Seite nicht wiedererkannt werden möchte, kann man natürlich deren Cookies löschen.

Alle Cookies löschen, das kommt für mich nicht infrage, denn ich will ja mit den von mit benutzen Seite arbeiten und nicht bei jedem Aufruf von vorne beginnen.

Inoffizielle „Cookies“

Cookies sind offizielle Daten, die von einer Webseite gespeichert werden. Aber es gibt in der Zwischenzeit weitergehende Möglichkeiten für Programmierer Dich zu verfolgen. Man spricht von „Super-Cookies“.  Schlüssel dazu ist die auf jedem Browser verfügbare Sprache JavaScript. Dieses JavaScript kann eindeutige Merkmale Deines Arbeitsplatzes errechnen und diese zum Server weiterleiten. Ganz ohne Cookies, zum Beispiel mit POST. Und es geht hier gar nicht um irgendwelche persönlichen Daten; es geht nur darum, dass Du es bist, der sich irgendwo, zum Beispiel bei Amazon eine bestimmte Seite länger angeschaut hat, sagen wir eine Seite über Drohnen. Dann kann die Seite dieses Informationspaar Drohne-DeineArbeitplatzId an befreundete Webseiten weitergeben und wenn Du dann diese anderen Seiten besuchst, ermitteln diese nach demselben Verfahren DeineArbeitplatzId und wissen aufgrund der ausgetauschten Verzeichnisse, dass Du Dich für Drohnen interessiert hast. Ganz ohne ein „offizielles“ Cookie.

Wir haben von Norbert erfahren, dass durch die Ermittlung von Kenndaten über Dein Endgerät (Android oder iPhone oder andere) der jeweilige Endkunde einen anderen Preis erfährt, weil man etwa annimmt, dass Apple-User bereit sind, mehr zu zahlen. Diese Verfahren sind als  „Dynamic Pricing“ bekannt. Sofern diese Seiten über Cookies kommunizieren, kann man diese Cookies gezielt löschen. Wenn dasselbe aber über inoffizielle, unspezifierte SuperCookies passiert, auf die der Benutzer keinen Einfluss hat, wird es schwierig mit der Anonymität. Wichtig ist dennoch zu wissen, dass es nicht um Deine persönlichen Daten geht, sondern nur um das Wissen dass jemand auf Deinem PC sich für Drohnen interessiert hat.

Über „rechtskonforme“ Cookies

Jeder von uns kennt die (oft nervende aber rechtskonforme) Nachricht auf Webseiten, dass hier Cookies verwendet werden. Wie sonst sollen interaktive Webseiten funktionieren? Der Text auf den PopUps ist aber wenig informativ und erweckt den Eindruck, als wäre es eine Option, die Cookies nicht zu akzeptieren und dass man dann sicherer unterwegs wäre. Aber das ist nicht der Fall. Zum Beispiel würde dann unsere Buchhaltungsseite nicht funktionieren und man würde immer nur die Seite als anonymer User sehen.

Weitergedacht könnte man auf diese Weise PopUp-Meldungen im Sinne eines „Tipp des Tages“ zu allen möglichen Anlässen zeigen, die da lauten:

• Ist es Dir bewusst, dass ein Klick auf einen aggressiven Link, Unheil auf Deinem Rechner anrichten kann? (Viel mehr als Cookies das können?)
• Weißt Du, dass Aufforderungen in Mails, dass Du etwas Wichtiges tun sollst, Dir ziemlich sicher schaden werden, wenn Du sie befolgst? (Spam-Filter sind eine gute Sache aber besser ist es, selbst zu erkennen, dass eine Spam-Mail vorliegt.)
• Weißt Du, dass man bei jeder Kommunikation Spuren hinterlässt, und dass es nur eine Frage des Aufwandes ist, sie zu rekonstruieren?
• Weißt Du, dass Texte, die etwas von Dir erwarten (Zum Beispiel „Annehmen ja nein“) nur Texte sind und dass das „ja“ oder „nein“ nur dann im Wortsinn richtig sein wird, wenn es sich um eine seriöse Seite handelt? Man kann die Ankündigung „Annehmen ja nein“ jederzeit auch so programmieren, dass es ganz egal ist, wohin man klickt; kaum hat man geklickt, ist man schon auf etwas hereingefallen. Und das kann bis zu „ganz schlimm“ sein; viel schlimmer als man das einem Cookie – ganz zu unrecht- unterstellt.

Mit einem Wort, das Leben ist lebensgefährlich aber noch gefährlicher wird es, wenn man vor lauter Angst alle Gefahren meidet und dann prompt bei einer ersten Begegnung mit einer Gefahr in die Falle tappt.

Mein Cookie-Text

Nachdem nun jede Seite, die Cookies verwendet (und das tun alle WordPress-Seiten, denn wir können uns ja auf einer WordPress-Seite anmelden und daher muss sich WordPress in einem Cookie merken, wer man ist und was genau man dann sehen darf), einen solchen Hinweis für den Besucher enthalten muss, habe ich mich für folgenden, eher weniger juristischen sondern eher informative Text entschlossen:

Diese Website verwendet Cookies.

Cookies sind kleine Textdateien, die beim Besuch dieser Website auf Deinem Computer dauerhaft oder temporär gespeichert werden. Cookies sind nicht in der Lage, Schadprogramme auf Deinem Rechner zu speichern oder zu aktivieren, da es sich nur um Texte handelt, die entweder nur gespeichert oder gelesen aber die nicht als Programm ausgeführt werden können.

Der ursprüngliche und nach wie vor unverändert gültige Sinn der Cookies ist die Notwendigkeit der Serveranwendung zu wissen, wer Du bist. Anderswie sind Benutzeridentifikationen oder Warenkörbe nicht realisierbar. Cookies bieten Dir im Web den Komfort, dass Du auf Seiten wiedererkannt wirst und in den meisten Fällen sich die Identifikation auf eine Bestätigung reduziert. Auch merken sich die Informationsanbieter Deine zuletzt besuchten Seiten und bieten Dir diese nach einem weitern Besuch wieder an.

Cookies werden auch dazu verwendet, Dein Surfverhalten innerhalb einer konkreten Website zu beobachten und damit zum Beispiel den Aufbau von Webseiten zu verbessern.

Cookies können aber auch Informationen über Deine Interessen speichern und an andere Anbieter weitergeben (Drittanbieter-Cookies). Das hat dann zur Folge, dass Du auf Webseiten, die das eigentlich gar nicht wissen können, Werbung von Produkten siehst, für die Du Dich schon einmal interessiert hast. Diese Drittanbieter-Cookies kann man auf allen Browsern abschalten. Es ist aber dadurch nicht sichergestellt, dass Du dann diese Werbungen nicht siehst, weil es bereits andere Verfahren als die Cookies gibt, deine Reise durch das Internet zu verfolgen.

Gewisse Aufgaben der Cookies (zum Beispiel das Merken von Passwörtern) überschneiden sich mit Eigenschaften der Browser, die ähnliche Informationen speichern.

Du kannst in Deinem Browser Cookies in den Einstellungen jederzeit ganz oder teilweise deaktivieren. Aber wundere Dich nicht, wenn Du bei deaktivierten Cookies nicht alle Funktionen nutzen kannst und manche Seiten möglicherweise überhaupt nicht mehr funktionieren.

Du kannst daher auch Cookies grundsätzlich einschalten (und das ist die Voreinstellung) und jene von unerwünschten Seiten unterbinden.

Zu den Drittanbieter Cookies: Webseiten teilen sich über Fremddomänen-Cookies mit, was Deine Interessen sind und bieten Dir dann darauf abgestimmte Werbung an. 

Was werfe ich täglich an gedrucktem Werbematerial weg. Insgesamt sind das ganze Wälder, die für sinnlos bedrucktes Papier verwendet werden. Müsste es nicht unser Anliegen sein, diese fehlgeleitete Werbung zu vermeiden? Sind nicht alle zielgerichteten Werbebotschaften nicht wenigstens ein bisschen intelligenter? Werbung würde in den Werbezonen einer Webseite ohnehin stehen. Wenn sie mich aber nicht interessiert hat sie überhaupt keinen Sinn. Wenn sich die Werbung aber auf meine durch Cookies registrierten Interessen bezieht oder zum Beispiel auf die Inhalte, die man auf der Seite ohnehin liest, dann ist das doch ein kleiner Fortschritt.

Und ob man schließlich ein Produkt kauft, das entscheidet nicht das Cookie, das entscheidet man immer noch selbst.

Diesen Text findest Du über einen Link im Cookie-Hinweis auf der Seite http://fiala.cc. Folie 27

Links

• PDF-Datei, Online-Darstellung
• PDF-Datei, Download