Author Archives: Ralph Mönchmeyer

DSGVO, Datenschutz – und manche verdienen mit – ohne das Richtige zu leisten …

Posted on by

Meine Leser wissen, dass mir Datenschutz ziemlich wichtig ist. Aber manchmal könnte man sich die Haare raufen. Da gibt es endlich eine im Kern vernünftige Vorgabe des Gesetzgebers (nämlich die DSGVO) – und schon wird es von einer bestimmten Art von “Datenschützern” verdreht und missbraucht …

So erlebe ich gerade bei einem Kunden, den wir vor einer Weile auf die DSGVO aufmerksam gemacht haben, eine Art panikartiges Verhalten – nicht durch den Kunden selbst, sondern durch dessen externen “Datenschutzbeauftragten”. Es geht um die Erstellung von HTML-/CSS-Codes für statische Webseiten ohne Cookies – mit einer Ausnahme, nämlich Google Analytics. Das hatten/haben gar nicht wir zu verantworten. Vielmehr hat der Kunde auf einer Seite die Einbindung einer Google-Maps-Lagekarte gemäß der technischen Vorgaben von Google verlangt. Der Kunde hat einen klassischen Web-Hosting-Vertrag bei einem ISO 271001-zertifizierten Provider. Alles bestens. Wir erstellen Webseiten-Codes für statische (!) Seiten nach fachlicher Vorgabe und liefern die dem Kunden auftragsgemäß zu. Aus technischer Sicht ziemlich langweilig.

Nun sollen wir gemäß des besagten externen Datenschutzbeauftragten aber einen ADV-Vertrag (Auftragsdatenverarbeitungs-Vertrag) abschließen, weil “wir und nicht (!) der Provider die Web-Seite pflegen würden und durch die Webseite IP-Daten erfasst würden”.

Da hat wohl jemand was in den falschen Hals bekommen. Leider erweist sich selbiger “Datenschutzbeauftragte” als beratungsresistent.

Ihr wisst schon – ADV-Verträge, das sind die Verträge, bei denen es um die Verarbeitung personenbezogener Daten durch Dienstleister im Auftrag eines Auftraggebers geht. Zielvorstellung von zugehörigen Musterverträgen ist (übrigens ganz im Sinne einer Lieferanten-Einbindung in Datenschutz und Security) die Erfassung der Datenart, der Kreis potentiell betroffener Personen, der Kritikalität der Daten, der Reichweite der Bearbeitungsschritte, etc.. Typischerweise werden zweifache Controller (einer auf AG- und einer auf AN-Seite) eingesetzt, Datenschutzbeauftragte benannt und technische Maßnahmen zum Schutz der Daten vereinbart. Pönalen werden für den Fall angedroht, dass der Auftragnehmer mit dem ihm überantworteten Daten Missbrauch betreiben sollte. Alles gut und richtig so.

Ziel der ganzen Geschichte sind in erster Linie Auftragnehmer, die sich für Auftraggeber mit elektronischen Diensten und deren Wartung/Pflege befassen müssen, bei denen z.B. Kundendaten, Bankdaten, Personaldaten etc. erfasst werden. In diesem Umfeld ist das auch alles völlig berechtigt. Das betrifft potentiell Pfleger von Web-Shops, manchmal aber auch Blogs, Personalabrechnungssysteme, Hosting-Provider, etc..

Worum aber geht es in unserem Fall?
Wir erstellen wie gesagt im Zuge von Einzelaufträgen statischen (!) HTML/CSS-Code für ein paar Webseiten nach Vorgaben des Kunden. (Ausnahme: Das kleine Google Analytics-Script für die Maps-Karte). Die einzigen “personenbezogenen Daten”, mit denen wir dabei direkt zu tun hatten/haben, sind dabei die Daten, die im Handelsregister zur Firma veröffentlicht sind und auf den statischen Seiten wiedergegeben werden. Die Zulieferung der von uns erstellten HTML/CSS-Dateien kann von uns per Mail und zip-Datei erfolgen. Wir müssen die nicht mal auf die gehosteten Server hochladen. Mit dem Hosting-Vertrag unseres Kunden haben wir weiter nichts zu tun.

Nun hat der externe Datenschutzbeauftragte aber brav gelernt, dass der Hosting-Provider Zugriffsdaten bzgl. seiner Web-Server und auch bzgl. die Webseiten des Kunden erfasst – u.a. IP-Adressen der Besucher. Wie jeder Hosting-Betreiber halt, der einen ordentlichen Job macht. Wobei gerade der in diesem Fall relevante Provider erfasste IP-Adressen für seine Kunden nur begrenzt und nur verfälscht bereitstellt. Gelernt hat der “Datenschutzbeauftragte” auch, dass Google Analytics womöglich noch mehr Daten sammelt.

Wir haben den Datenschutzmenschen
deswegen schon beim ersten Kontakt darauf aufmerksam gemacht, dass sein und unser Kunde deshalb (aber nicht nur deshalb; man denke etwa an die Mailaccounts) wohl einen ADV-Vertrag mit dem Webhosting-Provider und auch Google braucht. Und dass es entsprechende Hinweise und Erläuterungen in der zu erstellenden Datenschutzvereinbarung für die Web-Site unseres gemeinsamen Kunden geben muss.

