Zum hauptinhalt springen

Coronapoint – eine Achterbahn der Software-Katastrophen 🎢

eine sehr gefährliche Achterbahn

Wir wissen mittlerweile, dass es kein Spaß ist, Testzentren anzuschauen. Diesmal war es aber besonders anstrengend: Ganze drei Mal mussten wir dem BSI Sicherheitslücken bei dem gleichen Unternehmen melden. Schnallt euch an für eine Achterbahnfahrt der Software-Katastrophen.


Los geht es mal wieder in NRW. Hier ist Coronapoint einer der größeren Anbieter für Schnelltests, aber insgesamt in 4 Bundesländern mit 34 Testzentren vertreten. Deshalb waren wir sehr schockiert, als Leo uns eine private Nachricht schickte und uns auf ein Problem bei diesem Anbieter hinwies1.

Wer sich bei Coronapoint testen lassen möchte, muss sich vorher registrieren – und erhält im Testzentrum dann ein Papp-Kärtchen mit einem QR-Code und einem Passwort. Mit diesem QR-Code kann man dann später ein PDF mit dem Testergebnis abrufen, welches mit dem Passwort verschlüsselt ist. Das klingt erstmal gar nicht so verkehrt, aaaaber…

Du hast kein Passwort? Nimm dieses!

Problematisch wird es, wenn man dieses Passwort verbummelt hat. Im Registrierungsformular gibt es nämlich einen Button, um sich das Passwort erneut zusenden zu lassen. Klickt man den Button auf der Webseite, wird im Hintergrund die entsprechende Anfrage an den Server gestellt.

Normalerweise antwortet ein Server auf so eine Anfrage lediglich mit einer kurzen Erfolgsmeldung: “Yay, Problem verstanden, du bekommst eine Mail”. Der Server von Coronapoint ist hier leider etwas gesprächiger und beschreibt sehr ausführlich, was im Hintergrund passiert. Dabei erzählt er auch fröhlich den Inhalt der verschickten Mail – inklusive dem Passwort.

Log vom Mailversand, inklusive der Passwörter

Das bedeutet, man benötigt gar keinen Zugriff auf den E-Mail-Account, um das Passwort zu bekommen. Es reicht, die E-Mail-Adresse zu kennen, diese in das Formular einzutragen und dann zuzuschauen, was der Server an den Mail-Account schickt.

Unser Selbstversuch: Mitten rein ins Geschehen

Ein banaler Fehler, mit dem wir an die Passwörter für die PDFs kommen. Doch ohne die Dokumente nutzt uns das herzlich wenig. Also Glück gehabt? Nicht unbedingt: Wo so ein simpler Fehler passiert, ist vielleicht noch mehr kaputt, haben wir uns gedacht – und uns selbst bei Coronapoint für einen Test-Termin registriert.

Und uns wird klar: Unsere Fahrt hat gerade erst wirklich angefangen.

Wenn wir das Registrierungsformular für einen Test-Termin online ausfüllen, werden wir auch gefragt, ob wir das Ergebnis zusätzlich in der offiziellen Corona-Warn-App (CWA) erhalten wollen.
In der Corona-Warn-App kann man sich über das eigene Testergebnis informieren lassen. Falls der Test positiv ist, können die eigenen Kontakte so auch möglichst schnell gewarnt werden.

Das klingt nach einer sinnvollen Idee und natürlich sind wir neugierig, wie dieses Feature technisch umgesetzt wurde. Wir klicken also begeistert auf “Ja”. Sobald die Registrierung abgeschlossen ist, bekommen wir auch gleich den passenden QR-Code, um den Test in die CWA zu importieren.

Screenshot des QR-Codes für die CWA auf der Buchungsbestätigungs-Seite

Doch wie wird eigentlich der QR-Code generiert? Ein Rechtsklick verrät uns mehr:
In dem Auswahlmenü sehen wir die Option “Grafikadresse kopieren”. Der QR-Code ist eine Bilddatei, die sich unter https://e.coronapoint.de/cwa/qrcodes/{Buchungsnnummer}.png abrufen lässt.

Wie bei einer echten Achterbahnfahrt bekommen wir wieder ein flaues Gefühl im Magen, denn die Buchungsnummer ist nur eine einfache, aufsteigende Zahl. Und wie es schon bei Medicus und anderen der Fall war, lassen sich solche Zahlen einfach herunterzählen.

