Cookies und der Cookie Permission-Irrsinn

[DarkViper]

Mal wieder ein klein wenig ausführlicherer Lesestoff...

Cookies, das können einerseits leckere Süßigkeiten sein, aber auch etwas, an dem man sich gehörig den Magen verderben kann.
Wie immer bei Süßigkeiten, sollte man auch mit Cookies sehr vorsichtig umgehen. Man braucht nicht darauf verzichten, aber sie zumindest in einem vernünftigen Rahmen genießen. 

Generell:  Auch dynamische, interaktive Websites (mit PHP erstellt) lassen sich theoretisch ohne jeden Cookie betreiben. Nachteil ist dann jedoch, dass die Session-ID mit jedem internen Link mit übergeben werden muss. Dieses Verfahren ist sehr unsicher, da dabei die Session-ID fast immer in der URL im Klartext lesbar vorhanden ist. Nur zu leicht übersieht man diesen Umstand (egal ob aus Unachtsamkeit oder Unwissenheit) und kopiert die ID versehentlich mit einem Link in einen Post oder Chat. Und schon kann jeder mittels dieser ID dem Program eine falsche Identität vortäuschen. Stichwort: "Session-Hijacking".

Prinzipiell hat jeder die Möglichkeit, durch entsprechende Einstellung seines Browsers die Annahme von Cookies recht genau zu steuern (siehe Onlinehilfe des Browsers). Leider sind dazu meist etwas mehr als rudimentäre Grundkenntnisse der Technik erforderlich.

Die Nutzung eines meist einfach Session-Cookie genannten Cookies kann diese Fehlerquelle schon mal mit hoher Wahrscheinlichkeit beseitigen, da die Übertragung der Session-ID versteckt in den Headerdaten von Aufruf und Antwort erfolgt.
Zu diesem Cookie selbst: Es ist ein ganz einfaches Cookie, das als Datum ausschließlich die meist 32-stellige, hexadezimale  ID der aktuellen Session (Sitzung) transportiert. Diese Ziffer ist eine rein zufällig erzeugte Zahl, die keinerlei Rückschlüsse auf irgendwelche persönlichen Daten zulässt.
Das Cookie wird im Normalfall auch automatisch von der Festplatte des Besuchers gelöscht, sobald entweder die Session abgelaufen ist oder die letzte Instanz des benutzten Browsers geschlossen wird.

Anders verhält es sich mit dem sogenannten "remember me" Cookie. Dieses sorgt dafür, dass einUser bei einem späteren, erneuten Besuch einer Website automatisch wieder angemeldet wird. Auch dieses Cookie enthält nur einen zufälligen Code ohne Hinweis auf den User. Jedoch wird es dauerhaft (manches mal auch für einen wählbaren Zeitraum) auf der Festplatte gespeichert. Es wird nur dann gelöscht, wenn sich der Benutzer  bei der besuchten Website explizit abmeldet.

Eine dritte Art von Cookies kann Einstellungen speichern, mit denen z.B. die Anzeigesprache, ein wählbares Layout,  die Zeitzone usw. durch den Besucher ausgewählt wurde. Auch der Zustand des Seitenbaumes im Backend expanded/collapsed etc. wird auf diese Art gespeichert. Diese Cookies können unter Umständen recht lange überleben. Sie enthalten aber im Normalfall keinerlei persönliche Daten oder Daten, die Rückschlüsse auf den Besucher zulassen.

Ganz anders sieht es bei Cookies aus, die zu Tracking- und Statistikzwecken angelegt werden. Diese sind speziell darauf ausgelegt, Daten zu sammeln. Dabei ist es relativ gleichgültig, ob diese 'nur' von eigenen oder von entfernten Programmen ausgewertet werden.

Besondere Vorsicht ist geboten, wenn kostenlose Dateien (speziell Javascript) von Drittanbietern eingebunden werden. Es kann vorausgesetzt werden, dass hierdurch Tracking-Cookies gesetzt werden und auch der Einsatz der Dateien überwacht wird. Niemand hat etwas zu verschenken. Es mag zwar kein Geld kosten, jedoch sind die Daten die von diesen Diensten abgegriffen werden, für diese bares Geld wert. Auch ist es für den Betreiber einer Website praktisch unmöglich festzustellen, was diese eingebundenen Dateien eigentlich machen und ob sie auch morgen noch so harmlos sind, wie sie heute vorgeben zu sein.

