Der nächste Schritt ….

Die Grenzen zur Beeinträchtigung der digitalen Privatsphäre werden (erwartungsgemäß) weiter ausgelotet:
https://www.golem.de/news/verfassungsschutz-einbruch-fuer-den-staatstrojaner-1908-143268.html
https://www.sueddeutsche.de/politik/gesetzentwurf-bundesamt-fuer-einbruch-1.4564401
Unsere Sicherheitsorgane nicht mehr nur als Hacker ?.?.? — weil Hacking wohl zu mühsam ist und (erwartungsgemäß) nicht überall zum Erfolg führt?

Als nunmehr 60-Jähriger und Werte-Konservativer wundere ich mich über gar nichts mehr. Ich habe an der Schule noch gelernt, wie essentiell eine Beschneidung der Möglichkeiten von Inlandsgeheimdiensten aufgrund der Erfahrungen aus dem sog. Dritten Reich ist – und dass es nach unserer Verfassung zu keiner Verquickung geheimdienstlicher und polizeilicher Tätigkeiten kommen solle und dürfe. Und dass ein richterlicher Beschluss unbedingte Grundlage jeder Verletzung der Privatsphäre sein muss. Nun erleben wir, wie im Namen der Sicherheit von den Bewahrern der Sicherheit “weiter” gedacht wird. Dass sich große internationale IT-Monopolisten um Privatsphäre und die dt. Verfassung bislang schon wenig scherten, überraschte wenig; von führenden Politikern und Ministerien muss man als Demokrat dagegen mehr erwarten dürfen.

Früher verhinderte die Umsetzung solcher Ideen, wie sie in den in den Artikeln behandelten Gesetzentwürfen ausgeführt werden, allein schon der Aufstand der Rechtschaffenen in der FDP und der SPD. Wo bleibt deren Aufschrei heute? Die SPD fragt sich wahrscheinlich in Arbeitskreisen auf lokaler Ebene erstmal, ob sie in einer zunehmend digitalisierten Welt überhaupt leben wolle – kein Witz, das wurde mir von einem Ortsvorstand genau so in einem Biergarten gesagt – … und wenn, ob man dafür dann nicht ein Tripel statt eines Duos für die Parteiführung benötige … Hr. Lindner von der FDP würde wohl antworten, dass man solche komplexen Themen nur und ausschließlich den Profis überlassen muss – und nicht der Parteipolitik …

Denkt man IT-Sicherheit und IT-Privatsphäre durch, so wird schnell klar, welche extreme Bedeutung der Unversehrtheit privat oder professionell genutzter IT-Systeme zukommt. Ist die nicht mehr gegeben, so gibt es schlicht und einfach gar keine Privatsphäre mehr – auch nicht bei Einsatz von auf Sicherheit getrimmten Linux-Systemen und voll-verschlüsselter System-/Daten-Platten bzw. -Partitionen oder gar der temporären Entfernung von Datenträgern aus den Systemen bei längerer Abwesenheit. Selbst wenn man als vorsichtiger Zeitgenosse (z.B. als Investigativ-Journalist) seine genutzten Linux-Betriebssysteme und seine Daten nach einer solchen längeren Abwesenheit nur aus voll-verschlüsselten Backups mit prüfbaren Hash-Summen rekonstruieren würde, die man zuvor an sicheren Orten platziert hätte, würde einen das gegenüber unbefugten Eindringlingen in Wohnung oder Home-Office nicht wirklich schützen. Da die Eindringlinge – egal welcher Coleur – ja womöglich Zugriff auf die Hardware der genutzten Systeme (wie PCs, Server) bekämen, könnten sie auch diese manipulieren. Das ist u.U. sogar einfacher und für den Betroffenen schwerer zu entdecken als Manipulationen an Software. Hatten uns die Amerikaner nicht vor kurzer Zeit genau davor im Zshg. mit Huwai und anderen chinesischen Herstellern gewarnt? Nun, das Volk der Dichter und Denker erweist sich als lernfähig. Tja, es scheint, als mangelte es selbst den Herren Huxley und Orwell an hinreichender Phantasie für die Wirklichkeit …