Statt dessen will er aber nun einen ADV-Vertrag mit uns, weil ja wir die “Website pflegen würden”. Das sei vom EuGH so geregelt. Und der gute Datenschutz-Mann bezieht sich dabei ausdrücklich auf die ggf. vom Provider und von Google Analytics erfassten IP-Adressen ….

Man fasst es ja nicht! Wir pflegen erstens gar nichts. Wir liefern beim Kunden HTML- und CSS-Code nach Vorgabe ab. Wir können zweitens auf die Elemente des Hosting-Vertrages, die Webserver und auf Log-Daten des Providers nicht zugreifen. Wir wollen das auch gar nicht. Wir haben auch keine Google Analytics Account für die Website unseres Kunden.

Und nun braucht es trotzdem wegen eines Web-Providers, zu dem wir nicht mal Zugang haben, und wegen von Google Analytics erhobenen IP-Adressen einen ADV-Vertrag mit uns? Wo wir von Google Analytics abraten?

Für diese Art von Wahnsinn und technischem Unverstand kann nicht mal Google etwas …

Ich meine: Hier versuchen Leute mit der Not von Kunden in geradezu halsbrecherischer Weise Geld zu verdienen. Leute, die mich kennen, wissen, dass ein ADV-Vertrag mit mir eine fachlich und technisch ausgefeilte Sache werden würde, die sicher mehr als 15 Seiten Vertragstext erfordern würde. Wieviele Stunden würde der externe “Datenschutzbeauftragte” wohl für den Erstellungsmarathon zu welchem Satz abrechnen? Und welchen Sinn hätte im vorliegenden Fall ein solcher ADV-Vertrag für den Kunden?

Wir hätten ja verstanden, wenn der “Datenschutzbeauftragte” aus grundsätzlichen Erwägungen eine Verschlüsselung des künftigem E-Mail-Verkehrs mit unserem Kunden verlangt hätte. Bieten wir natürlich auf OpenPGP-Basis an. Und ggf. eine Lagerung von Vorgabetexten für kommende Webseiten in irgendwelchen Crypto-Containern, falls es denn dabei den jemals um hochsensible Firmeninformationen gegangen wäre. Was alles nicht der Fall ist. Aber nein – er will einen ADV-Vertrag mit uns wegen eines Providers, der nicht unserer ist, und Google Analytics, die IP-Adressen sammeln.

Übrigens: Zu den für den Kunden wirklich relevanten Dingen – nämlich dessen ADV-Verträge mit dem Provider, mit Google, ggf. Facebook haben wir noch nichts gehört. Und eine textliche Vorgabe für eine Datenschutzerklärung, für die wir dann eine statische Website erstellen müssten, wobei wir auch alle anderen Seiten wegen des zugehörigen Link neu generieren würden, haben wir noch nicht bekommen. Sind ja noch 10 Tage Zeit …

Herr, bitte schmeiß mehr Hirn vom Himmel … bitte gleich … vor dem 25.05.2018!

Ein Einzelfall? Schreibt mir doch per Mail oder über Xing, wenn ihr gerade Ähnliches erlebt.

GnuPGP, email and eFail

Posted on by

Some of our clients use OpenPGP to communicate with us via mail. Now, after the last publications on eFail everybody gets nervous.

In general, some people out there – and hopefully not my clients – should indeed become nervous – if they use problematic email programs and/or handle them stupidly. In addition, there must be a chance of real and capable man-in-the-middle-attackers on the Internet – as e.g. secret or intelligence services – to perform and master the special attack vectors of eFail. (Actually, I do not care about the problems of bad guys out there misusing encryption for evil. I care about my business clients …).

But, my dear clients: It is not the encryption mechanism of PGP or OpenPGP in itself which fails! It is partially the stupid default settings in some email programs (regarding HTML/Javascript-execution). Such settings can and should be be changed. And partially there are flaws regarding the structuring of emails which can be used against encrypted PGP mails.

But all of this can be mitigated by short term measures – and, astonishingly for myself, some basic rules coincide with what I am not getting tired to say to my clients:

  • Forbid HTML/Rich text in your email client programs. It is a source of evil. Never ever open HTML-parts of a mail. Do not click on Links. Forbid automatic loading of remote pictures and alike.
  • Install OpenPGP in your desktop environment and decrypt your messages in a non HTML-capable environment outside your eMail clients.
  • Use Kmail or Evolution with PGP.
  • And of course: Use Linux – where GnuPGP/OpenPGP comes along as basic equipment of most user environments and does not require fiddling with external programs as on (some) Windows systems.

Properly used PGP in its Opensource variants still is a secure way of exchanging emails. And, please, remember:

If your whole desktop or PC/laptop/server-environment is under attack and hacked no encryption will help you when you decrypt/encrypt in such an environment.

So: Do not panic. Be clear about what the real threats are and where they potentially may come from! Follow some simple basic rules. PGP-based encryption is only one brick in a secure exchange of information. Other bricks may be much more and directly vulnerable from the beginning.