Merke:  Fremde, eingebundene Dateien können vom Anbieter jederzeit unbemerkt verändert werden!! Fremde, eingebundene Dateien könnten private Daten unbemerkt an jeden beliebigen Ort der Welt liefern!!

------------- übrigens
Das Forum von WebsiteBaker benötigt genau 2 Cookies:

• PHPSESSID Dies ist das 'berüchtigte" Session-Cookie, das einzig und allein die Session-ID speichert damit ein Besucher während einer Session (Sitzung) vom Server wieder erkannt wird und sich nicht bei jedem Seitenaufruf neu anmelden muss. (Dieses Cookie wird beim Schließen der letzten Browserinstanz gelöscht)
• SMFCookieXX Mit Hilfe dieses Cookies kann sich das Forum zum Beispiel merken, welche Kategorien der Benutzer auf- oder zugeklappt hat und welche Anzeigesprache benutzt werden soll. Dieses Cookie enthält keinerlei persönliche Hinweise auf den aktuellen Benutzer. (Dieses Cookie kann bis zu 6 Jahren überdauern.)

Weitere Cookies werden vom Forum nicht gesetzt. Auch werden keinerlei Zusatzmodule benutzt, die eigene Cookies setzen könnten.

[evaki]

Ich hab so bisschen das Gefühl

Du kannst auch gefühlt selbst finden, wenn Du schon weißt was gesucht ist:
https://de.wikipedia.org/wiki/Sitzungsbezeichner
und mehr.
MfG. Evaki

[dbs]

Da werden reine PHP-Funktionen verwendet.
Reinschauen kann man mit print_r($_SESSION);

