ich wüsste gerne mal, inwiefern Cloudflare datenschutztechnisch bedenklich ist für einen normalen Benutzer, wenn man eine Seite besucht, wo dies als Skript drauf ist (zu sehen mit NoScript und UBlockOrigin). Ist es dann nur bedenklich, wenn man die Skripte zulässt oder auch sonst schon? Gibt es anderes als Skripte was im Zusammenhang mit Cloudflare problematisch sein kann? Z.B. wenn man Online-Shops besucht?
Ich hatte schon einiges zu Cloudflare hier versucht zu lesen, aber ehrlich gesagt nicht viel verstanden. Schien sich an Webseitenersteller o.ä. zu richten, aber ich bin nur Nutzer.
Als Betreiber eines vermutlich nicht unerheblichen CDNs, das behandeln wir in einem noch zu findendem Sammelthema (ich werde das dann hier ergänzen).
Als Irritation in den Skriptblockern, das behandeln wir nun hier.
Es kommt auf den Inhalt an. Allein, daß Content nachgeladen werden soll, mag irritieren, muss aber nicht zwangsläufig Schlechtes enthalten.
Es gibt ja viele Content Delivery Networks und es ist für Betreiber von Webseiten sinnvoll, immer wieder gleiche Inhalte dort einmal abzulegen und den Traffic dort abarbeiten zu lassen.
Dagegen hilft zum Beispiel das AddOn LocalCDN (für Firefox, für Chrome, für Firefox auf Android), auch empfohlen auf dem Kuketz-Blog, das einem nach dem ersten Nachladen weitere Wiederholungen erspart.
Oder man kann auch auf das jeweilige Skript und dessen Ausführung im Scriptblocker ganz verzichten, wenn man den Content eben nicht braucht.
Daß man sie womöglich nicht mehr erreichen kann, weil der DNS einem eine Fehlermeldung zeigt, aber das behandeln wir, wie oben beschrieben, im anderen Thema.
Grundsätzlich können alle Nachladungen, egal von wo, auch Böses enthalten, das kann man nie wissen. Aber das ist ja nichts Neues.
Problematisch könnten auch ethische Aspekte sein, wie die Verbreitung oder das Schützen (DDOS Attacken) von Webseiten von stark politisch motivierten Menschen, wo angeblich auch Leben hätten gerettet werden können. (Quelle).
Manchmal nehmen sich sogar ethische Hackergruppen solche Seiten vor, doch wenn diese von einem gigantischen Unternehmen geschützt werden, ist es schwierig bis unmöglich gegen diese vorzugehen. Und Exekutive und Judikative sind oft zu langsam bis es zum Handeln kommt.
Für mich ist das Übelste an Cloudflare nicht die Dienstleistung, Skripte zur Verfügung zu stellen, sondern der „Dienst“, die Besucher einer Webseite abzufangen und auf einen Cloudflare-Server umzuleiten.
Stell dir vor, du willst Online-Banking mit der Bank deines Vertrauens machen. Deren Server steht in Deutschland. Du gibst die URL der Bank im Browser ein. Ein https-Request wird gemacht, der Server wird kryptografisch authentisiert, der Browser sagt „Sichere Verbindung“. Alles gut, du glaubst mit dem Server deiner Bank zu reden. Tatsächlich aber landen deine Daten alle auf einem Cloudflare-Server, z.B. in Kalifornien. Klartextlich! Deine Kontonummer, die Transaktionen, der Kontostand, …
Für mich ist damit das https-Konzept ad Absurdum geführt. Für mich grenzt das an Betrug. Und wenn du dann in die Datenschutzinfo schaust, wird das oft nicht mal erwähnt.
siehe auch hier: The great cloudwall
Das ist mal interessant, um überhaupt einen Überblick über das Ganze zu bekommen, wenn man von dem Thema noch keine Ahnung hat. Ich verstehe zwar noch nicht, was das genau bedeutet und wie das alles miteinander zusammenhängt, aber ich hoffe, dass das im Laufe des Threads noch klarer wird.
Scheint jetzt sowas Dual-Use-mäßiges zu sein, also eine Technologie/Methode/Erfindung, die einerseits positive, gleichzeitig auch negative Aspekte hat (so wie ich das jetzt verstanden habe, die Webseite kann ich mir nicht ansehen). Nichts gegen solche Überlegungen, aber mir ging es mit dem Thread erstmal drum, was man als Nutzer selbst tun kann, um sich zu schützen.
Ich dachte immer, alles was man in die Formulare eingibt, geht nur an den Webseitenbesitzer (bzw. was man in einer korrekt ausgefüllten Datenschutzerklärung der Webseite nachlesen kann, mit wem sie die Daten austauschen). Das wäre ja der Hammer!!!
Vermutlich ist es dann auch so, wenn man irgendwo ein Konto hat, was man mal irgendwann (vor cloudflare) angelegt hatte, dass das dann die Daten auch an Cloudflare geschickt werden, wenn der Anbieter jetzt cloudflare eingebunden hat?!
Das ist jetzt ein ähnlicher Schlag in die Magengrube, wie als ich erfahren habe, dass es google-safe-browing gibt und all meine angewählten Webseiten an google gingen, und das, wo ich immer so drauf bedacht war, google zu meiden.
Ich glaube, Du täuschst Dich: das zweite Thema macht es eher komplizierter, weil es in die anderen beiden hineinspielt. Es wäre bestimmt übersichtlicher, sich gleich dort zu informieren, auch wenn es erstmal anstrengender aussieht.
Das ist müßig, weil im Grunde alles im Dual Use konträre Zwecke verfolgen kann. Denk nur an eine Scheibe trocken Brot: Ein Nahrungsmittel? Man kann daran sterben (wenn man es einatmet und nicht wieder raus bekommt)!
Was maxmoon da anspricht, ist die Betätigung als Man-in-the-Middle. Du rufst eine Seite auf (die dort Kunde ist) und bekommst eine Fehlermeldung, an der Du nicht vorbeikommst, weil sie zu dem Drittel des Internets gehört, den CF verwaltet.
Näheres dazu findest Du in dem besagten Thema unter dem Stichwort „MiTM“. Du kannst dort auch nach Einzelheiten fragen.
Das hat mit Deinem Thema hier eigentlich nichts zu tun.
Gell? Da macht der Gedanke erst so richtig Spaß!
Genau das sollst Du ja auch denken!
Das macht keinen Unterschied: es geht schlicht um die eine aktuelle Verbindung. Sobald Deine Bank oder was auch immer, den Service gebucht hat, kann Dir sowas leicht passieren.
Ansonsten kann es das auch, aber dann wäre das ein Hackerangriff und man schützt sich mittels TLS, heutzutage.
Das Problem bei Googles „Safe Browsing“ ist, dass Google ständig über deine aktuelle IP informiert wird und dich schnell namentlich identizifieren kann (eine Email an einen Googlemail-Nutzer oder dein Android in deinem WLAN) und deinen Besuch (Dauer, Unterseiten, Medien etc.) auf den meisten Webseiten erkennen kann.
Das ist so nicht ganz korrekt. Mozilla bezieht die URL von Google und erstellt lokal eine Liste, mit der dann die URL verglichen werden. Google erfährt also nicht die aufgerufenen Seiten und nicht immer die aktuelle IP.
… laden Browser wie Chrome, Safari oder Firefox in regelmäßigen Abständen (ca. alle 30 Minuten) diese Blockliste bei Google.
Hervorhebung von mir.
Übrigens hielte ich auch die 30minütige Übermittlung der IP an den Google-finanzierten Softwarehersteller zunächst einmal für datenschutzgefährlichen Unfug, der eher anderen Zwecken dient als dem Schutz des Nutzers.
Dass die Kenntnis der IP Google die Nachverfolgung der Surfens ermöglicht, weiß das nur Google?
Man muss da wegkommen vom „digitalen“, vom schwarz-weiß Denken: Mustererkennung erlaubt das Verwerten unscharfer Daten. Es reicht beim Tracking völlig, wenn ich jemanden mit 90%tiger Wahrscheinlichkeit „erkenne“. Zur Schärfung gibt es ggfls einfache, weitere „Tools“.
Bei einem Treffer sendet der Browser einen Hash der aufgerufenen Seite (URL) an Google
Das bedeutet auch: Google kann beliebige Urls auf diese Weise personengenau automatisiert überwachen lassen, d.h. prüfen, wann Otto Meier die Seite xyz aufruft.
Es braucht dafür nur die Einspeisung der Url in die Böse-Liste und die IP der Person.
Die Frage „Ruft target x die Webseite xyz auf? Wenn ja, wie, wann, wie lange, wie oft?“ ist für Google leichtens beantwortbar.
Ein ideales Überwachungsinstrument. Ob sich die In-Q-Tel schon gemeldet hat? Sie hätte einen Fehler gemacht, wenn nicht.
LocalCDN ist aus dem Privacy-Handbuch, der Arkenfox und bei Privacyguides.org schon lange rausgeflogen. Firefox Standard DFPI (dynamic first-party isolation) isoliert/partioniert die Bibliotheken vom CDN, so dass es so aussieht, als ob ein anderer Nutzer die Bibliothek anfordert.
Schöne Theorie. Aber nein so ist es zum Glück nicht. Die Banken die Cloudflare nutzen haben
2 Server. Einen, der die öffentliche Inhalte für Cloudflare bereitstellt, und einen sicheren statischen Server, für die Personbezogenen Daten.
LocalCDN war nie auf diesen Seiten gelistet. Decentraleyes war Bestandteil, ist dann „raus geflogen“ und LocalCDN wurde dort „angehängt“.
Wenn man die Verbindungen zu Cloudflare unterbinden möchte, ist (d)FPI keine Lösung. Die Requests gehen ja trotzdem raus.
Nein, bei Cloudflare findet definitiv eine TLS-Terminierung statt. Cloudflare bietet sogenannte „Regional Services“ an, was dafür sorgt, dass die TLS-Terminierung innerhalb EU stattfindet.
With Regional Services, TLS is only terminated inside the configured region. For example, if a hostname is configured to regionalize to the EU, any HTTPS request from the US will route to the EU. (Quelle: developers.cloudflare.com)
Hier wird das ganze Problem an einem konkreten Fall (DKB; 01/2020) beschrieben: www.it-finanzmagazin.de.
Ok, danke, das mit Google werde ich mir bei Gelegenheit nochmal genauer anschauen. Sollte nur ein Beispiel dafür sein, dass man nichts Böses denkt und dann überrascht es einen so. Jetzt wieder zurück zu Cloudflare und Anfängerfragen.
Liegt das an den Skripten?
Falls nein, gibt es einen indirekten Zusammenhang, also ist es in der Praxis wahrscheinlich, wenn eine Seite Skripte von Cloudflare verwendet, dass dann auch dieses Verhalten von Cloudflare vorliegt und umgekehrt?
nein, nach meinem semiprofessionellen Verständnis sind das zwei verschiedene Sachen, wenn auch beide unter den Begriff CDN fallen.
Wenn eine Webseite Skripte von Cloudflare (oder Google oder Twitter oder facebook …) einbindet, dann geht der Browser beim Seitenaufbau zu diesen ThirdParty Servern und holt die Skripte ab. Das sieht man z.B. in der Netzwerkanalyse von Firefox (über F12) oder in dem AddOn uBlockOrigin. Ein gutes Beispiel: tvinfo bindet Skripte von Cloudflare (und den anderen üblichen Verdächtigen) ein, liegt aber nicht hinter der Abfangstation CF.
Du kannst alle diese Skripte z.B. mit uBO blockieren.
Wenn hingegen die Abfangstation Cloudflare den Benutzer abfängt und zu Cloudflare umleitet, dann ist der Browser an diesem Vorgang nicht beteiligt und der merkt das auch nicht. Der Cloudflareserver gaukelt dir und dem Browser den Server vor, mit dem du zu reden glaubst, weil er dessen TLS-Private-Key besitzt. Beispiel: LineageOS.
Mit dem AddOn Cloud Firewall kann man den Unterschied sehr gut sehen: bei tvinfo wird die Seite angezeigt, das AddOn listet sehr viele gesperrte Skripte auf, auch von Cloudflare. Bei lineageos blockt das AddOn die ganze Seite.
Ist cloudflareinsights. com das Skript von cloudflare? Das habe ich schon öfter gesehen.
Hier hingegen
wird es mir nicht angezeigt (weder bei NoScript noch bei uBO, auch nicht nach Freischalten von tvinfo. Oder haben die Skripte von Cloudflare einen anderen (weiteren) Namen?
Na ja, dann verwende ich das Addon Cloud Firewall einfach weiter, dann sehe ich es ja, wann es vorliegt (bei 2 Seiten, die ich kannte, die cloudflareinsights. com verwenden, wurden diese auch von dem Cloud Firewall-Addon blockiert)
Sind die Skripte von Cloudflare denn unbedenklich freizuschalten? Aus Datenschutzsicht, meine ich? Weil ihr redet nur vom Nachladen von Inhalten im Zusammenhang mit Skripten, aber es können durch Skripte doch auch Informationen von mir erfasst werden und bei einem großen Unternehmen, das seine Skripte auf allen möglichen Seiten hat, besteht dann noch eher die Gefahr, dass da alles mögliche miteinander verknüpft wird, oder? Ganz unabhängig davon, dass zusätzlich Inhalte aus Formularfeldern zu Cloudflare geschickt werden können, was nudel beschrieben hat (*), das macht so eine Datenverknüpferei ja nochmals schlimmer.
(*) wäre dann das, was Bit in der Übersicht in seinem ersten Beitrag hier als zweiten Punkt aufgeführt hat?
Sind Hämmer und scharfe Werkzeuge aus Werkstätten wegen der Verletzungsgefahr zu verbannen?
Es kommt darauf an, was man daraus [resp. damit] macht.
Ein Skript ist im Grunde nur das Transportmittel und bezeichnenderweise mit eindeutigem Namen gekennzeichnet. Das lässt auf den Inhalt schließen, garantiert aber genau gar nichts.
Und ob ein Inhalt datenschutzrelevant ist, ist dann noch separat zu beurteilen, wenn man ihn und seine Kontexte kennt.
Jaaaa …
Außerdem ist einem natürlich schon der Name suspekt und wenn man unsicher ist, verzichtet man drauf.
Eigentlich gilt das aber auch für andere Skripte.
Deswegen lasse ich generell erstmal gar keine Skripte zu, öffne dann das first party script (falls es notwendig ist) und sehe dann überhaupt erst, was da noch alles angefragt wird.
Nur, wenn ich denke, daß ich die Seite öfter mal brauche, mache ich weiter:
Ich probiere solange, ob die Seite das Gewünschte hergibt, ohne daß ich unnötige Skripte zulasse, bis ich zum Ergebnis komme. Manchmal gelingt das auch nicht, dann verlasse ich die Seite wieder oder gebe mich dem Risiko hin.
Mit der Zeit lernt man, welche Skripte welche Effekte haben und erkennt schon viel am Namen:
Consent = Cookie-Banner oder -Wall
AD = Werbung
Google = …
CloudFlare = …
usw.
Aber das ist eine persönliche Einschätzung, die man schlecht allgemeingültig als Empfehlung verwerten kann, weil man eigentlich zu wenig über den Inhalt weiß und ob der Name überhaupt wirklich auf den Absender irgendeines Inhaltes referenziert.
Und selbst wenn man es wüsste, müsste man einen Katalog für all die Skripte anlegen und ihn dann auch noch ständig aktuell halten …
Wer will das verantworten?
Ja, genau, CDNs liefern auch aktive Skripte, die komplexe Aufgaben ausführen, aber auch anderen Content, im Grunde alles, was sich immer unverändert wiederholt: Standard-Texte, Bilder usw.
Das ist das Problem, dass man die nicht am Namen erkennt. Bei mir zeigt z.B. js.tvinfo.net auf Cloudflare (mit nslookup in der Konsole).
Aber es ist mir auch egal, bei mir sind alle ThirdParty-Skripte geblockt, egal ob von Google, Cloudflare, facebook …
Aber nein so ist es zum Glück nicht. Die Banken die Cloudflare nutzen haben