Mail-server-upgrade to Opensuse Leap 15 – and some hours with authentication trouble …

Some of my readers know that the mail server in my private LAN resides in an encrypted KVM/qemu guest. It provides IMAP- and SMTP-services to mail-clients – and receives emails from several hosted servers on the Internet via a fetchmail system in a DMZ. It was/is my policy that any access to a mail service account on my private mail server requires authentication against user entries on a separate LDAP-server. The accounts the IMAP/SMTP-service-daemons deal with are not to be confused with Linux user accounts: On the mail server NO Linux user accounts are required for mail handling. I regard the absence of standard Linux user accounts on the mail-server as a small, but effective contribution to security. No mail user can login into the mail server as a Linux user. Nevertheless authentication for the use of mail services is required.

Upgrade top Leap 15 resulted in unusable mail services

The manual upgrade of the mail server system from OS Leap 42.3 to Leap 15 seemed to work perfectly. I got no serious warnings. As root I could login to the virtual KVM guest via ssh – and systemd had started all required services: Fetchmail operated on external servers in the DMZ and transferred new mails to the upgraded mail server. There my postfix queues and secondary services for virus and spam checks seemed to work perfectly. Regarding IMAP I could also see that new entries for new mails appeared in various email accounts (more precisely: in related spool directories). Everything looked great …

However, the big surprise came pretty soon: No mail user could login to the IMAP-service – neither with Kmail, nor Mutt, nor Thunderbird. Access to the SMTP service for sending email was not possible either. System messages appeared on the GUIs saying that there was an authentication error. A very unpleasant situation which required analysis ….

In the meantime I had to start a backup copy of the old mailserver guest installation. On this front
virtualization proved its strengths and simplicity – I had made a copy of the whole KVM guest before the upgrade and just had to include the copy as a virtualization domain into the KVM setup of the virtualization host. But, as the upgraded server had already processed some new mails, I needed to transfer these mails between the servers and reconstruct and reindex some IMAP accounts … A simple, but a task which can be done by some scripts ….

Error analysis

It took me quite a while to figure out where the origin of the upgrade problem was located. I first checked my local firewall protocols both on the mail server and on the LDAP server. Nothing special there … Then I checked the LDAP access protocols – there were successful data requests from various systems – but astonishingly not from the mail server. So it seemed that the mail services did not even try to authenticate their users … strange ….
I then created a new IMAP test user based on a new local Linux user account, i.e. with an entry in “/etc/passwd” and “/etc/shadow”. Guess what? This user could work without any problems. So, obviously the communication of the mail services with the LDAP service for authentication was not triggered or failed in a strange way. I, therefore, tried a manual data request to the LDAP server from the mail server – and got a perfect answer. So, there seemed to be no fundamental problem with the required sssd-daemon and client-configurations. What else was wrong? A bit of despair was in the air …

The role of PAM in the game

Then I tried to remember what I had done in the past to separate the email accounts from the Linux user accounts. Over the last years I had actually forgotten how I had treated this problem. After some reading in old diaries my attention eventually turned to PAM …

The PAM-layer offers Linux admins the possibility of fine-tuning access/authentication conditions for the usage
of a service; among other things you can request certain PAM-modules to authenticate a user via given credentials against defined resources. A sequential series of required, sufficient or optional criteria can be set up. ( When a service needs additional Linux user account information during a session NSS can in addition request information from name resolution backends as “/etc/passwd”. However, this is NOT required for mail services. )

Linux mail services often use the SASL-framework and the saslauthd daemon to perform authentication. SASL can communicate with a variety of authentication backends directly – but it can also use PAM as an intermediate layer. And, in fact, I had used PAM to access my independent LDAP-server with mail account credentials via the PAM-module for SSSD.

I have described my simple approach in a previous article
https://linux-blog.anracom.com/2014/03/15/cyrus-imap-mit-sasl-pam-sssd-und-ldap-opensuse-12-313-1-ii/
Unfortunately, only in German. I, therefore, summarize the basic ideas shortly (see also the graphics in the referenced article).

