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.

Weiterlesen

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen

Eine Verschlüsselung von Daten auf Laptops ist in Zeiten der DSGVO Pflicht, da Laptops verloren gehen oder gestohlen werden können. Mein in die Jahre gekommener Laptop benötigt eh' einen neue (jungfräuliche) SSD. Zudem muss ich auf Opensuse Leap 15 wechseln. Ein guter Anlass, eine Verschlüsselung von Betriebssystem- und Daten-Partitionen unter Opensuse Leap 15 zu testen.

Vor einem Tausch der SSD wollte ich zunächst ausprobieren, ob eine Betriebssystem-Verschlüsselung unter Opensuse Leap 15.0 mit dem Laptop überhaupt funktioniert. Die meisten Linux-Profis setzen die Kombination "dm-crypt/LUKS" zur Verschlüsselung von Partitionen oder Volumes ein. Dabei spielen verschiedene Parameter eine Rolle, für die unter Opensuse normalerweise der YaST-basierte Partitioner Default-Werte vorgibt.

Ich nahm mir diesmal allerdings die Freiheit, die LUKS-Partitionen selbst mit eigener Parameter-Setzung vorzubereiten. Danach wurde das ganze Unternehmen unerwartet abenteuerlich und es taten sich etliche Falltüren auf. Es gab u.a. Probleme mit dem SuSE-Installer; nicht mehr bootfähige Systeme, nicht funktionales Kryptographie-Setup, Dracut-Probleme sind nur einige Stichworte. Man glaubt, man hat eine Lösung und schon zieht ein Neuinstallieren des Bootloaders über YaST alles wieder in den Abgrund. Probleme mit dem Grafik-System (Optimus; Nouveau, KMS) kamen zwischenzeitlich dazu - mit komischen Querbeziehungen zu systemd beim Shutdown und Aushängen des verschlüsselten Volumes für das /root-Filesystem.

Der ganze Themenkreis erfordert neben praktischen Installations- und Konfigurations-Schritten aber auch einige "theoretische" Vorüberlegungen. Verschlüsselung allein bietet schließlich noch keine hinreichende Sicherheit ... und man muss auch an Konsequenzen für den praktischen Betrieb eines solchen Laptops denken. Zudem kann man sehr verschiedene Wege bzgl. des System-Layouts einschlagen. Beispiele für Varianten sind etwa:

  • Vollverschlüsselung unter Einschluss des root-Filesystems oder Einsatz von Daten-Containern?
  • Vollverschlüsselung des Hosts oder nur darunter virtualisierter Systeme?
  • LVM on LUKS oder LUKS on LVM ?

Das sind nur drei wichtige Variationsmöglichkeiten - über die man schon im Vorfeld der praktischen Installation entscheiden muss. Ich denke, das ist einige Blog-Posts wert ... Auch wenn das primäre Ziel die Voll-Verschlüsselung eines Linux-Laptops unter Opensuse Leap ist, so können viele der angestellten Überlegungen und Vorgehensweisen auch auf Desktops oder z.T. auf einfache Server übertragen werden.

Ich beginne mit einer Reihe von "theoretischen" Vorüberlegungen, die jedoch praktische Auswirkungen auf die Sicherheit der Daten haben. Um eine ständige Unterscheidung zwischen LVM-Volumes und Partitionen zu vermeiden, spreche ich nachfolgend generell von "Volumes". An den Stellen, wo die Unterscheidung wichtig wird, werde ich sie explizit treffen. "Betriebssystem" kürze ich im Weiteren mit OS ab.

Für Grundlagen zu grundsätzlichen Abläufen unter LUKS können Interessierte einen Blick in meine früheren Blog-Posts werfen; dort sind auch viele Links zu weiterführender Literatur im Internet angegeben:
dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – I
dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – II
Ich setze im späteren Verlauf dieser Serie ein grundlegendes Verständnis der Arbeitsweise von LUKS voraus. Die praktische Umsetzung von LUKS auf der Kommando-Ebene zeige ich natürlich (ausschnittsweise) im Zuge dieser Artikel-Serie.

Unterscheidung Vollverschlüsselung - Teilverschlüsselung

Wir unterscheiden im Folgenden zwischen Voll- und Teil-Verschlüsselung. Unter einer Voll-Verschlüsselung verstehe ich dabei einen Ansatz, in dem

  • sowohl das Volume für das OS, mit dem auf die zu schützenden Daten zugegriffen wird,
  • als auch separate Volumes zur Lagerung der zu schützenden Daten,
  • als auch Swap-Volumes

verschlüsselt werden. Bei Abweichungen spreche ich von Teil-Verschlüsselung.