QR-Codes für alle

Und leider hat unser Bauchgefühl wieder recht, denn nach nur zwei Versuchen landen wir auf dem QR-Code einer anderen Person. Der Puls steigt, denn schlimmstenfalls haben wir damit Zugriff auf eine ganze Menge fremder Codes. Nach kurzem automatisiertem Abfragen wissen wir, dass tatsächlich der Zugriff auf mehr als 88.000 QR-Codes der letzten 20 Tage möglich ist.

Doch es geht wieder bergauf, die Architektur der CWA rettet für einen Moment unsere Laune: Beim Design der CWA wurde der Verlust von QR-Codes anscheinend mitgedacht. Jeder QR-Code kann nur einmal in die App importiert werden – und auch nur auf einem einzigen Gerät.

Die CWA ist vermutlich einer der sichersten Wege, ein Testergebnis abzurufen.

Bei der Architektur wurden sich durchaus Gedanken gemacht, auch um Sicherheit und Datensparsamkeit und so ist auch keine der Lücken, die wir gefunden haben in der CWA selbst.

Trotzdem können Testzentren, die das Ergebnis in der CWA bereitstellen, immernoch grobe Sicherheitslücken haben.

Jeder Höhepunkt in einer Achterbahn verspricht aber auch eine Abfahrt: Denn die QR-Codes können noch mehr Daten enthalten als nur ein Test-Hash. Die CWA unterscheidet zwischen namentlichen und anonymen Tests. Bei namentlichen Tests werden neben dem Hash auch eine Test-ID, Vorname, Nachname und Geburtsdatum im QR-Code hinterlegt.

Von den mehr als 88.000 QR-Codes, welche uns offen zugänglich waren, waren mehr als 53.000 für namentliche Tests – und enthielten somit persönliche Daten.

Das Feld testid ist in allen namentlich QR-Codes enthalten, darin steht eine UUID2, also ein langer, zufälliger Wert – und nicht einfach nur eine aufsteigende Zahl.

Auf ins Testzentrum

Unsere Experimente zur Registrierung am Rechner mit all ihren Höhen und Tiefen müssen wir jetzt aber erstmal beenden. Es wird nämlich Zeit, dass wir uns auf den Weg zum Testzentrum zu unserem Termin machen.

Dort bekommen wir ein kleines Papp-Kärtchen, mit einem aufgedruckten QR-Code. Das ist aber nicht der gleiche wie für die CWA. Dieser QR-Code enthält einen Link zu https://e.coronapoint.de/result.php?testid={Buchungsnummer}&uuid={UUID}, dort soll später unser Testergebnis liegen.

Foto des Pappkärtchens

Was uns dabei auffällt: Die testid ist die gleiche wie die aufsteigende Nummer aus der Registrierung. Und die uuid entspricht der UUID, die wir gerade eben schon im CWA-QR-Code finden konnten (dort verwirrenderweise als test_id hinterlegt). Wir scannen den QR-Code und kommen über einen Link zum Testergebnis. Dort werden wir zwar nach einem Geburtsdatum gefragt, aber das ist ja praktischerweise im CWA-QR-Code enthalten.

Screenshot des Formulars zur Eingabe des Geburtsdatums

Nach der Eingabe des Geburtsdatums erhalten wir nun das PDF mit dem Ergebnis. Doch die Talfahrt nimmt ein Ende und wir können Aufatmen: Das PDF ist mit einem Passwort verschlüsselt. Nur um kurz darauf festzustellen: Upps, wir hängen kopfüber in einem Looping!

Denn das Passwort, das wir benötigen, ist genau jenes, welches wir ganz am Anfang mit Hilfe der E-Mail-Adresse abfragen konnten.

Erster Gedanke: Puh, wir haben ja die E-Mail-Adressen nicht, die wir eingeben müssten, um das Passwort “zurücksetzen” zu können.

Zweiter Gedanke: Wir wissen mittlerweile, dass die Passwörter nur 4 Zeichen lang sind und nur aus den Zeichen 0123456789ABCDEF bestehen. Selbst ein alter Laptop kann die 65.536 möglichen Kombinationen in Sekundenbruchteilen durchprobieren.

Et voilà: personenbezogene Daten