The things one has to do to force IMAP and/or a SMTP services to use LDAP, but other services to use local authentication resources is:

  • We direct local login-services, ssh-services, etc. on the server via PAM to local resources, only.
  • We eliminate any UIDs corresponding to email account names from local resources as “/etc/passwd” and “/etc/shadow” (and NIS if used).
  • We do not create any local home-directories for email account names.
  • We eliminate LDAP as a usable NSS resource from nsswitch.conf; i.e. we eliminate all LDAP references there.
  • We setup special PAM files in “/etc/pam.d” for the IMAP-service and the SMTP-service. These files will necessarily include pam-modules for the “sss“-service (pam_sss.so).
  • We select entries on the LDAP server for users which for any reasons shall NOT or NO LONGER get access to the mail service accounts, set the “host”-attribute for these entries and configure sssd to use the host-attribute. Or deny certain user names access to the IMAP-service by the help of IMAP -configuration files; cyrus e.g offers the maintenance of a list “userdeny_db”.

This strategy worked very conveniently already on an Opensuse 12.3 platform. Examples for the required special files “/etc/pam.d/imap” and “/etc/pam.d/smtp” are given in the article named above. The mix and sequence of the statements there is due to the fact that locally defined system users as “cyrus” must get access to the IMAP-service, too.

What had happened during the Leap 15 upgrade?

My configuration had survived multiple upgrades of the virtualized server in the past. But not the one to Leap 15! What had happened?

After having remembered the importance of the PAM configuration, I eventually had a look into the directory “/etc/pam.d” on the upgraded system and compared it to the respective directory on the original system. Whereas during previous upgrades “personal” PAM configuration files for services had been respected, the upgrade to Leap 15 simply had removed my PAM configuration files for SMTP and IMAP – without a backup! Incredible, but true! Actually and astonishingly, the contents of some other standard PAM files had been transferred to a backup ….

A restoration of my PAM files for the mail services lead to an immediate success – authentication for the access of mail accounts on the upgraded server was possible again. Some hours in the hell for Linux admins came to an end.

Conclusion

Never (!) trust a standard upgrade of a whole Linux system procedure to keep configuration files in “/etc/pam.d” untouched. Keep an admin or system diary for unusual approaches. And – of course: Full
backups of critical systems before backups are a MUST ….

Full encryption with LUKS (SHA512, aes-xts-plain64) – grub2 really slow ….

My German readers know that I work on an article series regarding a reasonable full encryption of customer related Linux laptops and virtual machines with dm-crypt/LUKS. Whilst experimenting with different configurations I found that all my naive assumptions regarding the boot time of fully encrypted systems on standard laptops were wrong.

The boot manager for Linux – Grub2 – can lead to unacceptable long boot times (> n * 10 secs) – despite much smaller and reasonable values for the time required by the kernel to open encrypted devices. Delay factors during boot of more than 7 to 8 are possible and have to be taken into account during the encryption setup.

In my case Grub2 appears to be dead slow regarding a distinct factor which determines the time required during a first boot phase until the graphical Grub menu with choices for bootable installations gets displayed. The time for later boot phases (loaded kernel with initrd-support, access to encrypted volumes by the kernel) is much, much shorter.

A quick test showed that Grub2 is inefficient with respect to the SHA512 and not to the core and aes-based symmetric decryption algorithm.

Continue reading

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

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

Leaving Facebook … – I

At the beginning of this year I got advice from several people to become a customer of Facebook. I thought this could be interesting – what would it feel like? Especially, as I am biased – against data collectors … And I knew the GDPR of the EU (DSGVO in Germany) would come soon … Would be interesting to see how FB would react …

My wife – a Norwegian citizen – is very active on Facebook and Instagram. One reason is that she, of course, is interested in current developments in her home country. My grandchildren are on Instagram. Some friends are on Facebook – mostly as private persons. So, there are obviously some points that at least count for other people in favor of FB. Among other things: FB offers “free” communication services. And it offers information spreading – on fast time scales. Yeah, well known … A fundamental question, however, is: Information spreading to whom?

As some people may have noticed: I have left Facebook two days ago – for good. As I have no other platform, yet, I want to explain my decision here.

Personal Experience – a summary