session_start();
speichert intern dieses:
    [session_started] => 1526994...
    [TOKENS] => a:1:{s:7:"default";a:3:{s:5:"value";i:0;s:6:"expire"...
    [PAGE_ID] => 88
    [HTTP_REFERER] => https://deine.domain.de/pages/e...

Die generierte Session ID in dem Cookie verweist auf diese Daten.

session_regenerate_id();
Beim Wechseln der Seiten wird eine neue ID generiert und die Daten übernommen.
Das verhindert Session-Hijacking.

[msfrog]

Naja, dass da ne ID drinsteht kann man ja leicht sehen. Aber was macht denn WB nun genau damit, darauf fehlt irgendwie noch eine schlüssige Antwort. Ich hab so bisschen das Gefühl, dass es nichtmal die Entwickler mehr wissen

[evaki]

>>Is n' Systemcookie
Das ist sowieso ne Null-Info bzw. Allerweltsbezeichnung
Ein "Systemcookie" wäre eher dem Server (z.B. Apache) zuzuordnen, der kanns auch.
Da aber meist das System unbekannt ist, haut man halt so eine Bezeichnung raus.

Was bei WB generiert und übertragen wird ist ein Session-Cookie, eine beim Client hinterlegte Datei, die auf der Benutzerseite nach dem Schließen des Clients automatisch gelöscht wird.

Was macht WB?
Generiert aus Sitzungs ID und Session ein Session-Cookie

Das sagt z.B. FF

Code Select Expand


Name: wb-4857-sid
Inhalt: 77050mor6fii4fg9qnju0r7fm1
Host: localhost
Pfad: /
Senden für: Jeden Verbindungstyp
Gültig bis: Zum Ende der Sitzung

Also alles andere als Persistent oder auch Permanent-Cookies. Die könnte aber z.B. ein Modul generieren. Obs eines gibt? Keine Ahnung!

MfG. Evaki

[CyberDyne]

Hallo,
über den Sinn und Unsinn der DSGVO kann man wohl bis zum Sanktnimmerleinstag diskutieren, ohne zu einem Ergebnis zu kommen.
Trotzdem hätte ich gerne gewusst, was in dem Cookie über die jeweilige Sitzung gespeichert wird.

"Is n' Systemcookie, daher Ausnahme" reicht leider nicht, respektive meinen Kunden reicht das nicht, die sich einem Mob von Abmahnanwälten gegenüber sehen und die dann wohl zu mir schicken wollen, gebe ich hier eine klare Auskunft.

Also wat speichert WB in diesem Cookie? Kann man das nicht einmal kurz und bündig auflisten? Viel scheint es ja nicht zu sein und sie wird halt auch ohne Formular und ohne Warenkorb generiert.

Viele Grüße,
Klaus

[evaki]

Und noch ein bisschen DSGVO-Irrsin, nämlich die Informationspflichten.
Wenn man diesem Beitrag folgt, kann Telefonieren demnächst zur akrobatischen Nummer werden.

Schon allein deshalb getrennte Telefone für private und berufliche Kontakte.
Auch berufliche Kontakte nicht übers private Telefon annehmen.

MfG. Evaki

[evaki]

>>AVV's mit den Anbietern
Soweit kommts noch... Millionen Telekomanschlüsse mit Routern, die Adressspeicher haben, und noch keine Frage/Meldung von irgendwo? Da steht die Telekom vor -ups

Jedenfalls wird das, was sich bisher Verfahrensverzeichnis nannte, durchs Verzeichnis von Verarbeitungstätigkeiten (DSGVO) abgelöst.

Wie verhält sich das Verfahrensverzeichnis zu ADV? Beides verhält sich doch in diesem Beispiel "irgenwie" zu Drittleistern. Vielleicht 'nen Tip wo guck?

Als Freiberufler sollte man (meine pers. Empfehlung) konsequent private Kontakte von beruflichen trennen. Gerade bei denen wird das Gegenteil sehr oft "gepflegt" Deshalb neben dem priv. Telefon, ein zweites oder mehr anschließen. Die Telefone haben dann getrennte Personenverzeichnisse. Wie das dann mit dem Adressverzeichnis des Routers im Falle der Synchronistaion aussieht, weiß ich noch nicht. Bringt der das alles in ein einziges Verzeichnis, sollte man die Synchronisation tunlichst unterlassen. Aber vielleicht weiß da jemand schon wie sich das verhält -bei jedem Router anders oder gleich und wie?

MfG. Evaki

Edith: Ansonsten, gerade entdeckt: Datenschutz Verfahrensverzeichnis (mit Muster)

[dbs]

Hehe, wenn du es beruflich nutzt, wohl ja.
Machst halt noch ein paar AVV's mit den Anbietern.

[evaki]

Habe gerade 20 Seiten "ADV" (Auftragsdatenverarbeitung) vor mir liegen, is ja Tach vonne Aabeit 
Da wartet noch viel Spaß auf Euch.

MfG. Evaki
p.s. Is jetz mein Telefonspeicher in Handy, Telefonanlage un so auch Datenverarbeitung im Sinne von DSGVO?
Läude holt Euer DIN A6-Adressbücher wieder raus, aber mit Dokumentenpapier.

[hgs]

Dann mal schnell alle Domänen nach Österreich umgezogen und als KdöR habe ich Ruhe 

[Luisehahne]

Gefunden bei Heise
Keine Strafen: Österreich zieht neuem Datenschutz die Zähne
Dietmar

[evaki]

Nach "DSGVO und der Jugendschutz" gehts diesmal um DSGVO und die Fotografie.
Also vor Veröffentlichung den überfahrenen Hasen fragen, und die Metadaten löschen wegen Rückverfolgbarkeit.
MfG. Evaki

[evaki]

@Luisehahne:

Ich habe mit dbs den versuch gestartet und session deaktiviert, danach war hängen im Schacht. Wir setzen mit dem sessioncookie keine persönlcihe Daten. WebsiteBaker müsste komplett neu gecodet werden um ohne zu arbeiten.

Manchmal (gut, bei mir häufiger) brauchts halt 3xGuck

Es geht ja nicht um die Session(s) (gibts auch ohne php vom Indianer), sondern nur um die (Session)Cookies, und dann auch nur im FE.

MfG. Evaki

[evaki]

(Falls da 'n extra Topic draus werden soll, dann bitte abtrennen/verschieben)

DSGVO und der Jugendschutz
Ob man nun wirklich an Jugendschutz oder eher an eine ungestörte Geschäftstätigkeit dachte, ist hier unerheblich. Art. 8 DSGVO ist maßgeblich. Weil es hier jedoch auch nationale Spielräume gibt, empfehle ich zusätzlich die Anbieter-Alterskennzeichnung (per XML-Datei) auf dem Server zu hinterlegen, auch wenn das anscheinend noch nirgendwo erwähnt wird/ist (oder hat wer?). Wer keine Probleme bei (oder nach) Bestellungen mit Kiddies haben will, setzt dann rigoros die Altersstufe ab 18 Jahren. Dann sollten die Eltern das Problem an der Backe haben, und der Jugendschutz wird ernst genommen.
Schon mal'n Smartphone mit Jugendschutzsoft, die age-de.xml erkennt, gesehen?
Da lachen ja die Kinder, ähm die Hühner.

MfG. Evaki
p.s. "Sie haben Post:
Liebe Kunden, ab dem 30.4.2018 werden wir Ihnen die Möglichkeit geben, einen ADV-Vertrag gemäß DSGVO herunterzuladen.

[evaki]

>>zeigt nur, dass die Politik von der Technik null Ahnung hat.
Es freut sich der Jurist, wo Geld zu holen ist 

Ja der DAU und die Richter, da hab' ich hier schon zu erklärt, daß man das nicht unterschätzen sollte.
Vielleicht noch schnell ein E-Book (On Demand) erstellen und den Link der Datenschutzerklärung beifügen. 
MfG. Evaki

[msfrog]

Hallo,
danke für euer Feedback. Ich würde mich bei solchen Themen nicht drauf verlassen, wie normale Menschen das verstehen. Vor Gericht gibt es keinen gesunden Menschenverstand Also wirds wohl drauf hinauslaufen, dass ich überall dieses blöde Banner einbauen muss.

Trotzdem würde mich interessieren, was genau dieses Cookie macht bzw. wozu dessen Informationen genutzt werden. Wie gesagt, wenn ich Cookies nicht erlaube kann ich meine Seiten trotzdem nutzen. Multi-Language-Menüs hab ich nicht drin, wird das nur dafür benutzt?

Evaki, für Warenkörbe ist das der einfachste Weg. Irgendwie musst du den Nutzer wiedererkennen, damit du weißt, welcher Warenkorb zu ihm gehört. Früher hat man das über eine Session-ID in der URL gemacht, das ist aber sicherheitstechnisch eine Katastrophe. Kopierte Links mit der ID führten dann z.B. fremde Nutzer ins Kundenkonto usw. Es gäbe sicher auch noch andere Möglicheiten, z.B. über die IP-Adresse, aber auch das ist problembehaftet. Ich versteh auch nicht, warum diese Cookie-Panik geschoben wird. Ja, es gibt Missbrauchspotential, dann muss man den entsprechenden Seiten eben auf die Finger hauen. Aber gleich mal eine sinnvolle und nützliche Technik im Netz mit diesem Fluch zu belegen zeigt nur, dass die Politik von der Technik null Ahnung hat.

[evaki]

>>Session Cookies ohne Einwilligung des Benutzers erlaubt
So wird es gehandhabt. (Deutschland hat die Cookie-Richtlinie nicht in nationales Recht umgesetzt.) Bei der Anwendung der E-Privacy-Richtlinie könnte es etwas enger werden, aber auch eindeutiger in den zulässigen Verwendungen, z.B. Spracheinstellungen, Konfigurationen usw. Entscheidend ist hierbei die Begründung für die jeweilige Nutzungsform. Es muß die z.B. die technische Notwendigkeit begründet werden. Dort wo es  über die "Verarbeitung von Kommunikationsdaten" hinausgeht, greift dann die DSGV, eben hier dann auch mit entsprechenden Begründungen.

Und da an einigen Stellen einiges offen bzw. kontrovers dasteht, kann man das auch schon jetzt, wie schon gesagt, mit ein paar Zeilen mehr erschlagen. Meine Gespräche in den letzten Tagen, haben mich von der Panikschiene runter gebracht. Machts doppelt und dreifach, erklärt mit Links noch das Internet dazu -Ihr sollt ja kein Buch schreiben, sondern ?? Ja was eigentlich? Ist das wirklich notwendig, den Besuchern das Internet vom Hoster bis zum Browser und, und, und... zu erklären? Dort sehe ich im Moment das hauptsächliche Problem. Oft muß man den Leuten erklären, daß das Ding womit sie im Internet surfen ein Browser ist.

MfG. Evaki

[Luisehahne]

Den netten Spruch habe ich gefunden

das Internet wurde konzipiert um einen Atomschlag zu überstehen - aber an Juristen hat damals keiner gedacht

Soweit ich das verstehe sind Session Cookies ohne Einwilligung des Benutzers erlaubt, sofern das Session Cookie für die Benutzung der Website unbedingt erforderlich ist.

Ich habe mit dbs den versuch gestartet und session deaktiviert, danach war hängen im Schacht. Wir setzen mit dem sessioncookie keine persönlcihe Daten. WebsiteBaker müsste komplett neu gecodet werden um ohne zu arbeiten.

Fortsetzung folgt
Dietmar

[evaki]

Naja, da die Juristen fortlaufend mitteilen, daß vieles kontrovers diskutiert wird, ist so einiges nicht eindeutig. weshalb nicht jeder Formfehler sanktionsfähig sein wird (wahrscheinlich dann wieder mit einer Zeitvorgabe für Änderungen, und entsprechenden Richtersprüchen). Deshalb gebe ich selbst (mit Rücksprache) ja den Rat, den Unterschied zwischen SessionCookie und SystemCookie erst garnicht zu machen, und eben zwei Zeilen Text hinzuzufügen. Dann ist erstmal Ruhe im Karton. Abmahner laufen dann auf, und das ist gut so 

Und zu den "Schwierigkeiten" sag ich mal, daß im FE alles bis auf spezielle Modulfunktionen oder Anforderungen wie Warenkörbe etc. auch ohne Cookies funktionieren sollte. Obwohl, für Warenkörbe sind die auch nicht zwingend, scheint nur aufwendiger in der Programmierung zu sein, wie ich mal "irgendwo" lesen konnte.
MfG. Evaki

[dbs]

Ich habe eben mal einen Test ohne SessionCookie im Frontend gemacht (deaktiviert in initialize.php Zeilen ab 486).
Hatte sofort Schwierigkeiten mit dem Multilanguage-Menü. Seite leitet unendlich weiter.
Vielleicht hat es auch mit Shorturl zu tun oder beidem.

Für mich ist das SessionCookie ein SystemCookie, ohne persönliche Informationen und wäre damit nicht bannerpflichtig.

[msfrog]

Hallo Evaki,
danke für den Link, hab die Antwort von Dietmar auch grad gelesen. Wär natürlich gut, wenn das schon vor dem Termin fertig wird, ich hätte einige Seiten upzudaten...

[evaki]

DEV arbeitet an der Lösung (Core un so...)
Soll rechtzeitig "zum Termin" fertiggestellt sein. Daumen drücken!
MfG. Evaki

[msfrog]

Naja, aber da haben wir doch schon ein Problem. Wozu dient dieses Session-Cookie von WB und ist es zum Betrieb unbedingt erforderlich? Speziell letzteres bezweifle ich, denn ich kann mir meine Webseiten auch problemlos mit geblockten Cookies ansehen. Lediglich der Login funktioniert dann natürlich nicht, aber das ist für den normalen Besucher ja unerheblich.

[evaki]

DSGVO=Verarbeitung personenbezogener Daten
ePrivacy–Verordnung=Verarbeitung von Kommunikationsdaten.
Letztlich entscheidend wird die ePrivacy-Richtlinie ein, die aber dummmerweise bis zum 25. Mai 2018 wohl nicht rechtzeitig mit der DSGVO in Einklang gebracht werden kann. Sogar Juristen können aktuell nicht sagen, "wo's lang geht", und geben Empfehlungen, beruhend auf Vermutungen. Seriöse Juristen benennen die Probleme halt auch. Auf der "sicheren Seite" ist man wohl, wenn man alle verwendeten Formen von Cookies angibt, und das wichtigste, deren Verwendungsgrund angibt. Nur unabdingbare sollte man einsetzen. Dieser Hinweis sollte als erstes beim Zugriff auf eine Website erscheinen.

>>Könnte man das nicht evtl. per Default abschalten?
Versuche es mal im Template mit diesem Tip

MfG. Evaki