Und dann können wir erstmal gar nicht mehr denken, sondern stürzen in die Tiefe: Wir können mehrere zehntausende Testergebnis-PDFs mit persönlichen Daten herunterladen und entschlüsseln.

Auch nach unserem Hinweis, dass 4-stellige Passwörter nicht mehr zeitgemäß sind3, änderte Coronapoint an dieser Praxis nichts, obwohl solche Gesundheitsdaten wirksam verschlüsselt gespeichert werden müssen.

Uns ist schon ziemlich schlecht, und wir wollen eigentlich nur noch aus dieser Achterbahn aussteigen und nie, nie wieder mitfahren.

Die nächste Runde geht rückwärts: »Neuen Termin buchen«

Erholung wird uns aber nicht gegönnt: Etwa 20 Minuten nach dem Test erhalten wir eine E-Mail mit dem Ergebnis und einem Link, um einen neuen Termin zu vereinbaren. Dabei hatten wir uns doch gerade eben geschworen, nie wieder mit dieser Achterbahn zu fahren. Na gut, einmal vielleicht noch…

Der Link in der Mail soll eine weitere Buchung vereinfachen, indem die persönlichen Daten im Formular bereits vorausgefüllt werden.

Wir klicken also und landen auf einer normalen Buchungsseite, allerdings stehen in der URL zwei zusätzliche Angaben: bookingsid und uuid. Der ganze Link sieht damit so aus: https://e.coronapoint.de/buchung/?product=Antigen-KL&bookingsid={Buchungsnummer}&uuid={UUID}

Die Buchungsnummer kennen wir ja schon (das war der Dateiname des CWA-Codes) und die UUID kennen wir auch (ist im CWA-Code gespeichert). Wir können sie hier also einfügen.

Im Quellcode der Webseite finden wir auch alle Daten, die wir bei der Buchung angegeben haben. Die werden auch im nächsten Schritt des Buchungsprozesses hübsch auf der Webseite angezeigt.

Buchungsseite mit vorausgefülltem Formular voller persönlicher Daten

Dabei geht es um folgende Daten:

  • Geschlecht
  • Name
  • Adresse, PLZ, Ort
  • Telefonnummer
  • E-Mail
  • Geburtsdatum
  • Ausweis-Nr. (falls angegeben)

Und das schön maschinenlesbar, ohne ein PDF entschlüsseln und einlesen zu müssen. Wenn wir also die Informationen aus dem QR-Code für die CWA haben, kommen wir an personenbezogene Daten. Diese Runde Achterbahn ging also noch schneller – was aber auch bedeutet, dass uns jetzt noch schlechter ist. 🤢

Ein großer Haufen PDFs

Während wir uns die Seite näher anschauen, finden wir diese Zeile im Quellcode:

Screenshot des Quelltext in dem eine URL zusammengebaut wird

Dort wird ein Link zusammengebaut, der wie folgt aussieht: https://e.coronapoint.de/pdfs/results/result_{Buchungsnummer}.pdf

Als wir diese URL mit unserer Buchungsnummer aufrufen, entgleisen uns alle Gesichtszüge 4.

Zur Erinnerung: Die Buchungsnummer war die Nummer, die einfach aufsteigend war. Eine zusätzliche UUID aus den CWA-QR-Codes ist also gar nicht nötig, was nicht nur einen zusätzlichen Angriffsvektor bietet, sondern die Abfrage der Ergebnisse auch noch einfacher macht.

Looping um Looping wird uns übler

Einmal automatisch alle Zahlen aufsteigend durchprobiert, waren dort mehr als 140.000 Testergebnisse abrufbar. Zwar waren auch diese PDFs passwortgeschützt, aber einen wirklichen Schutz bietet das wie oben beschrieben nicht.

Zweimal durch den Looping durch und kein Ende in Sicht: Mittlerweile haben wir Zugriff auf 140.000 Testergebnis-PDFs. Doch was steht in denen überhaupt drin? Eine ganze Menge, nämlich

  • Geschlecht
  • Name
  • Adresse, PLZ, Ort
  • Telefonnummer
  • E-Mail
  • Geburtsdatum
  • Ausweis-Nr. (falls angegeben)
  • Test-Name, Hersteller
  • Test-Datum, Uhrzeit
  • Testende Person (Name)
  • Testergebnis
Screenshot des Testergebnis PDF