Get more information here:
https://thehackernews.com/2018/05/efail-pgp-email-encryption.html
https://efail.de/
https://efail.de/efail-attack-paper.pdf
Bruce Schneier on Details on a New PGP Vulnerability

And by the way: There are other aspects of PGP which deserve some interest with respect to intelligence services and/or economic espionage:
https://motherboard.vice.com/en_us/article/ezpxan/pssst-your-pgp-is-leaking

DSGVO – Löschung von Konten in diesem Blog

Posted on by

Liebe Leser dieses Blogs, dear readers of this blog,

Es gibt einige registrierte Leser dieses Blogs. Wir haben heute im Vorfeld der DSGVO die zugehörigen Konten bereinigt und einige gelöscht. Die entsprechenden User wurden per E-Mail benachrichtigt. Dahinter steckt keine Böswilligkeit unsererseits. Wir möchten allerdings dafür sorgen, dass registrierte Leser eine Kontoanmeldung auf Basis unserer Datenschutzerklärung vornehmen – und in dem Bewusstsein, dass Ihre Daten (E-Mail-Adresse, Namen, ..) gespeichert werden. Ferner sollten Nutzer, die Kontos als Kommentatoren nutzen wollen, klar sein, dass Ihre Texte auch im Entwurfsstadium für unsere Administratoren einsehbar sind und dass die Texte in Hinblick auf Spam-Versuche analysiert werden. Wir halten dieses Vorgehen für fair.

Wir möchten auch feststellen, dass dieser Blog primär Linux und Open Source Technologie/Tools unterstützt. Es ist auch mein persönlicher Weg, der Linux und OpenSource Community etwas zurück zu geben. Wir wollen auch in Zukunft und trotz zunehmender Anfragen nicht der kommerziellen Bewerbung von Closed Source oder technik-fremden Produkten dienen. Wir werden uns allerdings auch weiterhin mit solchen Produkten kritisch und konstruktiv auseinandersetzen – im Besonderen wenn sie unter Linux eingesetzt werden können.

There are some registered readers of this blog. In advance of the DSGVO / EU GDPR we have consolidated these accounts – and also deleted some accounts. We want to ensure that any further registration takes place by accepting
our data protection information. All account users should also be aware of the fact that their texts are visible to our administrators even before submit time and that all texts will be analyzed regarding Spam contents. We feel this procedure to be clean and fair. We shall provide an English version of the data protection information the next days.

We would also like to mention that this blog primarily supports Linux and Open Source technology. It is also our way of delivering soemthing back to the Linux and Open Source Community. We have no intention to support advertisement for closed source products or related companies. However, we will sometimes critically comment such products – especially when they can be used on Linux systems.

DSGVO – wir stoppen Google-Analytics nach einem Test des Verhaltens unserer Leser zu Cookie- und GA-Hinweisen …

Posted on by

Liebe Leser des Blogs,
wie viele andere schlagen wir uns gerade mit dem Thema DSGVO (bzw. EU GDPR) herum. Ein Thema ist dabei Google Analytics, kurz [GA]. Auch wir haben bislang in diesem Blog ein Plugin verwendet, um mittels GA feststellen zu können, wie oft unser Blog besucht wird und welche Artikel unsere Besucher am meisten interessieren. Wir haben dies bislang für legitim und auch sinnvoll gehalten. Nun hat sich unsere Meinung aber geändert.

Wie reagiert der Besucher von Websites auf Cookies und Google Analytics, wenn er die Wahl hat?

Das Gute an der DSGVO (EU GDPR) ist, dass man sich auch als Webseiten-Betreiber ein paar unangenehmen Fragen stellen muss. Eine Frage, die ich selber immer wieder verdrängt habe, ist:

Wie reagiert eigentlich der/die Besucher/in einer Web-Site, wenn er/sie entscheiden kann, ob Cookies verwendet werden und ob sein Verhalten mittels GA auf der Site getrackt wird oder nicht?

Wir machen uns dabei folgenden Aspekt zu wenig klar: Web-Site-Betreiber leisten ja eigentlich dem geschäftsbedingten Daten-Sammeltrieb von Google Vorschub, indem sie/wir vermeintlich zum eigenen Vorteil einen attraktiven und gut funktionierenden Service von Google nutzen. Gerade in im Falle von Google Analytics geht es aber nicht nur um unsere eigenen Daten. Die nachfolgende Frage drängt sich auf:

Kann man testen, wie der User oder Leser auf Google Analytics reagiert, wenn er rechtzeitig informiert wird – und eine Option hat? Antwort: Ja, das kann man – und sollte es im Vorfeld der DSGVO auch tun. Wir haben eine Woche lang – eher unfreiwillig – einen solchen Test gemacht. Hier ist unsere Geschichte, die uns selbst gestern ein wenig ungläubig auf GA-Daten zum Blog blicken ließ …

Erfahrung mit unseren Lesern, einem Cookie/Google-Analytics-Banner und GA-Opt-Out im Verlauf einer Woche