Teilverschlüsselung - Datencontainer und/oder ausschließliche Verschlüsselung von separaten Partitionen/Volumes für Daten?

Viele Leute (auch IT-Profis) wählen zum "Schutz" ihrer Daten den "bequemen" Ansatz, diese in verschlüsselten Containern (Files) oder Partitionen/Volumes zu hinterlegen. Sehr beliebt ist unter Linux und Windows etwa der Einsatz von VeraCrypt. Dabei operiert das OS selbst auf einem unverschlüsselten Volume, weil sich die Anwender (z.T. aus guten Gründen) an eine Voll-Verschlüsselung nicht herantrauen. So kenne ich etwa mehrere Leute, die unter Windows ihre Daten in verschlüsselten Krypto-Containern auf der Systemplatte ablegen und meinen, nun seien die Daten bei einem Verlust oder Diebstahl des Laptops sicher. Das ist ein Irrtum (nicht nur wegen MS Windows 🙂 ). Die Gründe lassen sich u.a. mit folgenden Stichworten charakterisieren:

  • Pufferung von Daten/Dateien durch das Betriebssystem und Anwendungen in "temporären" Verzeichnissen/Dateien/Datenbanken sowie anwendungsspezifische Backup-Dateien.
  • Dateianalysatoren und Indexer für schlagwortbasierte Suchverfahren, die ggf. automatisch ganze Verzeichnisbäume und deren Inhalte durchforsten und Ergebnisse in Datenbanken hinterlegen.

Durch solche Verfahren landen Daten oder Datenfragmente bei der Bearbeitung von Dateien des Kryptocontainers (dekryptiert) auf dem unverschlüsselten (!) Filesystem des Betriebssystems [OS].

Zur Bearbeitung muss man die Dateien ja öffnen und ihren Inhalt entschlüsseln. Mindestens im RAM liegen die Daten dann im Klartext vor. Würden das OS oder die aktuelle Anwendung vom RAM immer nur auf den Krypto-Container zurückschreiben, wäre die Welt in Ordnung; das ist aber in vielen Anwendungen und Betriebssystemen nicht ohne besondere Einstellungen der Fall. Auch unter Linux landen Daten u.a. im /tmp-Verzeichnis, im home-Verzeichnis des Users oder gar im Swap. Hinzu kommen weitere anwendungsspezifische Orte im Filesystem. Kritisch in dieser Hinsicht sind etwa bestimmte Mail-Systeme. Siehe zur Thematik der Lagerung von Daten in ggf. unverschlüsselten Bereichen des Systems auch die unten angegebenen Links.

Das gleiche Thema haben wir, wenn wir nur bestimmte Partitionen/Volumes eines Linux-Laptops für die Aufnahme von Daten verschlüsseln würden - aber das OS auf einem unverschlüsselten Volume desselben Geräts betreiben würden. Hier fungiert dann gleich eine ganze Partition oder ein Volume als "Container". Es gilt aber auch für begrenzte "Container", die man mit LUKS etwa auf Basis von datei-basierten Loop-Devices aufbauen könnte (ja, sowas geht 🙂 ).

Analoges gilt aber auch bei Einsatz externer Krypto-Container - z.B. auf USB-Sticks oder USB-Platten: Die Daten sind dort nur genau so sicher, wie sie es auf dem Laptop oder der PC selbst wären, von denen aus man regelmäßig mit dem externen Container arbeitet. Gerade bei mobilen Leuten ist das also ein Thema. All diese Ansätze entsprechen in Zeiten der DSGVO sicher nicht dem Stand der Technik.

Erstes Fazit: Für eine sichere Datenhaltung kommen wir um eine Verschlüsselung der Volumes/Partitionen für das OS (root-Filesystem) sowie ggf. separate Datenvolumes sowie Swap-Bereiche nicht herum.

Teilverschlüsselung - das Problem mit SSDs

Man könnte bei HDDs noch wie folgt argumentieren: Wenn ich alle Bereiche und Dateien kenne, die das System oder Anwendungen zur Pufferung, Backups, Indizierung etc. nutzen, könnte ich diese Bereiche regelmäßig löschen und mit Nullen oder Zufallsdaten überschreiben. Das funktioniert leider nicht bei SSDs, die heute in die meisten Laptops eingebaut sind. Die oben diskutierte Thematik schlägt dann voll zu:

SSD-Controller verteilen ankommende Daten zur Begrenzung von Ausfällen z.T. in mehrfacher Kopie auf verschiedene Speicherelemente; das Stichwort ist hier "Wear-Leveling". Das geschieht für den Anwender transparent im Hintergrund. Ohne Spezialwerkzeuge hat man als normaler User keinen Zugriff auf diese Storage-Bereiche. Selbst wenn man alle Systembereiche für Pufferung etc. kennt und mit zufälligen Daten überschreibt - es blieben unverschlüsselte Reste auf der SSD erhalten. An die kommen Hacker, die physikalischen Zugriff auf die SSD haben, im Zweifelsfall aber mit Spezialwerkzeugen heran. Einer der Entwickler von Veracrypt lehnt deshalb grundsätzlich vom Einsatz von SSDs auf Hochsicherheitssystemen ab. Siehe hierzu:
https://sourceforge.net/p/veracrypt/discussion/technical/thread/9cd45bb3/
https://www.veracrypt.fr/en/Security%20Requirements%20and%20Precautions.html
https://www.veracrypt.fr/en/Wear-Leveling.html

Das bedeutet:

Keine schützenswerten Daten dürfen den internen SSD-Controller je unverschlüsselt erreichen.

LUKS und auch Veracrypt sorgen dafür, dass genau das bei der Interaktion mit einem Storage-System passiert. Setzt man SSDs ein, so müssen also alle genutzten Partitionen, auf denen man schützenswerte Daten hält und auf denen ggf. unverschlüsselte Kopien oder Fragmente landen könnten, verschlüsselt werden. Allein hieraus ergibt sich eine Voll-Verschlüsselung für den Linux-Betrieb auf SSDs.

Das bedeutet aus meiner Sicht nicht zwingend, dass die komplette jungfräuliche SSD verschlüsselt werden muss. Aber mit OS-Installationen auf unverschlüsselten Partitionen darf man später NICHTS (!) Geheimhaltungswürdiges anfassen. Das ist in der Praxis gar nicht so einfach - und verlangt erhebliche Selbstdisziplin. Wer sicher gehen will, wird daher entweder die gesamte SSD oder zumindest alle OS-, Daten- und Swap-Partitionen, auf und mit denen regulär gearbeitet wird, verschlüsseln.

SSDs werfen übrigens noch ein zweites Problem im Zusammenhang mit Verschlüsselung auf: das des sog. Trimmens (fstrim-Kommando). Darauf komme ich in einem späteren Blog-Artikel zurück.

Teilverschlüsselung - das Hibernation-Problem

Vor allem im Fall von Laptops muss man sich auch mit dem Thema "Hibernation" auseinandersetzen. Beim Übergang in den maximal stromsparenden Zustand werden aktuelle RAM-Inhalte auf die Platte geschrieben (unter Linux evtl. in den SWAP-Bereich). Nach dem Öffnen eines Krypto-Devices wird im RAM aber auch der sog. "Master-Key" für das symmetrische Verfahren zur Datenverschlüsselung vorrätig gehalten. Das ist nicht nur bei LUKS so! Der Master-Key würde im Hibernation-Vorgang also auf der Platte landen ...

Auch das ist ein Grund dafür, auf Laptops alle Volumes/Partitionen die vom OS genutzt werden, zu verschlüsseln. Ein Angreifer könnte etwa einen Laptop in die Hände bekommen, der sich schon in einem Hibernation-Zustand befindet oder ihn nach gewisser Zeit erreichen wird. Der typische Fall für Freelancer ist der Verlust beim Umstieg zwischen zwei Zügen. Oder der gezielte Diebstahl in der Mittagspause.

Man sollte sich für seine Distribution in jedem Fall darum kümmern, was als Platz für Hibernation genutzt wird. Natürlicherweise bietet sich der SWAP an. Auch unter Opensuse Leap ist das der Fall. Der Swap-Space muss auf einem Laptop mit Hibernation deshalb auch eine hinreichende Größe (> RAM) haben. Siehe:
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.power-mgmt.html
Unter Suse müssten wir auf einem System mit aktiviertem Hibernation also unbedingt den SWAP-Space verschlüsseln.

Es gibt übrigens ein ganz ähnliches Problem im Zusammenhang mit Virtualisierung. Dort kann man Gastsysteme in einen "Saved"-Zustand überführen, in dem auch der RAM der virtuellen Maschine in einem vorgegebenen Verzeichnis-Bereich des OS - also ggf. auf einem unverschlüsselten Bereich des Systems gespeichert wird. Aber genug für heute ...

Zwischenfazit

Erste einfache Überlegungen sprechen gegen eine Teil-Verschlüsselung von (mobilen) Systemen, die Sicherheit geheim zu haltender Daten auf dem Stand der Technik garantieren sollen. Im nächsten Beitrag

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung

stellen wir Überlegungen zur Verschlüsselung virtualisierter Systeme an.

Links zum Thema "Warum Voll-Verschlüsselung?"

https://en.opensuse.org/SDB:Encrypted_root_file_system
https://wiki.archlinux.org/index.php/Disk_encryption

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