Interessantes Detail am Rande: Zwar ist das Ausweisnummer-Feld im Registierungsformular optional, aber kaum als solches zu erkennen. Daher finden sich vermutlich sehr viele Ausweisnummern in den Daten.

»Hallo BSI, zerforschung hier«

Wie immer, wenn wir solche Lücken finden, erstellen wir einen Aufschrieb der Lücke und schicken ihn an die zuständigen Stellen, in diesem Fall das CERT-Bund beim BSI sowie die Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LfDI NRW).

Das CERT-Bund hat dann Coronapoint informiert und schon wenige Stunden später bekamen wir eine Rückmeldung:
Coronapoint behauptet, die Lücken geschlossen zu haben.

Normalerweise endet hier unsere Fahrt mit dem Fazit: Hat durchgerüttelt, war anstrengend – und wir sind erleichtert, dass es vorbei ist.

Meistens bekommen es die Unternehmen nämlich hin, ihre Lücken zu fixen und wir können kurze Zeit später unseren Bericht veröffentlichen.

Meistens…

Und noch mehr Testergebnisse

Weil wir vor der Veröffentlichung immer sicher gehen wollen, dass die Lücken auch wirklich geschlossen sind, um keine persönlichen Daten zu gefährden, schauen wir selber besser nochmal nach:

Laut Coronapoint werden die Dateien jetzt nicht mehr unter der Buchungsnummer, sondern unter einer UUID gespeichert, also einer langen, zufälligen Zeichenketten, die wir nicht einfach hochzählen oder erraten können.

Wir haben den Report erhalten – Dann behebt ihr die Lücke, Richtig? – … – Dann behebt ihr die Lücke, Richtig?

Doch wir können immer noch problemlos unseren QR-Code und das PDF abrufen. Hört diese Fahrt denn nie auf?

Immerhin: Wenn wir uns aber erneut für einen Test registrieren, wird der QR-Code nicht wieder unter der Buchungsnummer gespeichert, sondern tatsächlich unter einer UUID.

Nix gelernt?!

Also packen wir wieder unser kleines Programm aus und probieren systematisch Buchungsnummern nach dem alten Schema durch.

Dabei stellen wir fest: Wir können keine QR-Codes finden, die nach 9:45 Uhr erstellt wurden. Allerdings sind die QR-Codes bis 9:45 Uhr immer noch abrufbar. Coronapoint hatte also zwar die Speicherung für neue QR-Codes umgestellt, aber die alten Dateien einfach liegen lassen? 🤯

Bei den Ergebnis-PDFs sieht es sogar noch schlimmer aus: Hier können wir nicht nur PDFs herunterladen, die nach 9:45 Uhr erstellt wurden, nein: Es kam sogar alle paar Sekunden ein neues PDF dazu. Hier hatte Coronapoint also einfach gar nichts geändert.

Davon sind wir doch reichlich entsetzt, und melden dem CERT-Bund zurück, dass die Lücken nur unzureichend bzw. gar nicht behoben wurden.

Auch darauf kam relativ schnell eine Antwort: Diese Lücken seien nun endgültig behoben. Und tatsächlich waren keine PDFs mehr nach diesem Schema abrufbar.

Liebe Leute, so geht’s nicht!

Dieses widerwillige, verzögerte Handeln hat dazu geführt, dass weitere Daten gefährdet wurden: In der Zeit zwischen unserer ersten Meldung und dem endgültigen Beheben wurden mindestens 6.000 Testergebnis-PDFs zusätzlich abrufbar gemacht.

Wir nehmen uns bei unseren Reports viel Zeit und geben uns Mühe, diese klar und verständlich zu schreiben, damit die Probleme von den betroffenen Unternehmen möglichst schnell nachvollzogen, verstanden und behoben werden können. Wir hatten beinahe den Eindruck, als ob Coronapoint unsere Reports nicht zu Ende gelesen hat.

Wer sich dann so verhält, hat entweder keine Ahnung oder macht diese Fehler bewusst. Beides ein sehr guter Grund, keine Software zu betreiben, die Kund*innen-Daten speichert, insbesondere wenn es um besonders schützenswerte Gesundheitsdaten geht.

Die Buchungsbestätigungen liegen einen Raum weiter, Tür ist offen

Während wir uns wütend an die Stirn schlagen, rasen wir immer noch durch die Achterbahn. Mittendrin aussteigen geht ja leider auch nicht.