Am 01. Mai habe ich mich aufgrund der DSGVO mit verschiedenen Plugins und Cookie-Bannern auseinandergesetzt. Zudem mit Plugins, die ein Google-Analytics-Opt-Out durch den Leser ermöglichen. In den Blog integriert wurde dann einerseits ein Cookie-Banner-Plugins der italienischen Regierung, das wir als gut erachtet hatten (s.u.). Auf diesem Banner wiesen wir auf Google Analytics hin. Zusätzlich kam auch ein Opt-Out-Plugin bzgl. Google Analytics zum Zuge.

Eine Woche später mussten wir folgenden, für uns doch ziemlich überraschenden Effekt konstatieren:

Laut Auswertung der “Google Analytics”-Statistik ging die Anzahl der Besucher dieses Blogs am 02.05. angeblich von durchschnittlich 150 Besuchern pro Tag schlagartig auf 3 oder 4 pro Tag herunter. Tendenz im Laufe der Woche fallend. Gestern war es nur noch 1 Besucher am ganzen Tag.

Irgendwie nicht lustig … Ein wenig Studium des Programmablaufs machte aber deutlich, dass das ein Scheineffekt war/ist – allerdings ein interessanter. Denn ein Gegentest zeigte, dass die veränderte Google-Analytics-Statistik etwas über die Haltung und Meinung unserer Besucher aussagt.

Die Auswirkung restriktiver und besucher-freundlicher Cookie-Banner

Wir gehen nach einer zwischenzeitlichen Analyse davon aus, dass der beobachtete GA-Effekt auf eine gewollte Wechselwirkung des Cookie-Banner-Plugins mit dem üblich “Google Analytics”-Skript in den Webseiten zurückzuführen ist. Das sog. “EU-Cookie-Law”-Plugin bietet nämlich als eines von wenigen eine Option an, die ich für absolut fair und richtig halte und deshalb aktiviert hatte:

Das Cookie-Banner-Plugin unterbindet in Webseiten integrierte Skripte, die ja potentiell weitere Cookies setzen und lesen könnten, so lange, bis eine explizite User-Zustimmung zur Cookie-Nutzung erfolgt ist.

Das verhindert technisch nun auch
nicht jede Art von Benutzer-Analyse: Bereits der PHP-Code der Seite könnte ja Session-Cookies und auch (verschlüsselte) Cookies mit weiteren tiefergehenden Informationen zum Besucher aufgrund von Browser-Informationen setzen und zumindest im Zuge von Seitenwechseln bestimmte Dinge auswerten. Viele WordPress-Plugins und Themes etwa setzen eigene (relativ harmlose) Cookies zur dynamischen Ablaufsteuerung, z.B. im Zusammenhang mit Bildgalerien. Detailliertere Auswertungen des Nutzerverhaltens setzen aber Javascript oder andere Skripts am Client (Browser/App) und bestimmte Cookie-Typen mit unterschiedlichen Informationen voraus.

Deshalb bietet das Plugin der italienischen Regierung die Option, cookie-fähige Skripte zu unterbinden, die auf der Client-Seite – also im Browser – ausgeführt werden. Das betrifft u.a. JS, Flash. Und natürlich Google Analytics; kaum überraschend setzt das GA-Skript ja gleich mehrere (3) Cookies.

Fairness gegenüber dem Besucher von Webseiten

Aus unserer Sicht spiegelt die Option des italienischen Cookie-Banners den Geist der DSGVO wieder… Der User soll nicht nur informiert werden, sondern auch ein wenig Einfluss auf das Geschehen haben, wenn seine Daten betroffen sind.

Stimmt der Besucher des Blogs durch Klicken auf den angebotenen Button zu, so ist das alles kein Problem. Das Script für Google Analytics läuft dann regulär ab; das Verhalten des Users auf der besuchten Seite wird direkt registriert und kann vom Inhaber der Seite auch live mitverfolgt werden. Was aber, wenn der Besucher den Button bzw. das gesamt Cookie-Banner aus guten Gründen ignoriert? Eine Folge ist, dass das Mini-Skript von Google Analytics dann nie zum Zuge kommt ….

Der vorsichtige User ignoriert Cookie-Banner systematisch …

Nun ist das bewusste Ignorieren des Cookie-Banners eine völlig verständliche Reaktion. Ich selbst wähle dieses Handlungsmuster laufend – u.a. und im Besonderen auch auf Seiten von Suchmaschinen-Herstellern. Ein Motiv ist dabei:
Warum sollte ich etwas zustimmen, das nicht explizit einer Wahl sondern eher einer reinen Kenntnisnahme entspricht? Und warum sollte ich etwas zustimmen, bei dem ich die Folgen nicht abschätzen kann?

Implizit müsste ein derart vorsichtiger Benutzer dabei davon ausgehen können, dass dann eben auch nichts außer einfachen Session-Cookies zum Tragen kommt. In Wirklichkeit ist dies leider nur bei einem kleinen Teil von Web-Sites der Fall. Das Cookie-Informations-Banner wird meist nur aus Alibi-Gründen angezeigt; das Nicht-Anklicken des OK-Buttons hat vielfach keine Wirkung im Sinne einer Cookie-Blockade. Im Fall unseres Cookie-Banners war das jedoch anders.

