Die folgende Grafik bietet diesen Vergleich und wird täglich aktualisiert. Als Quellen dienen die zur Verfügung gestellten Daten des Impfdashboards. Sie ist auch im Bereich covid19-plots hinterlegt.
Das Ergebnis ist sehr unerfreulich, es sind eindeutig zu viele Krankenkassen die Homöopathische “Behandlungen” bezahlen. Am dreistesten ist sicherlich die HKK, welche es unter den Namen Naturarzneimittel in ihrem Katalog aufführt.
Wählt weise!
Die folgende Grafik bietet diesen Vergleich und wird täglich aktualisiert. Als Quellen dienen die zur Verfügung gestellten Daten des Impfdashboards. Sie ist auch im Bereich covid19-plots hinterlegt.
Objekt = id, timestamp, {value}, description
id = ? int64 ?
timestamp = ? int32 ?
value = float
description = {Character}
Character = ? printable ascii characters ?
Als Kompressionsalgorithmen kommen zlib, zstd, lz4 und lzo in Frage. bz2 und lzma reduzieren den benötigten Platzbedarf zwar am meisten, sind aber auch erheblich langsamer als der Rest. Die benötigte Zeit ist das ausschlaggebende Kriterium. Da mich das Verhalten im Zusammenspiel mit Python3 interessiert wurden die Vergleiche auch mit Python3 (3.9.1) durchgeführt. Dabei wurden folgende externe Module verwendet:
Die Module zlib, bz2 und lzma sind teil der Standardbibliothek.
Die folgende Grafik zeigt die benötigte Zeit (Millisekunden), um ein Objekt einzeln und innerhalb einer Liste zu komprimieren.
Hier wird die Größe in Byte nach der Kompression gezeigt. None ist die Größe der Quelldaten.
Nachfolgende Plots zeigen die aufsummierte Zeit und Datenmenge, wenn 100.000 Objekte einzeln komprimiert werden und zusammen als liste.
Zum Schluss wird noch die benötigte Zeit für die Dekompression der Daten verglichen.
Pickle arbeitet sehr schnell und legt die serialisierten Daten effizient ab. Wenn 100K Objekte in einer Liste verpackt werden, benötigen diese nur 1/3 des Speicherplatzes, als wenn jedes Objekt einzeln serialisiert wird.
Einzelne Objekte (Events) zu komprimieren und sie im Anschluss zu übertragen scheint ineffizient zu sein, der eingesparte Speicherplatz für diese kleinen Objekte ist einfach zu gering. Bei größeren Objekten könnte eine Kompression wieder wieder sinnvoll sein. Man könnte größere Objekte soweit Komprimieren, dass sie in ein einzelnes TCP/UDP-Segment passen.
zlib ist einfach zu langsam, auch mit dem niedrigstem Kompressionslevel (zlib_1). zstd eignet sich überhaupt nicht um kleine Datenmengen zu komprimieren, schneidet aber bei größeren Datenmengen hervorragend ab. zstd reduziert den benötigten Speicherplatz am besten, benötigt zur Kompression aber mehr Zeit als lzo und lz4, ist jedoch bei der Dekompression nur minimal langsamer als diese beiden sehr schnellen Algorithmen. zstd wäre damit der beste Kandidat um komplette Warteschlangen zu komprimiert zu übertragen.
Soll eine Kompression von einzelnen Events erfolgen, ist lz4 der favorisierte Kandidat. Er komprimiert und dekomprimiert einfach am schnellsten.
Update
[26.03.2021] Seit heute ist im Google-Playstore die Berechtigung für den Standortzugriff ausgewiesen (Version 1.4.12). Wenn man die App allerdings installiert, existiert diese Berechtigung nicht. Damit ist die App immernoch nicht in der Lage einen automatischen Checkout vorzunehmen.
[21.04.2021] Seit dem 26.03.2021 Hat sich am Zustand der App nichts geändert.
Mecklenburg-Vorpommern ist das erste Bundesland das eine Betreiberlizenz für die LUCA-App erworben hat. Es wird offensiv mit der Nutzung der App geworben. Der Preis dieser Lizenz ist unbekannt.
Ich beziehe mich im folgenden auf die Android-Version der LUCA-App.
Ich befürworte ausdrücklich die Nutzung von IT-Lösungen zum Zweck der Kontaktnachverfolgung. Die Corona-Warn-App ist ein gutes Beispiel für eine datenschutzfreundliche und offene Lösung, der Entwicklungsprozess ist komplett transparent und auch das zugrundeliegende Exposure Notification Framework von Google ist mittlerweile im Quellcode verfügbar. Zudem gibt es einen Google-freien Nachbau des Frameworks vom MicroG-Projekt und auch einen Fork der originalen Corona-Warn-App namens Corona Contact Tracing Germany , die das MicroG-Exposure-Framework verwendet. Der einzige Kritikpunkt an der Corona-Warn-App könnten die hohen Entwicklungskosten sein. Wie viel die Luca-Lizenzen in Summe kosten ist aber auch noch unklar. Aus Datenschutzgründen hat man sich im November 2020 entschieden, keine Kontaktnachverfolgung im Sinne der LUCA-App in die Corona-Warn-App zu integrieren, um nicht das Vertrauen in die App zu verspielen. Stattdessen nehmen wir einfach eine nicht überprüfte Software von einem Berliner Start-up?
Genau die oben beschriebenen Vorteile, die auch das Vertrauen in die Luca-App stärken würden, da unabhängige Experte sich den Code anschauen könnten und Verbesserungsvorschläge einreichen können, fehlen in der LUCA-App komplett. Stattdessen setzt man offensichtlich auf eine strikt proprietäre Lösung, die nicht einmal einen Audit durch externe Firmen erfahren hat. Zudem werden Lizenzverhandlungen hinter verschlossenen Türen durchgeführt.
Seit Montag, dem 01.03.2021, ist es Frisören in MV wieder erlaubt zu öffnen. Natürlich mit der Bitte die LUCA-App zu verwenden. Eine Frisörmeisterin aus Rostock hat im Lokalradio von ihren Erfahrungen mit der LUCA-App berichtet. Sinngemäß wurde die Möglichkeit gelobt im Betreiber-Modus einen Radius zu erstellen, aus dem man automatisch ausgecheckt wird: Ist ein Nutzer mit der LUCA-App im Frisörsalon eingecheckt und verlässt den voreingestellten Radius, wird er automatisch ausgecheckt. Für die Frisörmeisterin eine hervorragende Funktion, Kunden müssen sich somit nicht manuell auschecken.
Wie funktioniert das automatische Auschecken?
Ganz einfach: Die Position des Smartphones muss zu jedem Zeitpunkt bekannt sein. Kurz gesagt, die LUCA-App braucht Zugriff auf die Ortungsfunktionen des Smartphones. Ortungen mit metergenauer Auflösung könnte folgendermaßen durchgeführt werden:
Alle drei Verfahren benötigen aber Zugriff auf die Standortdaten des Android-Smartphones. Das automatische auschecken auf Basis von Standortdaten scheint optional zu sein, das wird aber im Betreiber-Modus, während der Eintragung eines Radius nicht erwähnt.
Zusätzlich existiert noch die Möglichkeit eine sehr grobe Standortbestimmung mittels IP-Adressen vorzunehmen. Dieses Verfahren ist aber für die metergenaue Bestimmung unbrauchbar und auch nicht zuverlässig. Je nach Qualität der Daten kann man lediglich die Region (z.B. Stadt) bestimmen in der man sich aufhält. Diese Bestimmung benötigt keine gesonderten Berechtigungen auf dem Smartphone.
Nur die FAQ auf der Homepage bietet eine kurze Bemerkung, aber nicht wie Geofencing in der LUCA-App umgesetzt ist.
Wie schon erwähnt, müsste die LUCA-App Zugriff auf die Standortdaten haben um überhaupt das metergenaue automatische Auschecken zu ermöglichen. Derzeit wird diese Funktion durch die Android-App (Version 1.4.9) überhaupt nicht angeboten. Die Berechtigungen der App im Play-Store gibt eindeutig Auskunft darüber:
Auch nach der Installation der App existiert keine Möglichkeit der Standortabfrage:
Wie soll metergenaues auschecken unter Android so möglich sein? Gar nicht!
Die iOS-Version der App (Version 1.3.1) scheint die Möglichkeit der Standortabfrage zu bieten.
Abseits großer datenschutzspezifischer Bedenken, dass ein Unternehmen somit in der Lage wäre Bewegungsdaten tausender Menschen zu erfassen, kann diese Funktion einfach nicht benutzt werden.
Das automatische Auschecken wird im Betreiber-Modus der LUCA-Web-App zentral beworben, kann aber nicht funktionieren. Wenn sich technisch nicht versierte Betreiber und Gäste auf diese Funktion verlassen, ist das in meinen Augen ein schwerer Fehler. Es kann sogar dazu führen das eigentlich unbeteiligte Betreiber in Quarantäne müssen und so eventuell ihren Geschäftsbetrieb einstellen oder einschränken müssen, da sich Gäste eigentlich woanders infiziert haben, aber nicht ausgecheckt waren. Das kann natürlich auch Gäste treffen die sich auf das automatische Auschecken verlassen und später eine Quarantäne Aufforderung bekommen, obwohl sie schon lange nicht mehr vor Ort waren.
Rücknahme der Geofencing-Funktionen aus Datenschutzgründen und aufgrund unvollständiger Unterstützung des eigenen Softwarestacks.
Klare und detaillierte Beschreibung der Architektur.
Audit des gesamten LUCA-Softwarestacks durch mindestens zwei unabhängige Unternehmen.
Veröffentlichung von Preislisten oder gezahlten Preise für Lizenzen.
Druck auf die Entwickler erhöhen, den Code (Apps + Server) zu publizieren (public money public code!).
Alle Grafiken werden stündlich aktualisiert, sofern neue Daten zur verfügung stehen.
Der Quellcode steht auf github zur Verfügung.
Folgender Plot zeigt den nach Bundesländern aufgeschlüsselten Impffortschritt an. Als Quelle dienen Daten vom Impfdashboard.
Folgender Plot basiert auf den Daten aus Pavel Meyers Covid-Risiko-Tabelle. Das erzeugende Skript kann beliebige Landkreise, Städte, oder Länder plotten und ist auf github veröffentlicht.
[11.06.2022] Neue Plots für die Zeiträume vom 15.10.2021 und 15.02.2022
[06.04.2021] Plot zum Verhältnis von gelieferten zu verimpften Dosen hinzugefügt.
[16.03.2021] Plot zum Pandemieverlauf hinzugefügt.
[11.02.2021] Es wird nach Erst- und Zweitimpfung unterschieden.
[19.01.2021] Umstrukturierung der RKI-Tabelle, inkompatibel zur vorherigen Version Es existiert jetzt eine Aufschlüsselung nach Impfpräparaten.
[04.01.2021] Das RKI stellt seit heute auch die Impfquote pro 1000 Einwohnern und die Gesamtanzahl der Impfungen der letzten Tage in ihrer Excel-Tabelle bereit.
Wireguard ist eine moderne VPN-Lösung mit einer sehr schmalen Codebasis. Wireguard implementiert nur wenige, dafür aber aktuelle Verschlüsselungsverfahren und läuft, anders als zum Beispiel OpenVPN, im Kontext des Kernels. Eine detaillierte Beschreibung des Protokolls und eine Übersicht über die verwendeten kryptografischen Verfahren kann man im Wireguard-whitepaper nachlesen. In den nächsten Monaten (stand März 2019) soll Wireguard Aufnahme in den Linux-Kernel finden. Für debian 10 testing und unstable/sid stehen aktuelle Pakete in den debian-repositories bereit. Die Installation auf allen gängigen Linux-Distributionen und BSD-Systemen ist auf der Wireguard-Homepage beschrieben. Als Transportprotokoll setzt Wireguard ausschließlich auf UDP, möchte man stattdessen TCP einsetzen (einziger Grund wäre eine Blockierung von UDP), muss man Wireguard zum Beispiel über WebSockets tunneln.
Da Wireguard ein Kernelmodul benötigt, muss das System zu dessen Übersetzung vorbereitet werden:
sudo apt-get install linux-headers-$(uname -r) build-essential
Für debian 9 stretch/stable existieren noch keine Pakete im offiziellen repository, daher muss das unstable-repository auf dem System verfügbar gemacht werden. Bei debian 10 kann dieser Schritt übersprungen werden. Dabei werden alle Pakete aus unstable jedoch so niedrig priorisiert, dass alle Pakete aus stable bei Updates den Vorzug erhalten, außer explizit installierten Paketen aus unstable:
$ sudo echo "deb http://deb.debian.org/debian/ unstable main" > /etc/apt/sources.list.d/unstable.list
$ sudo printf 'Package: *\nPin: release a=unstable\nPin-Priority: 90\n' > /etc/apt/preferences.d/limit-unstable
Im Anschluss wird Wireguard installiert und das Kernelmodul wird automatisch übersetzt und geladen:
$ sudo apt update && apt install wireguard
Ob das Kernelmodul geladen ist, lässt sich leicht überprüfen:
$ sudo lsmod | grep wireguard
Damit der VPN-Server IPv4 und IPv6 Pakete weiterleitet muss diese Funktionalität dem Kernel mitgeteilt werden:
$ sysctl net.ipv4.ip_forward=1
$ sysctl net.ipv6.conf.all.forwarding=1
Um diese Einstellungen auch nach einem Neustart zu setzen, sind folgende Zeilen zur Datei /etc/sysctl.d/99-sysctl.conf zu ergänzen:
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
Wireguard basiert auf dem Konzept des Crypto-Routing. Jeder Kommunikationsteilnehmer an einem VPN besitzt ein asymmetrisches Schlüsselpaar, der jeweilige öffentliche Schlüssel wird demjenigen Kommunikationspartner mitgeteilt, der über den Kommunikationskanal kommunizieren darf. Die Schlüssel sind sehr kurze base64-kodierte ECDH-Schlüssel. Die Schlüssel können auf jedem System, auf auf dem Wireguard verfügbar ist, generiert werden.
Schlüsselpaar für den VPN-Server:
$ wg genkey > vpn-server.seckey
$ wg pubkey < vpn-server.seckey > vpn-server.pubkey
Schlüsselpaar für einen weiteren Kommunikationsteilnehmer:
$ wg genkey > mobile.seckey
$ wg pubkey < mobile.seckey > mobile.pubkey
Optional ist die Generierung eines weiteren pre shared keys um eine weitere Schicht symmetrischer Verschlüsselung hinzuzufügen. Gründe hierfür werden in Abschnitt 5.2 des Wireguard-Whitepapers erläutert.
$ wg genpsk > vpn.psk
Es existieren zwei Möglichkeiten Wireguard zu betreiben, man kann mithilfe von wg einen Tunnel
etablieren und Kommunikationspartner (peers) hinzufügen. Alternativ dazu hat man die Möglichkeit eine Konfigurationsdatei zu erstellen,
welche später von wg-quick eingelesen wird. Die zweite Möglichkeit hat den Vorteil, dass sich wg-quick auch gleich um die Erstellung
und Konfiguration der Wireguard-Netzwerkschnittstelle (im Beispiel: wg0) kümmert. Zudem bringt das Debian-Paket auch gleich ein
Systemd-Interface-Template mit, was ein Start des VPNs erleichtert und keine zusätzlichen Systemd-Kenntnisse erfordert.
Bevor die Konfiguration von Wireguard erfolgen kann, noch einige Worte zur IP-Adresskonfiguration von Hetzner. IPv4-Adressen
werden durch Hetzner per DHCP vergeben, sind aber persistent. IPv6 Adressen werden stattdessen statisch konfiguriert, Hetzner
verwendet dazu auf ihren debian Cloud-Servern die debian networking-scripte. Die IP-Adresskonfiguration findet sich unter:
/etc/network/interfaces.d/50-cloud-init.cfg.
Exemplarisch sind folgende Adressen auf dem Interface eth0 konfiguriert:
IPv4: 203.0.113.1/32
IPv6: 2001:db8:ffff:ffff::1/64
Da Wireguard über das virtuelle Tunnelinterface wg0 kommuniziert, müssen, jeweils für IPv4 und IPv6, interne Tunnel-Netze und Adressen
vergeben werden. Für IPv4 wählt man ein privates Netz gemäß RFC1918, in diesem Beispiel verwenden wir 172.16.100.0/24. Dem VPN-Server
wird später die erste Adresse aus diesem Bereich zugewiesen.
Die Adressen aus diesem privaten IPv4-Bereich müssen später noch einer Adressumsetzung auf die öffentliche Adresse 203.0.113.1 unterzogen werden.
Bei IPv6 hingegen reicht es aus das öffentliche Netz 2001:db8:ffff:ffff::/64 zu segmentieren. Zum Beispiel kann man das Netz in
256 Subnetze unterteilen: 2001:db8:ffff:ffff::/72. Die IPv6-Adresse auf eth0 ändert sich dadurch nicht, lediglich die Netzgröße.
Daher muss diese in der Datei /etc/network/interfaces.d/50-cloud-init.cfg angepasst werden:
#address 2001:db8:ffff:ffff::1/64
address 2001:db8:ffff:ffff::1/72
Im Anschluss muss die Konfiguration neu eingelesen werden:
$ sudo systemctl restart networking.service
Das zweite Netz aus dem IPv6-Bereich (2001:db8:ffff:ffff:100:/72) wird für die internen Tunneladressen verwendet.
Die Konfigurationsdatei von Wireguard muss nach dem Wireguard-Interface benannt benannt werden: /etc/wireguard/wg0.conf.
In diesem Beispiel lauscht der Wireguard-VPN-Server auf dem Port upd/443 auf eth0. Lediglich die Schlüssel müssen noch ergänzt werden:
[Interface]
Address = 172.16.100.1/24
Address = 2001:db8:ffff:ffff:100::1/72
SaveConfig = true
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 443
PrivateKey = [vpn-server.seckey]
[Peer]
PublicKey = [mobile.pubkey]
PresharedKey = [vpn.psk]
AllowedIPs = 172.16.100.0/24, 2001:db8:ffff:ffff:100::/72
Wireguard kann nun mittels wg-quick gestartet werden:
$ sudo wg-quick up /etc/wireguard/wg0.conf
Sollte der VPN-Server ohne Probleme starten, kann man die Konfiguration mittels Systemd persistent machen:
$ sudo systemctl enable wg-quick@wg0
Die Teilnehmer am VPN-Netzwerk sollen DNS-Anfragen durch den Tunnel an den VPN-Server richten können. In diesem Beispiel wird dnsmasq verwendet, aber auch andere resolver wie unbound können verwendet werden.
Eine exemplarische Konfiguration für dnsmasq (/etc/dnsmasq.conf):
# Quad9 - Initiative https://www.quad9.net/
server=9.9.9.9
server=149.112.112.112
server=2620:fe::fe
server=2620:fe::9
listen-address=127.0.0.1,172.16.100.1
bind-interfaces
cache-size=1000
Neustart von dnsmasq:
$ systemctl restart dnsmasq.service
Damit DNS-Anfragen an dnsmasq gerichtet werden, müssen auf dem VPN-Server die Nameserver in der Datei /etc/resolv.conf
auf eine Loopbackadresse verweisen. Dazu wird in der Datei /etc/dhclient/dhclient.conf folgende Zeile auskommentiert:
#prepend domain-name-servers 127.0.0.1;
prepend domain-name-servers 127.0.0.1;
Im Anschluss muss die Konfiguration neu eingelesen werden:
$ sudo systemctl restart networking.service
Die Datei kann auf einem beliebigen System erstellt werden:
[Interface]
Address = 172.16.100.2/24, 2001:db8:ffff:ffff:100::2/72
PrivateKey = [mobile.seckey]
DNS = 172.16.100.1
[Peer]
PublicKey = [vpn-server.pubkey]
PresharedKey = [vpn.psk]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = 203.0.113.1:443
Diese Datei kann nun als QR-Code kodiert werden und mithilfe der Android-/IOS-App eingelesen werden
$ qrencode -t ansiutf8 < client.conf
services:
fingerprints
SHA256:
51:49:8D:68:E8:2E:94:67:33:26:88:D5:14:85:16:60:65:D2:8E:F8:01:48:37:1D:1D:0C:87:6D:B6:89:84:87
SHA1:
DE:C8:CC:B4:2F:E7:6F:7C:92:1F:5B:B3:53:58:A8:C2:D0:83:03:5B
services:
fingerprints
SHA256:
18:44:C1:49:24:32:82:C5:DC:11:C8:23:6E:9C:42:6A:AE:AC:9E:C8:D6:60:B0:4C:CA:19:7D:05:6A:A5:41:03
SHA1:
5D:E1:83:5F:DD:C9:BF:E4:1E:5D:59:86:57:8E:6D:2D:64:DE:F1:4E
Als Grunddokument dient folgender Aufbau, dass Paket ifthen stellt grundlegende Kontrollstrukturen, Vergleichsoperatoren und Schleifen zur Verfügung:
\documentclass[a4paper,10pt]{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage{ifthen}
\begin{document}
...
\end{document}
Man kann einfache Funktionen definieren, indem man neue Kommandos erzeugt. Im folgenden Beispiel wird ein Kommando mit zwei Pflichtargumenten erzeugt:
\newcommand{\distanz}[2]{Geben Sie die Distanz zwischen #1 und #2 an!\\\\}
Das Kommando kann auch noch nachträglich verändert werden:
\renewcommand{\distanz}[3]{Geben Sie die Distanz zwischen #1, #2 und #3 an!\\\\}
Eine einfache String-Variable wird ebenso angelegt und verändert:
\newcommand{\zielort}{Bonn}
\renewcommand{\zielort}{Berlin}
Die Funktion kann nun aufgerufen werden:
\distanz{Kiel}{Hannover}{\zielort}
Ausgabe
Geben Sie die Distanz zwischen Kiel, Hannover und Berlin an!
Ganzzahlvariablen (auch negativ) heißen in Latex counter und werden folgendermaßen deklariert und mit einem Wert versehen:
\newcounter{zaehler}
\setcounter{zaehler}{100}
Der Wert eines counters kann auch inkrementiert werden:
\stepcounter{zaehler} %zaehler++ -> 101
Das Addieren und Subtrahieren geht ebenso:
\addtocounter{zaehler}{10} %111
\addtocounter{zaehler}{-11} %100
Jetzt kommt das Paket ifthen zum Tragen. Es bietet eine if-then-else-Anweisung und eine while-Schleife. Die Gesamtdokumentation dieses Paketes findet man hier.
Um lesend auf eine Variable/einen counter zuzugreifen, z.B. für einen Vergleich, dient folgende Anweisung:
\value{zaehler}
Möchte man stattdessen den aktuellen Wert als Dezimalzahl ausgeben:
\arabic{zaehler}
Um die Anwendung der Schleife und der if-Kontrollstruktur zu verdeutlichen dient folgendes Beispiel:
\newcounter{i}
\setcounter{i}{100}
\whiledo{\value{i} > 0}{
\noindent Wie viele Flaschen Bier sind noch da?\\
\addtocounter{i}{-1}
Es sind noch \textbf{\arabic{i}} Flaschen Bier im Kühlschrank.\\\\
\ifthenelse{\value{i} = 0}{\textbf{Es ist kein Bier mehr Da!}}
}
Ausgabe
Wie viele Flaschen Bier sind noch da?
Es sind noch 99 Flaschen Bier im Kühlschrank.
Wie viele Flaschen Bier sind noch da?
Es sind noch 98 Flaschen Bier im Kühlschrank.
...
Wie viele Flaschen Bier sind noch da?
Es sind noch 0 Flaschen Bier im Kühlschrank.
Es ist kein Bier mehr Da!