Natürlich haben wir noch weiter geschaut, ob wirklich alle Datenlücken geschlossen wurden.
Und mussten feststellen: Das war nicht der Fall. Die Daten aus den QR-Codes, die man braucht, um über die “Neuen Termin buchen”-Funktion fremde Daten abzurufen, waren weiter gültig.

Zwar können die QR-Codes jetzt nicht mehr einfach neu abgerufen werden, wer die zehntausenden QR-Codes aber bereits abgerufen hat, kann sich darüber weiter Zugriff auf die dazugehörigen Datensätze verschaffen.

Da Coronapoint nicht ausschließen kann, dass jemand die QR-Codes abgerufen hat und damit Unfug treiben wird, müssten sie diese Daten eigentlich ungültig machen, um weiteren Schaden zu verhindern.

Oh, noch mehr PDFs

Wir saßen gerade an einer E-Mail ans CERT-Bund, um nochmal auf dieses Problem aufmerksam zu machen, da kam uns eine Idee:

Wenn alle Testergebnisse unter https://e.coronapoint.de/pdfs/results/ liegen, sind dann die Buchungsbestätigungen vielleicht ähnlich zu finden?
Bingo! Wir müssen nicht einmal lange suchen: Unter https://e.coronapoint.de/pdfs/bookings/{Buchungsnummer}.pdf liegen die Buchungsbestätigungen. Wieder war nur die leicht zu erratende aufsteigende Buchungsnummer zum Abruf der Daten nötig. Als wir die Lücke entdeckten, waren es mehr als 34.000 Buchungsbestätigungen aus den letzten 3 Tagen.

Und auch diese Daten haben es in sich: Zwar war hier kein Testergebnis abrufbar, aber alle anderen Daten:

  • Geschlecht
  • Name
  • Adresse, PLZ, Ort
  • Telefon
  • E-Mail
  • Geburtsdatum
  • Ausweis-Nr. (falls angegeben)
  • Testdatum/-Uhrzeit
Screenshot der Buchungsbestätigung

An dieser Stelle müssen wir uns wirklich zusammenreißen, nicht zu schreien. Es geht rasant in die Tiefe: Diese Lücke ist quasi identisch zu der bereits gemeldeten. Das zeugt schon von Unkenntnis über den eigenen Code und das eigene System. Wenn wir melden, dass in dem einen Ordner Dateien öffentlich zugänglich liegen, wird dieser Fehler geschlossen. Na gut. Aber wie kann es sein, dass dabei niemand bemerkt, dass der Ordner nebenan auch öffentlich zugänglich ist?

Das ist, als würden wir Bescheid geben, dass das linke Vorderrad der Achterbahn fehlt. Und als Reaktion wird dieses Rad angeschraubt, aber dass auch das rechte Vorderrad fehlt, scheint niemandem aufzufallen oder wird mit einem Schulterzucken einfach so hingenommen.

Fazit: Fix und fertig

Nach der dritten Runde ist uns endgültig übel: Es ist einfach krass unverantwortlich, wie Testzentren immer und immer wieder fahrlässig mit unseren Daten umgehen.

Auch die Betroffenen hat Coronapoint bisher nicht informiert, dabei sind ihnen diese Lücken seit über einer Woche bekannt.

Wir finden das ist das Mindeste, was eine Firma nach einem Leck solch privater Daten machen sollte und auch die Landesdatenschutzbeauftrage von Berlin riet in einem ähnlichen Fall dringend, alle Betroffenen zu informieren.


Falls ihr nachfragen wollt, ob ihr betroffen seid, erreicht ihr Coronapoint unter:

02173 9938235 (Mo. - Fr. 8 - 18 Uhr, Sa. 10 - 18 Uhr, So. u. Feiertags 10 - 16 Uhr)
oder per E-Mail unter info@coronapoint.de.

Coronapoint ist jetzt die fünfte5 (!) Testzentrensoftware, aus der wir ohne großen Aufwand persönliche Daten in großen Mengen abrufen konnten.

Dabei sind wir auch nicht die einzigen, denen das auffällt und die auf die massiven Probleme hinweisen. Es gibt zahlreiche weitere Fälle, in denen die persönlichen Daten von Testzentren nicht geschützt waren. Noch sehr viel mehr Testzentren haben eine unzureichende Datenschutzerklärung.