Gegentests

Ich habe am gestrigen und heutigen Nachmittag dann mal getestet, was passiert, wenn ich die Sperre von Scripts über das Cookie-Banner wieder deaktiviere. Na, ihr erratet es schon:

An beiden Tagen wurden sofort wieder etwa 15 Besucher des Blogs innerhalb von jeweils ca. 30 Minuten Testzeitraum registriert. Das konnte ich live in unserem GA-Account verfolgen. Am Nachmittag ist das auf unserem Blog Durchschnitt. Damit ist die Theorie wohl richtig, dass unsere (intelligenten!) Besucher das Cookie-Banner entweder schlicht ignorieren oder systematisch eine ebenfalls angebotene Opt-Out-Alternative gewählt haben.

Konsequenz 1

Eigentlich sind Banner,

  • die ein Zustimmung zu Cookies anfordern und
  • die zulassen, dass clientseitig ablaufende Skripts im Hintergrund mehr als einfache Session-Cookies zur Steuerung des Seitenablaufs setzen, wenn der User das Banner ignoriert,

eine Farce. Wie gesagt: Ich selbst erwarte wider besseren Wissens, dass keine Zustimmung durch Button-Klick bedeutet, dass auch nichts passiert.

Aus meiner Sicht dienen die von GA dynamisch gesetzten Cookies jenseits meiner persönlichen
statistischen Interessen aber auch weiterreichenden Anliegen von Google (s.u.)! Es wäre also gegenüber unseren Lesern nicht fair, das GA-Skript nicht zu unterbinden, wenn der User das Cookie-Banner und seinen Button absichtlich ignoriert.

Konsequenz 2

Ignorieren die meisten unserer Besucher aber das Cookie-Banner tatsächlich absichtlich, so wird bei fairer Einstellung des Cookie-Banners Google Analytics für uns, vermutlich aber auch für andere völlig nutzlos. Das hat uns die Erfahrung der letzten Woche eindeutig gezeigt.

Die “neuen” Google-Bedingungen für die Nutzung von Google Analytics

Hinzu kam, dass man aufgrund der DSGVO als Nutzer von Google Analytics nun ja auch den neuen Google-Bedingungen für die Nutzung von Analytics zustimmen muss. Hmmmm – ausgedruckt sind das 13 Seiten, die Google da unverschämterweise nur in Form eines kleinen Popups anbietet, bei dem man sich dann den Mittelfinger wund-scrollt. Allein das sollte einen schon misstrauisch machen…. Zudem erhielt ich die neuen Nutzungsbedingungen in unserem Google-Account nur auf Englisch angeboten – obwohl Google natürlich sehr wohl erkannte, dass ich mich aus Deutschland auf der GA-Verwaltungsseite angemeldet hatte.

Ich muss nach einer längeren Lektüre leider sagen,

  • dass ich die neuen (englisch verfassten) Bedingungen mindestens genauso skeptisch sehe wie die von mir in diesem Blog zuletzt so kritisierten Nutzungsbedingungen von Facebook
  • und dass ich die Google-Bedingungen z.T. – wegen der ausgesprochen verklausulierten Anwaltssprache – als noch unverständlicher einstufe.

Es wird Leser meines früheren Artikels zu Facebook nicht wundern, dass auch bei Google eine Art “third-party-partners” (s. den Link unten) auftaucht – selbige heißen bei Google aber “Third-Party-Subprocessors” und “Affiliates”. Die spielen natürlich auch im Kontext der GA-Daten-Erfassung eine interessante Rolle. Letztere wiederum lässt sich allerdings nur über weitere sekundäre (und lange) Dokumente erschließen. Ehrlich: Das nervt!… schon auf Englisch, es würde das aber sicher auch auf Deutsch tun.

Mir scheint, die EU GDPR hat offenbar durchaus das Potential, das Geschäftsmodell bestimmter Informationskraken durch eine bessere Information von Nutzern in Frage zu stellen – und die Anwälte von Facebook, Google und Co. leisten nun ganze Arbeit, um Otto-Normal-Verbraucher mit wirklich schwer verdaulichen Text-Kaskaden von bestimmten Schlussfolgerungen abzuhalten. Gewollt oder nicht …

Im Fall von Google Analytics stößt man dann noch auf eine spezielle Anforderung: Man muss zustimmen, dass Google das Recht hat, Daten aus dem EWR/EU-Raum heraus zu befördern – speziell in die USA. Ich habe das mit meinen begrenzten Englisch-Kenntnissen zumindest so verstanden und meine, Punkt 10.1 ff. der neuen Google-“Terms” lässt hier keine andere Interpretation zu. Dieser Datentransfer dient dann u.a. der Versorgung von “Googles “Affiliates and Subprocessors” in solchen Staaten außerhalb der des EWR/EU-Raums. Dem soll ich als Google-“Customer” zwingend zustimmen.

Tja Leute, warum sollte ich das angesichts einer sich abschottenden amerikanischen Wirtschaft eigentlich tun?

