Internet-Law

Onlinerecht und Bürgerrechte 2.0

11.7.11

Cookies oder Pop-Up-Gewitter?

Über das mögliche Ende der Cookies durch eine neue Vorschrift im TMG, die im Zuge der Umsetzung der Datenschutzrichtlinie für elektronische Kommunikation geschaffen werden soll, hatte ich kürzlich berichtet.

Wie das mit dem Pop-Up-Gewitter in der praktischen Umsetzung aussehen würde, zeigt das Blog von David Naylor sehr anschaulich. Vielleicht kann man es sich ja so besser vorstellen.

posted by Stadler at 10:10  

15 Comments

  1. Aua! Körperlicher Schmerz!

    Comment by Tannador — 11.07, 2011 @ 11:04

  2. Aber das ist der Wahrheit.

    Schon dumm, dass die Leute die Richtlinien über Technik machen, nicht die gleichen Leute sind, die die Technik verstehen.

    Haben wir vielleicht einen politischen Evolutionssprung vor uns? Ist das Gesetzgebungsverfahren noch zeitgemäß, wenn Laien Gesetze über etwas machen, wovon sie nichts mehr verstehen?

    Man muss sich das mal vorstellen, Bürokraten und technische Laien bestimmen, wie die Technik zu funktionieren hat.
    Wer weise ist, ahnt wohin das führt.

    Comment by Frank — 11.07, 2011 @ 11:47

  3. Ein Fenster reicht auch, um den User zu informieren. Das ist lächerlich.

    Comment by ahhahaha — 11.07, 2011 @ 12:00

  4. Ich sehe da kein Fenster. Das funktioniert also definitiv nicht (mit noscript, ABP usw.)

    Obwohl, vielleicht hat das Gesetz ja doch was Gutes: Du lernst, Deine Privatsphäre selbst zu schützen oder ertrinkst im Popup-Gewitter.

    Comment by Joachim — 11.07, 2011 @ 12:43

  5. Das ist vollkommener Humbug. 99,99% der Seiten lassen sich vollkommen problemlos ohne Cookies betreiben wenn der Programmierer auch nur die geringste Ahnung von seiner Arbeit hat. Der einzige Fall bei denen Cookies wirklich benötigt werden ist beim Tracking von Benutzern – was sowieso unerwünscht ist – und das Weiterführen von Sessions auch nachdem die Seite geschlossen wurde. Letzteres ist in der Praxis die „Eingeloggt bleiben/Dauerhaft anmelden“-Checkbox bei der schon mit dem Anklicken der Checkbox der Benutzer einwilligt dass ein Cookie gespeichert wird und somit eine Abfrage entfällt. Ergebnis: Auf der einen Seite reine Panikmache, auf der anderen Seite ein Zeichen von Unfähigkeit der Programmierer.

    Comment by Rudi — 11.07, 2011 @ 14:59

  6. @Rudi:5
    Ich halte das nicht für ganz korrekt. Die Verwendung von Cookies in Webshops ist ein Sicherheitsfeature. Die Alternativen sind potentiell gefährlich für den Kunden und für den Anbieter.

    Zum Tracking gibt es einige mögliche Alternativen zu Cookies – zumal Firefox Cookies von Drittanbietern verbieten kann.

    Comment by Joachim — 11.07, 2011 @ 15:59

  7. @Joachim:6
    Was für einen Sicherheitsaspekt sollen Cookies denn erfüllen? Der einzige Aspekt den Cookies erfüllen würden sind die Weitergabe von Session-IDs beim Kopieren der URL, ein wirkliches Problem stellt das aber nicht dar. Durch eine einfache Bindung von Sessions an die IP-Adresse lassen sich de facto die absolute Mehrzahl der Anwender absichern, in Umgebungen mit einer gemeinsamen IP-Adresse (z.B. in Unternehmen) ist die Problematik nur bedingt vorhanden – denn dann müsste ja erst mal ausgerechnet jemand aus dem Unternehmen die URL erhalten. Durch Einführung weiterer Aspekte (wie z.B. User-Agent) lässt sich die Sicherheit erhöhehn.

    Würde beim Aufruf einer Seite dann detektiert werden dass einer der Aspekte nicht mehr stimmt, stellt es kein Problem dar nochmals das Passwort abzufragen und anzubieten, nun vielleicht doch Cookies zu verwenden oder, wenn das der Anwender nicht wünscht, zu erläutern weshalb dieser Fehler auftritt und ihm zu ermöglichen die Prüfung temporär zu deaktivieren.

    Vor wirklich sicherheitskritische Seiten – zum Beispiel bevor man einen Warenkorb abschickt – sollte sowieso nochmals eine Passwortabfrage erfolgen. Öffnet man dann für diese sicherheitskritische Bereiche ein PopUp in dem die Adressleiste ausgeblendet bzw. nicht benutzbar ist, ist die Problematik gelöst.

    Sprich: Nein, Cookies erfüllen keinen Sicherheitsaspekt. Oder sind da deiner Meinung nach Aspekte die ich übersehen habe?

    PS: Ich verbiete nicht nur Cookies von Drittanbietern, ich benutze für Cookies Whitelists. Das funktioniert ziemlich gut, meistens ist da NoScript problematischer – denn der Großteil der Seiten benötigt schlicht keine Cookies. Und die Seiten die wirklich mal Cookies benötigen bekommen Cookies die nur eine Sitzung gültig sind – mal von den wenigen Seiten bei denen ich eingeloggt bleiben will und denen ich vertraue abgesehen.

    Comment by Rudi — 11.07, 2011 @ 18:37

  8. Wo ist denn vorgeschrieben, dass man die Hinweise mit Hilfe von 20 Pop-Up Nachrichten darstellen muss anstatt einfach vorne weg eine Seite mit ner halben Bildschirmseite Text und darunter einer Schaltfläche „Akzeptieren“/“Nicht akzeptieren“?

    Comment by Pete — 11.07, 2011 @ 19:12

  9. @Rudi:7
    Cookies lassen sich kaum „stehlen“. IDs in URLs lassen sich erraten oder übernehmen. Post/Get kann manipuliert werden. Andere Methoden (via Cache, Pixel) sind wesentlich intransparenter und vom Nutzer kaum zu kontrollieren. Und selbst ohne Missbrauch sind Bookmarks mit Session-IDs sehr problematisch.

    Könnte es sein, dass sich die Macher von HTTP etwas gedacht haben, als die den RFC erstellt haben? Dir ist klar, was es bedeutet, das Rad neu zu erfinden zu müssen? Security by obscurity? Ok, ich warte auf Deinen RFC.

    Es trug erheblich zum Erfolg des Netzes bei, dass es immer auch ohne die Killerfeatures funktionierte. Deine Argumentation, das Netz funktioniere auch ohne Cookies ist sehr kurz gedacht. Damit wären wir noch bei Gopher…

    Doch ich will nicht noch überheblicher sein und mach hier – überlegend, ob ich mich jetzt ernsthaft entschuldigen muss, die Dinge hier nur plakativ anreißen zu können – Schluß.

    Comment by Joachim — 11.07, 2011 @ 23:54

  10. Bis auf die Youtube-Videos, die man auch ohne Cokkies einbinden kann, war da genau nichts dabei, dass ich als Nutzer vermisst hätte. So ein Pech aber auch.

    Comment by VonFernSeher — 12.07, 2011 @ 00:00

  11. @Joachim:9
    Dass die Übernahme von fremden Session-IDs de facto nicht möglich ist, habe ich bereits erläutert. Sie zu erraten ist sowieso totaler Quatsch… Zum einen weil die Verfahren zur Absicherung der Session sowieso greifen, zum anderen weil es vollkommen unrealistisch ist eine >30 Zeichen lange Session-ID zu erraten. Das ist absurd. Gleiches gilt für Bookmarks mit Session-IDs – die Wahrscheinlichkeit dass eine Dopplung auftritt liegt im Promillebereich, außerdem ist es auch hier nicht sicherheitskritisch. Der schlimmste Fall ist dass sich im Warenkorb plötzlich falsche Produkte befinden, auf fremde Rechnung bestellen kann man dann aber noch immer nicht da vor der Zahlung nochmal nach dem Passwort gefragt wird.

    Cookies sind nicht notwendig. Sie sind eine Vereinfachung und deshalb im HTTP-RFC, das heißt damit aber noch lange nicht dass sie wirklich notwendig und unverzichtbar sind. Wie ich bereits sagte: In 99,99% sind Cookies absolut verzichtbar, nur in 0,01% werden sie wirklich benötigt. Und bei solchen Zahlen stellt ein Opt-In-Verfahren auch kein Problem mehr dar.

    Comment by Rudi — 12.07, 2011 @ 00:10

  12. @Rudi:11 Ich rate Dir ernsthaft, Dich eingehender mit Sicherheits-Themen zu beschäftigen.

    Ohne (Sesson-)Cookies sind Login-Sitzungen auf Webseiten nur schwer bis gar nicht abzusichern. Das haben Sicherheits-Experten des öfteren gezeigt.
    Und selbst mit (Sesson-)Cookies gibt es keine absolute Sicherheit.

    Das schlimmste wären falsche Daten? Willst Du beim Online-Banking, dass jemand Dein Konto einsehen kann?

    Eines der Stichworte lautet „Session Fixation“.
    Und dass es möglich sein kann, Session-IDs zu erraten, haben Bugs auf Browser- und Server-Ebene bereits gezeigt.

    „Die Mehrzahl der Surfer“ hat vielleicht kein Problem, wenn Cookies wegfallen würden, weil die Mehrzahl das Web nur als Besucher betritt und vom Hintergrund keine Ahnung hat.
    Aber es geht darum, keine unnötigen künstlichen Hürden aufzubauen.

    Comment by tim — 12.07, 2011 @ 13:35

  13. @tim:12
    Und jemand der Sessions stehlen möchte schafft es nicht Cookies zu manipulieren? Es macht überhaupt keinen Unterschied ob man nun ein Cookie verändert oder eine GET-Variable in der URI manipuliert. Das Ergebnis ist das Selbe, Mehraufwand bedeutet das nicht wirklich. Was ein Schmarrn…

    Comment by Rudi — 12.07, 2011 @ 13:48

  14. @tim:12
    Vor allem wenn man sich dein Online-Banking-Beispiel anschaut solltest du vielleicht nochmal nachlesen wozu Cookies überhaupt dienen. Sie dienen nicht dazu Sessions *innerhalb einer* Browsersitzung zu organisieren, sie dienen dazu Sessions *über mehrere* Browsersitzungen hinweg zu realisieren. Und da Online-Banking vorzubringen ist vollkommen absurd, bei welcher Bank bist du denn bei der Sitzungen beim Online-Banking weiter genutzt werden können wenn du den Browser schließt? Oder bei welchen Seiten kaufst du ein bei denen das beim Zahlungsvorgang funktioniert? Absurde Begründungen sind das, dafür waren Cookies noch nie da und waren nie dafür konzipiert worden.

    Comment by Rudi — 12.07, 2011 @ 13:51

  15. @Rudi:11
    Ich halte das für (teilweise) falsch. Doch im Grunde ist das unwichtig.

    Cookies sind deshalb nicht notwendig, weil sie internettypisch optionale Erweiterungen eines Protokolls darstellen. Es ist kein Bug sondern ein Feature – entsprechend einer Designgrundregel des Internet. Lass es, wenn Du nicht willst. Du hast die Wahl. So muss das sein. Die Macher der RFCs sind „die Guten“. Wieso bemängelst Du das?

    Cookies sind zum Tracking absolut nicht notwendig. Es gibt unzählige Alternativen. Alternativen die deutlich intransparenter sind. Die Diskussion geht am Problem vollkommen vorbei. Das Problem ist das heimliche, aufgezwungene und oft genug illegale Verhalten der Tracker. Diese Firmen sind „die Bösen“ – wenigstens teilweise grenzwertig.

    Statt Gesetze zu fordern (die Cookies, ak Datenspeicherung auf Nutzerrechnern verbieten und damit ohne Sachverstand in die technischen Regeln des Internet eingreift, dabei höchstens Symptome angeht und die Nebenwirkungen unbedarft hinnimmt, sogar befördert)

    solltet ihr:

    noscript, adblock+, requestPolicity und RefControl installieren.

    Ihr solltet Euch schlau machen, wie diese AddOns bedient werden. Vielleicht wollt ihr Tor verwenden. Dazu sollte man auch den Firefox einstellen können. Es braucht oft – und da hast Du Recht – keine Cookies und kein Javascript oder Flash, keinen „Referer“, keine Zählpixel usw.

    Zu kompliziert? Ihr solltet lieber den Browserherstellern auf die Finger klopfen. Die Browservoreinstellungen sind ein sicherheitstechnischer Gau, der sich in Teilen nicht einmal wegkonfigurieren läßt.

    Comment by Joachim — 12.07, 2011 @ 14:58

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.