Aus unserer Sicht darf das nicht sein, dass sich die Mehrheit der Testzentren nicht an Gesetze halten – und dass das von Ehrenamtlichen aufgedeckt werden muss, weil in den zuständigen öffentlichen Stellen die Ressourcen fehlen, um dies zu kontrollieren. Denn Datenschutzbehörden könnten vorschreiben, wie eine Datenerhebung und -verarbeitung zu erfolgen hat und bei Verstößen “eine vorübergehende oder endgültige Beschränkung der Verarbeitung, einschließlich eines Verbots, […] verhängen” (Art 58, 2f, DSGVO).

Mehr Ressourcen für die Datenschutzbehörden!

Alleine im Land Berlin gibt es 1.300 Teststellen, die durch die Landesdatenschutz-Behörde kontrolliert werden sollten. Laut Organigramm ist für Gesundheitsdaten eine einzige Person zuständig. Die Landesdatenschutzbeauftragten brauchen hier deutlich mehr Personal, um ihre Aufgaben überhaupt angemessen erfüllen zu können.

Denn wo Kontrollen fehlen, gibt es auch keine Konsequenzen und so scheint der Datenschutz auch die Betreiber der Testzentren nicht zu interessieren.

Die DSGVO verlangt, dass immer eine Datenschutzfolgenabschätzung (DSFA) geschrieben werden muss, wo Gesundheitsdaten verarbeitet werden – darunter fallen ganz klar Testzentren (Art 35, 3b DSGVO).

Wir finden, dass diese Datenschutzfolgenabschätzung schon im Rahmen der “Beauftragung” der Testzentren eingereicht und überprüft werden sollte. Dies würde immerhin dazu führen, dass die Betreibenden sich wenigstens einmal mit dem Thema Datenschutz grob auseinander gesetzt haben müssen.

Wir verweisen hier noch einmal auf die Empfehlungen des Landesbeauftragten für Datenschutz und Informationsfreiheit Baden-Württemberg, was Testzentren-Betreibende beachten müssen und seine deutliche Einordnung:

Wir müssen gerade in dieser Phase der Pandemie sorgsam mit den personenbezogenen Daten der Bürger_innen umgehen. Es darf keine ‚Nebenwirkung‘ von Corona-Tests sein, dass persönliche und sensible Daten von vielen Menschen irgendwo im Internet landen und für Dritte einsehbar sind.

Wer für so sensible Infrastruktur verantwortlich ist, wie es aktuell Testzentren sind, muss sich um deren Sicherheit kümmern. Ob die Betreiber ihren Pflichten nachkommen, muss sachlich geprüft werden – das ist wichtiger als Pressefotos mit Karl Lauterbach und Rainer Wendt!

Disclosure Timeline

  • 2021-06-11: Leo kontaktiert uns
  • 2021-06-14 01 Uhr morgens: Wir melden die Lücken an CERT-Bund und LfDI NRW
  • 2021-06-14 11 Uhr: CERT-Bund antwortet uns. Hersteller behauptet Lücken geschlossen zu haben
  • 2021-06-15 12 Uhr: Wir stellen fest, dass die Lücken nur teilweise geschlossen sind und kontaktieren erneut das CERT-Bund
  • 2021-06-15 15 Uhr: Hersteller behauptet Lücken jetzt wirklich geschlossen zu haben
  • 2021-06-16: Wir stellen fest, dass CWA-Credentials weiterhin gültig sind und finden Buchungsbestätigungen
  • 2021-06-16 15 Uhr: Meldung an Cert-Bund
  • 2021-06-17: Buchungs-PDFs sind nicht mehr weiter abrufbar

An solch einem Artikel sitzen wir als Kollektiv deutlich länger als eine Woche, vom Finden der Lücken, über das Schreiben der Reports, den Umgang mit den betroffenen Unternehmen bis zur Veröffentlichung dieses Posts.

Falls er euch gefällt, könnt ihr uns gerne unterstützen.


  1. Wir können zwar nicht versprechen, dass wir alles angucken, was uns zugesendet wird, aber wenn die Zeit gerade da ist, sind wir schon auch neugierig. ↩︎

  2. wie in der Dokumentation der CWA empfohlen ↩︎

  3. und vermutlich auch nie waren 🙄 ↩︎

  4. 🚂🚃🚃🚃😱🚃🚃🚃 ↩︎

  5. und das ganz ohne Blockchain! ↩︎