Und ehrlich gesagt, die Termini “Affiliates” und “Subprocessors” gefallen mir gar nicht … speziell, wenn ich für ein besseres Verständnis noch weitere Papiere und Bedingungen studieren soll. Durch einen späteren Abschnitt und durch Appendix 1 wird übrigens klar, dass die exportierten Daten dann natürlich auch die erfassten Daten der Besucher einer Website umfassen. Zumindest nach meinem Verständnis. Vielleicht sollte google dazu mal Stellung beziehen.

Klar auch, dass in dem Augenblick, wo die Daten Server auf amerikanischem, chinesischem, russischem oder sonstigem Nicht-EU-Boden erreichen, dort womöglich der lokalen Rechtsprechung bzgl. des Umgangs mit
unseren/euren Daten unterliegen.

Konsequenz 3

Die neuen Nutzungsbedingungen von Google kann ich nicht guten Gewissens und schon gar nicht ohne vorherige Anwaltskonsultationen mittragen. Der ganze Text ist eine einzige Zumutung. Entscheidend ist dabei aber, dass es hier nicht nur um meine, sondern auch um eure Daten geht.

Liebes Google: Verlangt vom Nutzer eures GA-Services in Zukunft lieber eine angemessener Gebühr und haltet dafür die Daten dann ausschließlich auf EU-Servern vor. Und gebt sie (dann) explizit und grundsätzlich nicht an “Affiliates und Third Party Sub-Processors” weiter! Bitte sucht euch gefälligst auch Übersetzer, die das zugehörige Anwalts-Englisch in klare, für jeden Kunden nachvollziehbare Landessprache übersetzen.

Es ist für mich – wie bei Facebook auch – leider überhaupt nicht nachvollziehbar, was mit meinen und den erfassten Daten meiner Leser passiert, sobald diese Daten – offenbar absehbar und gewollt – die EU verlassen. Sorry, aber dabei gehe ich angesichts der Entwicklung in einigen Staaten weg von demokratisch verfasster Rechtsstaatlichkeit zunächst mal vom Schlimmsten aus. Gegenüber Eingriffen staatlicher Eingriffen nützt nämlich auch eine ISO 27000 nichts, auf die Google hinweist.

Da mein Cookie-Banner aus rechtlichen Gründen natürlich auch auf Google Analytics hinweisen müsste, sehe ich als Voraussetzung einer nachfolgenden aktiven Zustimmung des Lesers auch das Verständnis der Folgen einer Akzeptanz von GA-Cookies als zwingend notwendig an. Nun verstehe ich aber nicht mal selbst Googles Bedingungen … Das kann ich meinen Lesern nicht zumuten.

Der einwöchige Testlauf hat zudem deutlich gezeigt, dass zumindest die Leser dieses Blog die angeforderte explizite Zustimmung wohl aus guten Gründen nicht geben wollen und werden – was ich sehr gut verstehe!

Fazit

GA wird nach der DSGVO faktisch völlig sinnlos, wenn man mit seinen Lesern und potentiellen Kunden fair umgehen will – und eine explizite Zustimmung zu Cookies zur Bedingung für das Ablaufen wenn GA-Scripts macht. Ist vielleicht gut so, denn die Folgen der neuen Bedingungen für die Nutzung von GA kann ein Webseitenbetreiber eigentlich nicht ohne aktives Involvieren seiner Leser mittragen. Und meine Leser haben mir im Laufe der letzten Woche hierzu eine eindeutige Antwort gegeben.

Deshalb stellen wir Google Analytics auf diesem Blog im Interesse unserer Leser ab. Das entsprechende Konto bei GA wurde gekündigt. Leider behält sich Google das Recht vor, im Sinne von staatlich verordneter Datenvorratshaltung die bislang erfassten Daten noch eine Weile vorrätig zu behalten. Auch ein interessanter Punkt – aber ich mag meinen Blutdruck nicht weiter strapazieren …

Gerne könnt ihr mich per E-Mail zu diesem Thema kontaktieren.

Hinweis: Dieser Beitrag wurde am 08.05.2018 und 15.05.2018 textlich und inhaltlich bearbeitet. Am 15.05. wurden zudem etliche Rechtschreibfehler beseitigt.
Eränzung 15.05.2018: Möglicherweise fand der Beitrag ja auch bei Google-Mitarbeitern Interesse. So hatte ich am 07.05.2018 und am 08.05.2018 mehrfach Zugriffe auf mein Xing-Profil von Google-Mitarbeitern zu verzeichnen. Anonym natürlich … Liebe Leute von Google, wenn es etwas zu sagen oder zu besprechen gibt oder ich mich gar bzgl. der neuen Nutzungsbedingungen getäuscht haben sollte, dann schreibt mich bitte unter Nennung von Namen an. Ich bin auch gerne bereit, eure Meinung hier zu präsentieren.

Links

Leaving Facebook … – I
Bruce Schneier über Facebook, Cambridge Analytica und die Daten-Sammel-Industrie
https://www.kuketz-blog.de/das-kranke-www-stop-using-google-web-services/
https://traffic3.net/wissen/webanalyse/google-analytics-datenschutz
https://www.blogmojo.de/google-dsgvo/#5_google_analytics