I have tried and used FB now for 4 months. My personal opinions and conclusions are:

  • FB comprises a totally unproductive bubble world on a headline level.
  • It costs you a lot of time and delays productivity of whole societies.
  • Instagram appears to make children and teens addicted. A whole generation is literally wasting its youth with FB products.
  • In a way Facebook undermines the business of serious news agencies.
  • It is manipulative and provokes you to publish opinions – without any filter.
  • It is definitely a machinery aggregating detailed profile information on individuals of big parts of the world’s population.

So, FB, for me is at least as bad as expected – if not worse. But last things first.

The new terms and regulations as part of FB’s reaction to the EU GDPR

At least after the EU’s GDPR (https://www.eugdpr.org/) FB became relatively clear about what information it gathers on you. By providing you – at least in principal – with information on new terms and rules. Which you must accept, if you want to continue using FB services.

They are, however, not so clear about how they earn money with their services – and who really gets your data. Should make you suspicious. Despite all efforts to create a certain impression: FB is NOT a welfare company. So, take your time and read the new terms very carefully … No, its no fun; if printed, its a lot of pages in tiny letters …

Whilst you read keep in mind that FB already transferred 1,5 to 1,8 billion data records on non EU-customers to the US – where the information provision is not regulated as it soon will be in the EU.

“Data Policy” information – how to find it
So how do you as a EU citizen get to information of how FB uses data about and on you:

To see the full extent you have to move to your account, down to the left side – Link “impressum/terms/NetzDG”. Then you get to a page with the old rules; but at the top there is a warning about imminent changes – and a link to the new rules. Click there – navigate a bit – yes, there is a link for a printable version on the left side. Get the whole stuff printed on at least 7 pages in a quite tiny font size. Read … and get reminded of the Windows 10 user conditions.

My short summary is – and please correct me, if you find something which you think cannot be interpreted the way I see it:

What data, where from?
FB gathers all information on you which it can get – from all types of sources, including other persons and services besides FB’s own applications.
About what you do, where you do it, when, and not surprisingly for data analysts, how you do it (when you interact with their pages, e.g. via mouse or finger movement, scrolling analysis, …).

They collect detailed information about all devices you use and – as far as possible – also on processes running there as well as on configuration settings. They collect data that identify these devices and their settings in a unique way – and which identify, thereby, also you as a person, your location and parts of your behavior, plus your relation to your Internet providers. They use face recognition techniques if allowed on your device or if you accepted conditions to do so whilst using a FB product. FB clearly says that it combines all this gathered information. Across all of their products you may use (FB, Instagram, Whatsapp, Oculus, …). Not excluding other secondary sources and resources – as “partners” on whose websites you may have been.

Partners
And because FB is such a welfare oriented company it also does the following; I quote:

“We use the information (including your activities off our Products, such as websites you visit and ads you see) to help advertisers and other partners measure the effectiveness and distribution of their ads and services, and understand the types of people who use their services and how people interact with their websites, apps and services.”

Please note the “off” (2 fs !) in the first sentence. And the remarkable word “partners”. Hmm, there are “partners” and there are “third-party partners” as we soon learn. Notably, FB does not mention any money here. And of course not, where FB and their “partners” pay tax for all this “help”.

Yeah, … And of course your data may be used in projects and research in the context of “general social welfare, technological advancement, public interest, health and well-being”. Unfortunately, you have to assume that FB itself defines the meaning and borders of all these nice words … especially “public interest”. These expressions are not explained and left open – what an arrogance!

Then we learn throughout paragraph III that YOU as a user should think carefully about whom you share information with – because you may loose control over your data. Oooops … in the end data protection is still my own responsibility – and shit happens as we all know ….

Third-party partners
And then (2 pages later) comes a very nice and very fine distinction:
The “third-party partners.” And, within this context, we almost cannot believe it:

“We don’t sell any of your information to anyone, and we never will. We also impose strict restrictions on how our partners can use and disclose the data we provide. Here are the types of third parties we share information with …”.

You can almost see the lawyer who has written this. From the context it should become clear that this is only about “third-party partners” – and maybe not a general statement on other types of (direct) “partners”. Otherwise, FB would have to explain, where all the billions do come from, every year, … I would say – an unexplained business is a kind of dubious business.

Another pretty creepy part in this paragraph is the following – see the lines under “Measurement partners”: “We share information about you with companies that aggregate it to provide analytics and measurement reports to our partners.”

Wow … Read it again and again … It is not (!) Facebook that aggregates – it is some other companies! Meaning these other companies first get personal data about you which they then (!) aggregate and provide back to FB’s partners. You see the funny lawyer again, which I mentioned above. I hope the EU data protection authorities have a very close look into this type of information provided by FB.

And then again the welfare attitude:
“We also provide data and content to research partners and academics to conduct
research that advances scholarship and innovation that support our business or mission, and enhances discovery and innovation on topics of general social welfare, technological advancement, public interest, health and well-being.”

Didn’t you always want to become a subject for some special analysis? Hey, you can get famous – somewhere in some data lab …

Cooperation with law enforcement
Pretty nice also some passages about sharing data with law enforcement institutions: Here we learn that the exchange of data is based on “good-faith belief” on FB’s side. You do not believe it? Read paragraph VIII of the whole mess yourself. And good luck, if you, e.g., happen to be Russian or Chinese …

Addendum, 04/28/2018: What is not written in the new Data Policy

As with other business it is interesting, too, what is not written down explicitly. In this case in the FB document on “Data Policy”.

E.g., you do not get information on who are “partners” – and what makes a “partner” a partner of FB. Also, the definition of a “third-party partner” is pretty unclear. So, in the end you do not know where your data end up – or who under which conditions employees of partners and third-party partners get access to them.

The other remarkable thing is: It is not written where FB stores your data and what they do for data protection – technically and otherwise. You may assume from newspaper articles that your data should be located on servers within the EU, especially in Ireland. But, you have no guarantee for this.

You may nail the whole mess down with some simple questions: How can you as a EU citizen be sure that there, e.g., is no copy of all your collected data on a Russian FB server – and/or that there is no Russian “partner” or “third-party partner”, who is allowed to get your personal data for “aggregation” and “research” in the “public interest” of Russia? My copy of the present “Data Policy” of FB does not seem to exclude such a type of scenario – if I assume that there are some Russian partners of FB. Are there? I would like to know .. Of course, I have learned that the data would not be “sold” to third-party partners or authorities … but maybe just given – in “good-faith belief” …

A last remarkable thing is that you do not find a single description about variants and functionality of AI and deep learning algorithms FB or their aggregating partners or third-party partners use. So, besides not knowing where your data end up, you neither get to know in which way and for which special purpose your data get analyzed.

Conclusion

Facebook is and remains creepy. Its information on what customer data they gather and what they in general do with it is partially quite open and partially very obscure and evasive. In my opinion. Some paragraphs in the “Data Policy” open up a legal void – with much room for interpretation.

Taking it all together, I see a fundamental lack of understanding at FB what data privacy really means – and how it should be described for customers. But there is one thing I must admit: FB warns you – in a way – that you should be careful about what you share on Facebook.

You should take this warning seriously. And read a comment of the well known security expert and researcher Bruce Schneier on the whole information gathering industry around FB and others; his comment was published on CNN:

Bruce Schneier on Facebook and CA

Read also about the EU GDPR and its intentions:
https://www.eugdpr.org/


See also:

www.heise.de/newsticker/meldung/Wegen-der-
DSGVO-Facebook-verschiebt-Daten-von-1-5-Milliarden-Nutzern-aus-Irland-4027584.html

https://www.heise.de/newsticker/meldung/Wegen-der-DSGVO-Facebook-verschiebt-Daten-von-1-5-Milliarden-Nutzern-aus-Irland-4027584.html
https://www.reuters.com/article/us-facebook-privacy-ireland/eus-top-court-asked-to-probe-facebook-u-s-data-transfers-idUSKBN1HJ1D5
https://www.zdnet.de/88331745/dsgvo-facebook-verschiebt-15-milliarden-nutzerkonten-in-die-usa/
https://www.newsslash.com/n/12074-dsgvo-facebook-verschiebt-nutzerdaten-zum-schutz-von-nicht-europaeern
https://www.zeit.de/wirtschaft/2018-03/plattformkapitalismus-internetplattformen-regulierung-facebook-cambridge-analytica