PHP, MariaDB, Load Data Infile – manchmal ist der Umweg über Dateien performanter ….

Posted on by

Im Moment bin ich wider mit LAMP-Entwicklung beschäftigt. Mit Simulationen zu technischen Netzwerken in mehreren Dimensionen mit vielen Knoten, die kreuz und quer verbunden sein können. In solchen Netzen gibt es u.U. eine mit der Knotenmenge exponentiell wachsende Anzahl von Pfaden. Die Simulation des Informationstransports durch solche Netze ist ähnlich zum Transport von Signalen in “künstlichen neuronalen Netzwerken” – in unserem Fall ist aber die Komplexität aufgrund der Netzstruktur und der Qualität der transportierten Information erheblich größer.

Das Ziel meiner Auftraggeber sind datenbankgestützte Simulationen solcher technischen Netze mit PHP. Bei einer hinreichenden Anzahl von Knoten, Ebenen und Verbindungen erhält man dabei u.U. erhebliche Datenmengen, die man während der laufenden Rechnung systematisch auslagern muss. Das ist in Forschungslabors mit einer Armada von Prozessoren und SSDs nun heute selten ein grundsätzliches Problem. Im einem kleinen Büro oder auf billigen LAMP-Servern aber sehr wohl – insbesondere dann, wenn man nicht mit Multithreading in Web-Server-Umgebungen beginnen will oder aus Sicherheitsgründen gar nicht kann (pthread etc,. lassen das in Webumgebungen gar nicht zu). Oft hilft dann ein kleiner Umweg – und der führt u.U. über Ajax, Web-Clients und Dateien.

Ausgangslage

Aus bestimmten Gründen sollen die Berechnungen meiner Kunden auf LAMP-Servern angeboten werden. Hochgradige Programm-Effizienz ist also ein Muss. Günstige virtualisierte Mittelklasse-Server haben oft eine Ausstattung mit 4-6 Prozessoren, mehreren GB RAM und SSD-Speicherplatz. Zwei Prozessoren sollen ggf. einen Apache-Server mit PHP-Modul stützen, zwei andere eine Hauptdatenbank, die während der Simulation benutzt wird, und ein fünfter ggf. eine Bank für Ergebnisdaten.

Nun macht jeder mal die Erfahrung, dass Datenbank-INSERTs in der Regel grundsätzlich zu den langsamen Transaktionen zählen. Zudem behindern sie in einem PHP-Programm die Ausführung weiterer datengenerierender Funktionen, die möglicherweise gar nicht – oder zumindest nicht zeitnah – von den erzeugten Outputdaten abhängig sind. So kann es je nach Breite von Records schon mal im Bereich von Sekunden dauern, wenn man mehrere hunderttausend Datensätze “on the fly” in Datenbank-Tabellen schreiben will – und dabei auch noch mehrere Indices aufgebaut werden sollen. Wertvolle Zeit, in der andere Dinge – nämlich weitere numerische Berechnungen – passieren könnten. Wie kann man da CPU-Zeit sparen bzw. sinnvoll nutzen?

Ajax und der Web-Client zur Multitasking-Steuerung für Arme

Man vergisst oft, dass bei gut separierbaren Aufgaben auch der (Web-) Client ins Spiel gebracht werden kann. So kann ein Client über Ajax zwei (oder mehr) PHP-Threads auf einem Apache-Server starten – jeder in einer eigenen Umgebung (memory-, session- und prozess-bezogen). Per Ajax kann man den zweiten Prozess auch periodisch – und in Abhängigkeit von zwischenzeitlich dokumentierten Ergebnissen des kontinuierlich laufenden ersten Prozesses starten.

Der Hauptprozess – in unserem Fall unsere Simulation – kann dabei mit den weiteren periodisch gestarteten Prozessen signalartig über ein gemeinsames Medium kommunizieren – nämlich über spezielle Tabelleneinträge in der Datenbank. Die periodischen Jobs lesen diese Information aus und verhalten sich entsprechend. Ergebnisse werden per Ajax an den Client übermittelt, der dann weitere Nachfolgeaktionen einleitet.

Diese Art von getriggertem “Multitasking” über einen zentralen Web-Client und einen vermittelnde Ajax-Schicht hat einige Vorteile bei langwierigen Prozessen – wie etwa Simulationsläufen. Eine typische Anwendung ist etwa das Status-Polling zum Simulationsprozess. Ich hatte darüber bereits früher in diesem Blog berichtet.

Umgang mit großen zwischen-zeitlich aufkommenden Ergebnisdaten

Wie können wir das nun nutzen, um
zwischenzeitlich produzierte große Datenmengen halbwegs schnell in eine Datenbank aufzuräumen? Man vergisst im LAMP-Geschäft zu oft Dateien als Austauschmedium und als Puffer. MariaDB/MySQL-Systeme bieten zudem einen hochgradig effizienten Weg an, große Datenmengen in flache Tabellen einzulesen, nämlich “LOAD DATA INFILE”:

Vergleicht man die Zeit, die man in einem ausreichend mit RAM gepufferten System mit Write-Caching auf Linux-Ebene benötigt, um strukturierte Daten in ein File zuschreiben, so wird man feststellen, dass das u.U. erheblich (!) weniger Zeit kostet, als zwischenzeitlich eine Datenbanktabelle zu befüttern. Das gilt auch dann noch, wenn man die Zeit hinzurechnet, die ein LOAD DATA INFILE der MariaDB für das Füllen einer Tabelle aus den insgesamt generierten CSV-Filedaten (mit ggf. Millionen Datensätzen) benötigt. Das Schreiben in ein File, das anschließende Laden in eine Tabelle einer ansonsten wenig ausgelasteten Bank (ohne gleichzeitige Index-Generierung!) und die nachträgliche Erzeugung von Indices ist i.d.R. immer noch um Faktoren schneller als der direkte Transfer über (prepared) INSERTs – selbst wenn man hunderte Rows in ein INSERT-Statement packt. Zeit, die – wie gesagt – vom eigentlichen Simulationsprogramm genutzt werden kann!

Hinweis:
Ganz entscheidend für den effizienten Einsatz von “LOAD DATA INFILE” ist hierbei, alle Indices von der zu befüllenden Tabelle gelöscht zu haben, die Daten zu laden und erst danach die notwendigen Indices zu generieren. In all unseren Tests haben sich hierbei übrigens MyISAM-Tabellen performanter als InnoDB-Tabellen verhalten.

Schrittfolge

Wir werfen kurz einen Blick auf die Schrittfolge (habe leider gerade keine Zeit, schöne Grafiken zu zeichnen):

  • Schritt 1: Der Web-Client startet das Simulationsprogramm “S”, das durchgehend auf der Hauptdatenbank-Instanz arbeitet.
  • Schritt 2: Der Web-Client startet unmittelbar darauf auch noch zum ersten Mal und danach periodisch ein weiteres Programm “O”, das für die Behandlung von Output-Daten zuständig ist (sobald halt welche angefallen sind) und das dazu eine spezielle Tabelle der Hauptdatenbank auf Einträge zu fertiggestellten Output-Dateien abfragt. Der Client startet “periodisch” aber nur dann weitere Jobs vom Typ “O”, wenn er zuvor Statusmeldungen des aktuellen “O”-Prozesses erhalten hat, und sich der aktuelle “O”-Prozess beendet hat.
  • Schritt 3: Der zweite PHP-Prozess “O” widmet sich dann jeweils der zuletzt fertiggestellten Datei, prüft ggf. deren Struktur und übergibt dann die weitere Behandlung an einen LOAD DATA INFILE-Prozess der MariaDB – ggf. einer zweiten separaten Datenbank-Instanz, der eigene Prozessoren und memory-Anteile zugewiesen wurden.
  • Schritt 4: Nach einem erfolgreichen Laden der Daten durch den Prozess “O” beendet sich dieser, nachdem er dem Client noch eine Meldung per Ajax zugeschickt hat.
  • Schritt 5: Der Client startet ein weiteres Mal das für Outputs zuständige Programm vom Typ “O”.
    etc.

Das Ganze dauert so lange, bis vom Hauptprogramm ein “Signal” (per DB-Eintrag) gesetzt wurde, dass kein weiterer Output mehr zu erwarten ist.

Das Vorgehen entspricht einer Art selbstgesteuertem, dynamischen Batch-Processing von Daten auf einem LAMP-Server. Es erfordert ein wenig mehr Programmieraufwand (insbesondere zur Fehlerbehandlung) als ein Standard-Vorgehen im Rahmen eines einzigen Threads – es bringt u.U. aber Faktoren an Performance – solange die Simulation nicht auf Zwischenergebnisse in der Bank warten muss. Letzteres ist bei uns oft genug der Fall.

Wir haben so Programm-Läufe, die in Tests 25 Sekunden dauerten, auf unter 5 Sekunden gebracht. Es
war der Mühe wert – und wir können anderen, die langwierige PHP-Programme für Simulations-Berechnungen auf LAMP-Servern nur empfehlen, eine solche Vorgehensweise an kritischen Engpässen mal als Alternative zu untersuchen.

Zusammenfassung

Fallen bei langwierigen PHP/LAMP-Programmen zwischenzeitlich große Datenmengen an, können diese u.U. ohne Beeinträchtigung des Hauptprogramms parallel durch weitere PHP-Programme einer Behandlung durch eine Datenbank zugeführt werden. Teil der Steuerung kann dabei ein gemeinsamer Ajax-Client sein, der die Ergebnislieferung der verschiedenen PHP-Programme überwacht. Der Datenaustausch zwischen den parallel laufenden PHP-Prozessen erfolgt dabei über die Datenbank, Ajax-Meldungen und Datenfiles. Zur Behandlung großer Datenmengen kann dabei LOAD DATA INFILE seine Performance-Vorteile ausspielen. Insgesamt sind dadurch im Einzelfall erhebliche Programm-Beschleunigungen möglich.