Skip to content

Gesichtserkennung an schottischen Schulen

Die Schulen im schottischen Bezirk North Ayrshire setzten Ende 2021 Gesichtserkennungssysteme ein, um Schulkinder zu erkennen. Das System sollte die Kinder identifizieren und denen dann die Teilnahme am kostenlosen Schulessen ermöglichen. Diese Praxis sorgte bereits für einige Kritik in UK-Medien und rief auch die dortige Datenschutzbehörde ICO auf den Plan.

Diese hat den Sachverhalt geprüft und kam zu dem Schluss, dass Gesichtserkennung in Schulen im Allgemeinen möglich ist. Allerdings hat der North Ayrshire Council (NAC) gegen verschiedene Bestimmungen in der DSGVO verstoßen. Konkret wurden folgende Punkte benannt:

  • Grundsatz der Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz
  • Informationspflicht
  • Speicherbegrenzung
  • Datenschutz-Folgenabschätzung

Der NAC wurde empfohlen bei der Datenminimierung und dem Grundsatz der Richtigkeit Verbesserungen vorzunehmen.

Die DSGVO schreibt im Erwägungsgrund 38, dass Kinder einen besonderen Schutz bei der Verarbeitung ihrer Daten genießen, da Kinder sich der betreffenden Risiken, Folgen und Garantien und ihrer Rechte bei der Verarbeitung personenbezogener Daten möglicherweise weniger bewusst sind.

Insbesondere wenn die Verarbeitung sehr tief in die Rechte und Freiheiten eingreift, so muss eine so genannte Datenschutz-Folgenabschätzung vorgenommen werden. Hierbei müssen die konkreten Risiken bewertet und Abhilfemaßnahmen eingebaut werden. Dies erschien der ICO im Falle der Schulen zwingend notwendig, war aber nicht vorhanden.

Die ICO hat sich die Anlage genauer angeschaut und versucht, eine Bewertung entlang der Pflichten der DSGVO vorzunehmen. Das Schreiben an die NAC liest sich wie eine Horrovorstellung.

  • NAC were unable to demonstrate that there was a valid lawful basis for the processing.
    Zu gut Deutsch: Für die Verarbeitung gab es keine Rechtsgrundlage. Personenbezogene Daten dürfen aber nur verarbeitet werden, wenn es eine solche gibt. Anfangs wurde wohl behauptet, dass die Schulen Aufgaben des öffentlichen Interesses wahrnehmen. Später ist man dann umgeschwenkt und hat eine Einwilligung als Rechtsgrundlage herangezogen. Allerdings gab es eben keine wirkliche Einwilligung, die den Vorgaben der DSGVO entsprach. Die Eltern scheinen mehr so eine Art allgemeine Einwilligung abgegeben zu haben.
  • Die Gesichtserkennung diente hier zur Identifizierung von Kindern. Das sind also biometrische Daten und damit besondere Kategorien personenbezogener Daten. Deren Verarbeitung ist im Art. 9 DSVGO nochmal explizit untersagt und hier gibt es eine Liste von Ausnahmen.
  • Einwilligung für Kinder müssen in einem für sie verständlichen Text geschrieben sein. Die ICO schreibt, dass es in der Tat zwei verschiedene Einwilligungsformulare (Erwachsene und Kinder) gab. Der Unterschied zwischen beiden Formularen waren die Worte Ihr Kind und Du. Dazu muss man wohl nichts mehr sagen.
  • Die ICO konnte nicht herausfinden, wann welche Daten wirklich gelöscht werden. Die NAC gab an, dass die Bilder fünf Jahre nach dem Ausscheiden oder am 23. Geburtstag der Person gelöscht werden. Warum gerade fünf Jahre ausgewählt wurden oder ob sowohl die Vorlage, die zur Erkennung genutzt wird wie auch die Einzelaufnahmen gelöscht werden, konnte nicht herausgefunden werden.
  • Auch zur Datenschutz-Folgenabschätzung ist die ICO eindeutig: We consider that the DPIA we reviewed is unlikely to have complied with Article 35 of the UK GDPR

Insgesamt ist das Schreiben der ICO sowie die Case Study ein schönes Dokument, um mal zu erfahren, wie man es nicht macht. Allerdings schreibt die ICO auch sehr gut und detailliert, wie die Schulen es besser machen könnten.

Ich hoffe ja, dass die Schulen lernen und das System abbauen und nicht wieder benutzen. In Anbetracht der Tatsache, dass vorher dort wie auch an anderen Schulen in Schottland Fingerabdrucksysteme zum Einsatz kamen, habe ich da jedoch wenig Hoffnung.

Kommunikationswerkzeuge im Jahr 2022

Es wird wieder mal Zeit, die Liste der Kommunikationswerkzeuge zu aktualisieren. Bisher erschien dies

Die Liste ist zum Vorjahr recht stabil geblieben. Ein Neuzugang ist der Messenger SimpleX, den ich mal mit verschiedenen Leuten teste. Darauf bin ich durch einen Blogbeitrag von Mike Kuketz aufmerksam geworden. Keybase habe ich nicht mehr benutzt. XMPP/Jabber steht auf der Abschussliste, da mir dort zuviel Spam reinkommt. Weiterhin habe ich mal cwtch.im (Onion Service) getestet. Die Bedienung war für mich zu wenig eingängig und da habe ich das nicht weiter verfolgt.

Nutze ich

  • E-Mail (ist für mich eines der Hauptkommunikationsmittel. Hinweise zum Schlüssel findet ihr auf der Kontaktseite.)
  • Signal
  • Matrix (@qbi:matrix.kraut.space)
  • XMPP/Jabber
  • Threema (PWB22538)
  • Jitsi (meist für Videokonferenzen des Hackspace Jena)
  • BigBlueButton
  • Briar (Kontakt gern auf Anfrage)
  • Mumble
  • SMS
  • Twitter oder Mastodon DM (nicht aktiv genutzt, wird aber als Kanal genutzt)
  • Wire
  • Zoom
  • Delta.Chat (deltachat[]kubieziel.de ist die korrekte Adresse)
  • SimpleX (Kontakt zum Testen gern auf Anfrage)
  • OnionShare (OnionShare kann seit kurzem auch Chats. Hier finden manchmal kurzzeitig Chats über Onion Services statt.)
  • Auf einem Extra-Rechner kommt für Kundenprojekte noch MS Teams und Google Meet zum Einsatz. Das erwähne ich hier aber eher der Vollständigkeit halber. :-)

Delta.Chat und Wire werden recht selten verwendet. Daher kann es sein, dass die beim nächsten Update in die untenstehende Kategorie verschoben werden.

Nutze ich nicht (mehr)

  • Keybase
  • Mattermost
  • Slack (ist im wesentlichen durch Matrix ersetzt worden)
  • Telegram
  • WhatsApp

Alles, was nicht genannt ist, fällt vermutlich in die Kategorie nicht genutzt. ;-)

Mastodon und die DSGVO

Bild eines Mastodons
Mastodon von Thomas Quine

Die Software Mastodon ist eine neue Erfolggeschichte aus meiner Heimatstadt Jena. Seitdem Elon Musk Twitter übernommen hat, suchen sich viele Menschen ein neues Social-Media-Zuhause und deren Wahl fällt sehr oft auf Mastodon. Andere gehen einen Schritt weiter, nehmen den Code von Eugen Rochko und bauen Server für sich und andere auf. Der Betrieb eines solchen Servers bietet einerseits einige technische Herausforderungen, aber aber auch viele aus dem nicht-technischen Bereich. Ich will in dem Beitrag mal den Augenmerk auf die Pflichten aus der Datenschutz-Grundverordnung (DSGVO) legen. Der Podcast Rechtsbelehrung hat kürzlich noch einen viel weitere Blick genommen. Hört mal in die Folge 112 zu Nutzungsbedigungen, Datenschutz und Digital Services Act rein.

Folgende Punkte gilt es zu beachten:

Mastodon-Startansicht
Mastodon-Startansicht

DSGVO?

Die erste Frage, die man sich stellen kann, ist, ob die DSGVO überhaupt relevant ist. Mit dem Betrieb eines Mastodon-Servers werden E-Mail-Adressen, Namen und anderes verarbeitet. All dies sind personenbezogene Daten. Damit ist die Verordnung anzuwenden.

Auftragsverarbeitung

Am Anfang steht die Frage, wo die Software installiert werden soll. Es könnte der eigene Server zu Hause sein, ein Raspberry Pi oder ein Server, der bei einem Provider in einem Rechenzentrum gemietet wird. In all diesen Fällen liegt die komplette Verantwortung in euren Händen. Hier müsst ihr euch später Gedanken zur Sicherheit machen. Aber hinsichtlich Auftragsverarbeitung können wir einen Haken machen. Denn dies ist nicht der Fall.

Wenn ihr ein “Fertigangebot”, wie masto.host, nutzt, dann beauftragt ihr eine fremde Firma mit der Verarbeitung der personenbezogenen Daten. Dies ist dann eine Auftragsverarbeitung. Damit müsst ihr sicherstellen, dass sich euer Anbieter auch an die DSGVO hält und auch ausreichende Sicherheitsmaßnahmen eingebaut hat. Die Anbieter haben für den Nachweis meist Listen mit technischen und organisatorischen Maßnahmen, Zertifikate oder anderes. Hier solltet ihr einen Blick drauf werfen und abschätzen, ob das euren Anforderungen genügt.

Der zentrale Punkt ist dann ein Vertrag zur Auftragsverarbeitung. Dieser Vertrag muss sich an die Vorgaben des Art. 28 DSGVO halten. Praktisch haben die Anbieter meist vorgefertigte Verträge, die ihr nur herunterladen und unterschreiben müsst.

Mit diesem ersten Schritt habt ihr die erste Hürde überwunden und könnt zur Installation oder Konfiguration des Servers schreiten.

Sicherheit der Verarbeitung

Beim Installieren und Einrichten des Servers (wie auch später im laufenden Betrieb) ist es sinnvoll, sich Gedanken über die Sicherheit zu machen.

Die DSGVO möchte ein angemessenes Sicherheitsniveau haben. Dies muss der Art der verarbeiteten Daten und dem Risiko entsprechen. Dabei muss der Stand der Technik und die Kosten der Einführung mit berücksichtigt werden. Doch welche Daten verarbeitet ihr? Soweit ich das sehe, sind das bei einem Mastodon-Server:

  • Name und Profilname
  • E-Mail-Adresse
  • Passwort
  • öffentliche Toots und “private” Nachrichten

Dabei sind Name, Profilname und öffentliche Toots Daten, die die Person mit der Verwendung des Dienstes auch veröffentlicht. Hier ist der Schutzbedarf eher gering. Meiner Meinung nach sind nur die E-Mail-Adresse, das Passwort und die privaten Nachrichten Daten, wo sich tiefergehende Gedanken über die Absicherung “lohnen”. Andererseits werden all diese Daten in einer Datenbank liegen. Somit ist es sinnvoll, die Datenbank als Ganzes zu betrachten.

Die konkreten Überlegungen hängen davon ab, wie ihr den Server betreibt, also steht der bei euch zu Hause oder im Rechenzentrum, läuft der auf einer eigenen Maschine oder auf einem Rechner, der von vielen anderen benutzt wird etc.? Mit den untenstehenden Fragen will ich ein paar Denkanstöße hinsichtlich von Sicherheitsmaßnahmen geben. Denkt mal bitte darüber nach, wie das bei eurem Server aussieht und ob dieser hinreichend abgesichert ist:

  • Zugang zum Server: Ein Schutz besteht schon, wenn niemand den Server “anfassen” kann. Das heißt, Personen, die keine Berechtigung haben, sollten auch keinen physischen Zugang zu dem Gerät bekommen. Wie sieht das bei euch aus? Steht das Gerät in einem stark frequentierten Raum oder separat in einem abgeschlossenem Raum? Gibt es Fenster und Türen, durch die Menschen einfach an das Gerät kommen? Stellt euch einen Einbrecher vor und fragt euch, wie leicht oder schwer es dieser Person fallen könnte, direkt auf euren Server zuzugreifen. Anhand dessen könnt ihr euch dann Maßnahmen überlegen, die dies erschweren. Wenn es ein Server in einem Rechenzentrum ist, erübrigen sich diese Gedanken meist. Denn hier gibt es meist Zugangsrichtlinien, die kontrolliert werden und auf die ihr auch keinen Einfluss habt.
  • Zugriff auf die Daten: Wenn es nun jemand zum Server geschafft hat, soll die Person möglichst keinen Zugriff auf die Daten bekommen. Dies könnte passieren, wenn diese Person vor dem Rechner steht und versucht, euer Passwort zu erraten oder über SSH Rateversuche unternimmt. Eventuell hat sich Schadsoftware auf der Maschine breit gemacht und liest Daten aus. Bei Überlegungen zu dem Punkt ist eure Kreativität gefragt. Auf welche Weise könnte ein Angreifer Zugriff auf eure Daten bekommen und wie unterbindet ihr das?
  • Abhören der Daten: Beim Einloggen in den Server oder auch bei der Benutzung des Servers könnte es sein, dass Unbefugte versuchen, mitzuhören. Es wäre möglich, dass jemand eure Kommunikationswege (E-Mail, Messenger etc.) überwacht, um Daten mitzulesen. An der Stelle bruacht ihr ebenfalls Maßnahmen. In der Regel sind das verschiedene Verschlüsselungsmaßnahmen. Das heißt, die Webseite muss über TLS erreichbar sein, eure Mails und anderen Kommunikationen müssen mindestens transportverschlüsselt sein. Wenn ihr die Daten physisch umher tragt, solltet ihr ebenfalls über eine Verschlüsselung nachdenken.
  • Verfügbarkeit der Daten und des Dienstes: Vermutlich gebt ihr keine Garantien hinsichtlich der Verfügbarkeit ab. Dennoch kann es schnell passieren, dass euer Dienst im Nirvana verschwindet. Hitze, Staub und Feuchtigkeit können dem Server zusetzen. Wenn der im Rechenzentrum steht, haben sich andere Gedanken gemacht. Wenn der Server auf euren Maschinen läuft, müsst ihr euch diese Gedanken machen. Weiterhin ist ein Backup ein wichtiger Schritt. Denkt darüber nach, wie die Datenbank und die einzelnen Dateien gebackupt werden können und testet regelmäßig die Wiederherstellung.

Ihr könnt natürlich noch viel mehr Maßnahmen einsetzen und den Schutz deutlich erhöhen. Die obige Aufstellung soll euch ein paar Anstöße liefern. Das Grundschutzkompendium des BSI ist u.a. eine Quelle, wo verschiedene Maßnahmen mit aufgelistet sind.

Rechte der betroffenen Personen

Die DSGVO gibt den betroffenen Personen einige Rechte. Diese sollen wissen, dass Daten von ihnen verarbeitet werden, welche das sind, wie lange etc. Die Rechte müsst ihr beim Betrieb eines Servers natürlich auch gewährleisten.

Datenschutzhinweise

Wenn Daten erhoben werden, beginnt für euch eine Pflicht, die Menschen zu informieren. Dies geschieht in der Regel über Datenschutzhinweise auf der Webseite. Der Artikel 13 der DSGVO enthält genaue Hinweise, welche Daten dort aufzuführen sind. Ich habe euch exemplarisch mal Hinweise anderer Instanzen verlinkt. Dort könnt ihr sehen, solche Informationen aussehen können.

Auskunftsrecht

Nun können die betroffenen Personen jederzeit zu euch kommen und euch um eine Auskunft zu den verarbeiteten Daten bitten. Das bedeutet, zunächst müsst ihr prüfen, ob ihr überhaupt Daten dieser Person verarbeitet und falls ja, ist dann eine Auskunft zur Verarbeitung zu machen.

Wichtig ist hier zunächst, dass ihr einen solchen Antrag überhaupt wahrnehmt. Vermutlich werden sich die meisten über eine Mastodon-Nachricht oder eine E-Mail an euch wenden. Das heißt, ihr solltet sicherstellen, dass ihr regelmäßig eure Direktnachrichten und E-Mails lest. Denn ihr müsst spätestens innerhalb eines Monats nach Eingang auf die Nachricht reagieren.

Wenn ich davon ausgehe, dass jemand mit einem Mastodon-Konto auf eurem Server eine solche Anfrage stellt, so können die erforderlichen Angaben dem untenstehenden Verzeichnis der Verarbeitungstätigkeiten entnommen werden.

Sollte nun jemand ohne Account bei eurem Mastodon-Server eine Anfrage stellen, wird es spannend. Denn unter Umständen verarbeitet ihr auch dessen Daten. Soweit ich das sehe, müssten die folgenden Punkte mit in der Auskunft erwähnt werden. Bitte kopiert dies jedoch nicht einfach hier von der Seite, sondern prüft das nochmal nach. Wenn ihr zu einem anderen Ergebnis kommt, freue ich mich natürlich über eine Rückmeldung.

  • Zweck der Verarbeitung: Betrieb eines Mastodon-Servers, Austausch und Kommunikation
  • Kategorien personenbezogener Daten: Name, Mastodon-Benutzername, Uhrzeit des Beitrags, verwendete Software, Inhaltsdaten, (ggf. IP-Adresse und weiteres)
  • Empfänger: Besucher:innen der Webseite, andere Mastodon-Benutzer:innen
  • Speicherdauer: Hier musst du in deine Einstellungen schauen.
  • Drittlandübermittlung: Wenn dein Server oder auch dein Anbieter außerhalb der EU agiert, wäre das hier mit zu erwähnen.
  • Weiteres: Daneben musst du die User auf deren Rechte hinweisen. Genaueres siehe Art. 15 DSGVO.

Löschrecht

Neben einer Auskunft kann jemand auch die Löschung seiner Daten verlangen. Das könnte sowohl jemand mit als auch ohne Konto bei eurem Server sein. Im ersteren Fall wird ein Löschantrag sicher schwierig, denn die Person hat ja noch ein Konto. Damit wäre eine weitere Verarbeitung vermutlich notwendig und es gäbe keinen Löschanspruch.

Wenn jemand ohne Konto eine Löschung verlangt, wird es schon schwieriger. Diesen Fall diskutiert Enno Lenze auch in seinem Beitrag “Weg von Twitter, hin zu Mastodon?”.

Datenschutzverletzungen

Wenn euer Server gehackt werden sollte, so gibt es auch seitens der DSGVO Pflichten, die auf euch zukommen. Einerseits ist das eine Meldepflicht in Richtung der Aufsichtsbehörden und andererseits eventuell auch eine Information der betroffenen Personen.

Eine Datenschutzverletzung kann dabei vieles sein. Im Allgemeinen muss es sich um eine Verletzung der Sicherheit handeln, die zu

  • Vernichtung
  • Verlust
  • Veränderung
  • unbefugter Offenlegung oder
  • Zugang durch Unbefugte

führt. Also wären

  1. ein versehentliches Löschen der Datenbank,
  2. Ransomware, die alle Daten verschlüsselt,
  3. ein Datenbankdump, der auf der Webseite frei zum Download steht oder
  4. ein “klassisch” gehackter Server

Beispiele für Datenschutzverletzungen. Es wäre sinnvoll, dass ihr euch immer mal wieder Gedanken macht, was in eurem Fall konkret Datenschutzverletzungen sein können. Oftmals stellt man fest, dass auch schon triviale Sachen in die Definition passen und gemeldet werden müssen.

Ich will die obigen Beispiele kurz diskutieren:

  1. Wenn ihr für die Datenbank ein Backup habt, spielt ihr das ein und der Server läuft wieder. In dem Fall ist aus meiner Sicht kein besonderes Risiko für die betroffenen Personen entstanden. Daher gehe ich nicht von einer Meldepflicht aus. Allerdings solltet ihr gemäß Art. 33 Abs. 5 DSGVO den Vorgang dokumentieren. Also kurz aufschreiben, was passierte und was ihr gemacht habt.
  2. Eine Ransomware, die nur die Daten verschlüsselt, könnte auch durch Aufspielen eines Backups “bekämpft” werden und der Fall wäre wie der oben zu behandeln. Allerdings müsst ihr sicherstellen, dass es keinen Fremdzugriff gab und das ist gerade bei aktueller Schadsoftware nicht der Fall. Das heißt, hier wird sehr oft auf die Daten zugegriffen, die heruntergeladen etc. In solch einem Fall liegen die personenbezogenen Daten in den Händen Fremder. Also besteht ein Risiko für die Betroffenen. Es empfiehlt sich eine Meldung an die Aufsichtsbehörden und ich würde hier sogar eine Meldung an die Betroffenen befürworten.
  3. Wenn der Dump nur kurze Zeit auf der Seite war und ihr Fremdzugriffe ausschließen könnt oder wenn der Dump verschlüsselt ist, könnte man wie bei 1. auf die Meldung verzichten. Aber gerade wenn das nicht der Fall ist, wäre eine Meldung an die Betroffenen und die Aufsichtsbehörden Pflicht.
  4. Ein gehackter Server ist immer ein Grund für eine Meldung an die Behörden. Es sei denn, ihr könnt durch spezielle Sicherheitsmaßnahmen im Vorfeld ausschließen, dass es einen Zugriff auf personenbezogene Daten gab.

In einer Meldung über eine Datenschutzverletzung muss folgendes stehen:

  1. Art der Verletzung
  2. Kategorien und Zahl der betroffenen Personen
  3. ungefähre Zahl der Datensätze
  4. Beschreibung der Folgen der Verletzung
  5. Beschreibung der Maßnahmen, die ihr ergriffen habt.

Ich würde euch empfehlen, euch bereits vorher Gedanken über eine solche Meldung zu machen. Das macht es im konkreten Fall oft leichter, die Meldung abzusetzen.

Verzeichnis von Verarbeitungstätigkeiten

Ein recht “spannender” Punkt ergibt sich aus dem Art. 30 DSGVO. Demnach wäre ein Anbieter eines Mastodon-Servers verpflichtet, ein Verzeichnis von Verarbeitungstätigkeiten (VVT) zu führen. Das ist eine Auflistung von Vorgängen oder Prozessen bei denen personenbezogene Daten verarbeitet werden. In diesem Punkt steckt meist viel Detailarbeit. Beim Betrieb eines Mastodon-Servers müsste man zumindest die Verarbeitung durch den Server selbst sowie Kommunikation per E-Mail mit erfassen. Alles weitere hängt von euren Gegebenheiten ab. Ich habe untenstehend mal einen Versuch unternommen, die Einträge aufzuschreiben. Korrekturen sind herzlich willkommen.

VVT zum Serverbetrieb

  • Name und Kontaktdaten des Verantwortlichen: Das solltet ihr leicht ermitteln können. :-)
  • Zweck der Verarbeitung: Bereitstellung einer öffentlichen Kommunikationsplattform auf der Basis des ActivityPub-Protokolls
  • Kategorien betroffener Personen: Besucher:innen, Nutzer:innen
  • Kategorien personenbezogener Daten: Name, Mastodon-Username, Uhrzeit, verwendete Software, Inhaltsdaten, Verbindungsdaten
  • Empfänger: Andere Mastodon-Server, Dritte
  • Übermittlung in Drittländer: keine (oder Nennung, falls ihr sowas einsetzt) oder, aufgrund des Charakters des Dienstes, immer :-)
  • Löschung der Daten: Nennung, wann ihr welche Daten löscht. Hier gibt es Unterschiede zwischen Nutzungsdaten, wie IP-Adresse, und Inhaltsdaten, wie Beiträgen.
  • IT-Sicherheitsmaßnahmen: Nennung der Sicherheitsmaßnahmen, die ihr implementiert habt. Es ist meist besser, das in einem eigenem Dokument aufzuschreiben und darauf zu verweisen.

VVT für E-Mails

  • Name und Kontaktdaten des Verantwortlichen: Das solltet ihr leicht ermitteln können. :-)
  • Zweck der Verarbeitung: Elektronische Kommunikation
  • Kategorien betroffener Personen: Nutzer:innen, Dritte
  • Kategorien personenbezogener Daten: Name, E-Mail-Adresse, Verbindungs- und Inhaltsdaten
  • Empfänger: eventuell andere Admins des Dienstes (überlegt, wer die Mails noch “sieht”)
  • Übermittlung in Drittländer: keine (oder Nennung, falls ihr sowas einsetzt)
  • Löschung der Daten: E-Mails als Geschäftsbriefe 6 Jahre Aufbewahrung, E-Mails als steurrechtliche Unterlagen 10 Jahre Aufbewahrung
  • IT-Sicherheitsmaßnahmen: Nennung der Sicherheitsmaßnahmen, die ihr implementiert habt. Es ist meist besser, das in einem eigenem Dokument aufzuschreiben und darauf zu verweisen.

Weiteres und Fragen

Beim Schreiben dieses Artikels fiel mir auf, dass es noch viel mehr Dinge geben könnte, auf die man ein Auge haben müsste bzw. es gäbe andere Spezialfälle, die man auch diskutieren könnte. Ich habe mich letztlich entschieden, diese wegzulassen. Falls du beim Lesen des Beitrags Fragen hast oder dir Themen fehlen, schreibe am besten einen Kommentar (oder nutze andere Wege). Ich versuche, darauf zu antworten oder den Beitrag entsprechend anzupassen.

Onionshare für den Dateiaustausch verwenden

In regelmäßigen Abständen habe ich das Vergnügen, auf Journalisten aus verschiedenen Ländern der Welt zu treffen. Ich schule diese, wie man Internetsperren umgehen kann, worauf es bei der Anonymität ankommt etc. Eines der Werkzeuge, die ich dabei erwähne und welche Begeisterung auslöst, ist OnionShare (Onion-Link).

Wie der Name schon sagt, geht es um den Austausch (von Dateien) über Onions (also das Tor-Netzwerk). OnionShare entstand ursprünglich als Werkzeug, um eine einfache und sichere Downloadmöglichkeit über Tor Onion Services zur Verfügung zu stellen. Das Gute hieran ist, dass der Austausch komplett über das Tor-Netzwerk läuft, Sender und Empfänger können also unerkannt kommunizieren. Wenn OnionShare beendet wird, dann verschwindet auch der Link und kann auch nicht wieder wiederhergestellt werden. Mittlerweile lassen sich über das Programm Downloads oder Uploads bereitstellen, chatten und auch Webseiten anbieten. All das passiert mit wenigen Klicks. Wie funktionier das?

Für Windows gibt es eine MSI-Datei und für macOS eine DMG-Datei, die man installieren kann. Unter Linux gibt es Flatpak- oder Snap-Pakete. Ich nutze in der Regel das Flatpak. Dazu müsst ihr zunächst Flatpak einrichten. Der konkrete Weg ist abhängig von eurer Distribution und verbirgt sich hinter dem Link. Wenn das eingerichtet ist, kann das dann über flatpak install flathub org.onionshare.OnionShare installiert werden.

Willkommen-Bildschirm beim Start von OnionShare
Willkommen-Bildschirm beim Start von OnionShare

Oben seht ihr das Menü nach dem Start von OnionShare. Im einfachsten Fall klickt ihr auf “Connect to Tor”, OnionShare verbindet sich mit Tor und ihr könnt nun aus vier Möglichkeiten auswählen:

  1. Dateien teilen
  2. Dateien empfangen
  3. Webseite
  4. Anonym chatten

Sollte keine Verbindung zu Tor hergestellt werden können, empfehle ich einen Blick in das Handbuch. Dort stehen verschiedene Möglichkeiten beschrieben, die ihr einstellen könnt.

Die weitere Benutzung von OnionShare ist recht einfach. Ihr wählt den entsprechenden Menüpunkt aus, beantwortet ein paar Fragen und schon kann es losgehen.

Wenn ihr Dateien teilen wollt, klickt auf Dateien oder Ordner hinfügen und wählt diese aus. Wenn ihr damit fertig seid, könntet ihr schon mit dem Teilen beginnen. Allerdings solltet ihr über zwei Punkte nachdenken:

  1. Standardmäßig lässt OnionShare einen Download zu und schließt danach den Onion Service. Das ist sinnvoll, wenn ihr einer Person die Datei(en) schicken wollt. Wenn sich der Download an mehrere richtet, solltet ihr den Menüpunkt “Dateifreigabe beenden, …” deaktivieren. Dann bleibt der Dienst bis zum Schließen von OnionShare erhalten.
  2. Weiterhin richtet OnionShare eine private OnionShare-Adresse ein. Damit wird neben der Onion-Adresse ein privater Schlüssel erzeugt, der an den Empfänger übertragen werden muss. Dies ist einerseits die sichere Variante, andererseits macht das aus meiner Erfahrung mehr Probleme. Daher wähle ich meist aus, dass das ein öffentlicher OnionShare-Dienst ist.

Beide Punkte findet ihr auch bei den anderen Menüpunkten von OnionShare. Wenn ihr eure Auswahl getroffen habt, klickt auf den grünen Knopf und das Teilen kann beginnen.

OnionShare teilt Dateien

OnionShare teilt Dateien

Die obigen Ansicht zeigt euch OnionShare an, nachdem das Teilen begonnen wurde. Ich habe mal eine Datei geteilt, die nsu-akten-gratis.pdf heißt. Wenn ihr den Artikel lest, wird es die Onion-Adresse nicht mehr geben. Die Datei bezieht sich auf eine Veröffentlichung von Frag den Staat und Jan Böhmermann (Alternative). Das Original liegt hier.

Das Wichtige oben ist die Onion-Adresse. Diese schickt ihr weiter und der Empfänger öffnet diese mit dem Tor-Browser. Dort wird dann folgendes angezeigt:

Download im Tor-Browser
Download im Tor-Browser

Mit einem Klick auf “Download Files” werden die Dateien schließlich heruntergeladen. Probiert das mal aus. Ihr werdet sehen, dass dies wirklich einfach ist.

Doch wie funktionieren die anderen drei Punkte? Findet es heraus! Probiert es mal für euch und teilt eure Erfahrungen in den Kommentaren. Ich freue mich, von euren Erfahrungen zu hören. ;-)

Erste Erfahrungen im Wissensmanagement mit Obsidian und Logseq

Graph meines kleinen ersten Projekts
Graph meines kleinen ersten Projekts

Im Podcast TILpod war Wissensmanagement mit Obsidian und Logseq kürzlich das zentrale Thema. Dirk Deimeke und Sujeevan Vijayakumaran berichteten über deren Erfahrungen mit den Tools Logseq und Obsidian. Im Rahmen meines Jobs betreue ich derzeit eine ERP-Software und dort gibt es viele Knöpfe, Einstellungen, Möglichkeiten etc. Daher wollte ich beide Werkzeuge mal testen und prüfen, ob die sich irgendwie in meine Arbeit integrieren lassen. Der Blogbeitrag ist das Ergebnis meiner ersten Schritte. Ich will hier mal die frischen Erkenntnisse niederschreiben.

Zettelkasten

Die Idee beider Software lehnt sich an das Zettelkastenprinzip von Niklas Luhmann an. Das bedeutet, man schreibt seine Ideen, Gedanken oder anderes auf einen Zettel. Diese Zettel sind, ähnlich wie in einem Wiki oder auf einer Webseite, miteinander verlinkt. Dadurch entsteht ein Wissensnetz und durch eine Graphansicht lassen sich neue Erkenntnisse und Einsichten gewinnen. Die Beschreibung ist sehr verkürzt. Wenn ihr euch mehr dafür interessiert, schaut euch mal das Video “Zettelkasten deutsch - Smarte Notizen schreiben” von Joshua Meyer an. Ich fand das eine gute Einführung in das Thema.

Obsidian und Logseq

Obsidian, Logseq wie auch andere Software setzen die Zettelkästen um. Es wird ein “Zettel” in Markdown geschrieben. Dadurch lassen sich die Notizen formatieren und der Text bleibt lesbar. Das heißt, die Notizen bleiben unter Umständen für die Ewigkeit erhalten. Mittels der Verlinkung in Markdown entsteht auch untereinander eine Verlinkung und ein Graph wird aufgebaut.

Obsidian ist eine proprietäre Software und wird über Github zum Download angeboten. Diese kann dann kostenlos oder derzeit einmalig für 25 bzw. 50 US-Dollar genutzt werden. Bei der kostenlosen Variante bleiben die Daten lokal auf der Festplatte liegen. Für 8 US-Dollar pro Monat lässt sich eine Synchronisation dazu buchen. Allerdings geht das durchaus auch über NextCloud, Dropbox oder ähnliche Dienste. Mir ist derzeit unklar, warum ich die Software kaufen sollte. Die Features, die beworben werden (Zugang zu “Insider Builds”, schöne Badges etc.), erscheinen mir wenig reizvoll für den Kauf.

Logseq ist Freie Software unter der AGPL-3.0-Lizenz. Sie wird ebenso über Github zum Download angeboten. Die Entwicklung der Software finanziert sich u.a. über Spenden. Wie auch bei Obsidian lassen sich die Dateien mit Cloud-Diensten synchronisieren. Zusätzlich ist auch ein Commit via git im Standardumfang enthalten.

Wann immer es geht, versuche ich, Freie Software einzusetzen. Daher würde ich gern Logseq einsetzen, sofern ich den Ansatz für das Wissensmanagement überhaupt weiter verfolge.

Mein Einstieg

Zu Anfang habe ich mir die Videoanleitungen “Zettelkasten in Obsidian” und “How to get started in Logseq” sowie ein paar andere angeschaut.

Wenn man sich die beiden Kurse anschaut, stellt man schon interessante Unterschiede fest. Der Kurs zu Obsidian nimmt die Menschen in den Fokus, die die Software erstmalig einsetzen wollen. Es gibt es Erklärung zu dem Prinzip des Zettelkastens und dann wird mit einem konsistenten Beispiel über den Kurs hinweg gearbeitet. Nach dem Video hatte ich einen guten Eindruck, wie die Software funktioniert und wie ich die nutzen kann. Der Kurs zu Logseq erzählt auf einem sehr hohen Level Konzepte und Ideen. Ich hatte hier zunächst das Gefühl, dass dies für mich wenig hilfreich ist. Beim TILpod ist noch “Logseq beginner's course” verlinkt. Damit gibt es einen besseren Einstieg in das Thema. Den Kurs empfand ich wie ein Handbuch, was vorerzählt wird.

Nachdem ich das Gefühl hatte, in etwa die Software zu verstehen, habe ich mit einem künstlichen Beispiel in Obsidian erste Schritte unternommen und mit einem realen Beispiel Logseq bespielt. Unten habe ich dann das Beispiel aus Logseq auch in Obsidian genutzt.

Mein angedachter Arbeitsablauf

Meine erste Vorstellung des Arbeitsablaufs war, dass ich zunächst ein paar grundlegende Informationen in der Software hinterlege und später diese dann um aktuelles Wissen ergänze. So gibt es beispielsweise immer mal wieder das Problem, dass beim Login in der ERP-Software die Meldung kommt, dass der Nutzer schon angemeldet sei. Hier würde ich dann in Logseq oder Obsidian eine entsprechende Seite anlegen und die Lösung beschreiben. Dies würde ich dann entsprechend verlinken und hoffentlich später wieder finden.

Soweit ich das einschätzen kann, würde Obsidian diesen Ansatz recht gut unterstützen. Jedenfalls kann ich die Ideen mit der Standardinstallation einfach so umsetzen.

Logseq arbeitet standardmäßig mit einem Journal. Das heißt, zunächst wird dort eine Seite mit dem aktuellen Datum geöffnet. Dort lassen sich tägliche Notizen machen und dann verlinken. Dieser Ansatz fühlt sich anders an, als bei Obsidian. Allerdings lässt sich hier mein obiger, geplanter Arbeitsablauf durchführen.

Vom Start weg scheint Obsidian hier besser benutzbar zu sein und das zu unterstützen, was ich machen will. Bei Logseq fiel mir das erst auf den zweiten Blick auf.

Unabhängig von meinem angedachten Arbeitsablauf erscheint mir der Ansatz von Logseq recht gut zu sein. Hier kann man seinen kompletten Tag aufschreiben und verlinken. Dadurch bildet sich eine viel größere Wissensbasis als in meinen auf einen Zweck beschränkten Beispiel.

Erste Schritte mit Obsidian

Startansicht von Obsidian
Startansicht von Obsidian

Beim ersten Öffnen von Obsidian fragt die Software nach einem so genannten Vault. Das ist so eine Art Projektansicht. Nachdem entweder eine existierende geöffnet oder eine neue angelegt wurde, kann es losgehen. Datei um Datei entsteht dann ein Wissensspeicher.

Wenn das linke Vorschaufenster ausgeklappt ist, sind die Dateien sichtbar. Die Ansicht finde ich im Moment recht nützlich, weil sie mir einfach einen Überblick über existierende Dateien verschafft. Vermutlich wird das aber im Laufe der Zeit eine immer kleinere Rolle spielen.

In den Videoanleitungen zu Obsidian gab es noch einen Hinweis zu Aliasen. Dieses Feature fand ich recht nützlich. Denn im Rahmen meines Anwendungsfalles gibt es einen Baustein namens “Auftrag”. Wenn ich im Text hierauf verweise, kann es sein, dass ich manchmal Aufträge, Aufträgen etc. schreiben muss. Mittels Aliases kann das alles auf eine Seite umgebogen werden.

Ansicht eines Eintrages mit Graph
Ansicht eines Eintrages mit Graph

Erste Schritte mit Logseq

Initiale Ansicht von Logseq
Initiale Ansicht von Logseq

Beim ersten Öffnen von Logseq erscheint eine Art Info-Bildschirm. Dieser informiert über die ersten Schritte bei der Bedienung der Software. Allerdings fehlte mir die Information, wie ich über den Start hinaus komme. Innerhalb des Tutorials kann man arbeiten, neue Seiten anlegen etc. Aber wie arbeitet man nun produktiv? Erst später fiel mir auf, dass es rechts oben den Eintrag “Öffnen” gibt. Darüber kann man ein Verzeichnis angeben. Die Daten werden dann in diesem Verzeichnis abgelegt.

Interessanterweise fand ich keine Möglichkeit, wieder zu dem Startbildschirm zurück zu wechseln. Man kann neue Seiten anlegen und zwischen diesen wechseln. Aber der Startbildschirm scheint verschwunden zu sein.

Der Arbeitsablauf bei Logseq basiert nun auf dem Journal. Es wird eine Datei mit dem aktuellen Datum angelegt. Dort lassen sich dann Informationen, TODO-Einträge und vieles mehr ablegen. Über Verlinkungen werden dann auch einzelne Seiten angelegt. Es fühlt sich für mich so an, als ob das Journal der Kern der Software wäre.

Mir fehlt eine Ansicht der Dateien. Es gibt zwar Neueste und Favoriten. Aber ich würde mir für den Anfang eine Überischt aller Dateien wünschen. Diese lässt nur über den Menüeintrag “Alle Seiten” öffnen. In dem Fall öffnet sich dann ein neues Fenster.

Neben den obigen Punkten muss ich mich vermutlich noch in die Software einfinden. Rein optisch stören mich die Punkte am linken Rand. Das ist vermutlich eine Markierung für den Block. Aber gerade bei Überschriften sieht das merkwürdig aus.

Detailansicht eines Eintrags in Logseq
Detailansicht eines Eintrags in Logseq

Vorläufiges Fazit

Für meinen Anwendungsfall (Wissen bei einer spezifischen Software dokumentieren) scheint mir Obsidian die passendere Software zu sein. Die unterstützt das, was ich will, bestmöglich. Das geht natürlich auch mit Logseq. Aber hier habe ich den Eindruck, dass ich da immer mal einen Klick oder einen Befehl zusätzlich verwenden muss und die Software da mehr im Weg steht.

Ganz allgemein finde ich jedoch den Ansatz von Logseq, alles in ein Log zu schreiben und Dateien zu pflegen, sehr gut. Dadurch erhält man einen guten Überblick über die täglichen Aufgaben, TODOs und anderes. Ganz nebenbei wird eine Wissensdatenbank aufgebaut. Logseq bietet auch die Möglichkeit, die Dateien in ein git zu committen. Das will ich mal ausprobieren.

Wenn beide Anwendungen ähnliche Voraussetzungen hätten, würde ich vermutlich Obsidian nutzen. Die Software macht mir den Eindruck, als ob sie meinen Arbeitsfluss deutlich besser unterstützen würde. Allerdings bevorzuge ich eben Freie Software, so dass ich die nächsten Schritte erstmal mit Logseq machen werde. Eventuell werde ich später über die weitere Erfahrungen berichten.

Nutzt ihr auch Obsidian, Logseq, Roam oder etwas ähnliches? Wie sind eure Erfahrungen und wie setzt ihr die Software ein?

Liste von Android-Apps

Bei Jörg sah ich kürzlich eine Liste von Android-Apps, die er verwendet. Solch eine Liste kann eine gute Idee sein, um neue interessante Apps zu finden. Daher habe ich beschlossen, auch eine solche Liste aufzustellen.

Systemfunktionen

Büro

Kommunikation

Multimedia

  • Antennapod: Verwaltung von Podcasts
  • Newpipe: Zugriff auf Youtube, Soundcloud, media.ccc.de und anderes
  • SkyTube: Zugriff auf Youtube
  • VLC: Video- und Musikabspielprogramm
  • Zapp: Streams der öffentlich-rechtlichen Sender anschauen

Sonstiges

Der IFG-Hack des Tages

Die Informationsfreiheitsgesetze sind ein wundervolles Instrument, um öffentliches Handeln transparenter zu machen. Mit einer Anfrage lassen sich verschiedene Informationen beziehen und die Plattform Frag den Staat macht es einfach, solche Anfragen zu stellen. Ein Blick auf die letzten Anfragen ist immer recht interessant.

So stieß ich kürzlich auf eine Anfrage einer Person, die von der TU Dortmund die Kosten für den Einsatz von Zoom und Webex wissen wollte. Spätestens seit Beginn der Corona-Pandemie setzen viele Unternehmen und auch Universitäten auf Videokonferenzen. Zoom und Webex sind zwei solcher Lösungen. Eine Frage nach den Kosten des Einsatzes sollte einfach zu beantworten sein. Jedoch beobachte ich, dass sich viele Stellen schwer tun und versuchen, “Gegenargumente” zu finden.

So war es auch im Fall der TU Dortmund. Zunächst wurde die Anfrage nicht innerhalb der gesetzlichen Frist beantwortet. Die Person mahnte zweimal eine Antwort an. Schließlich antwortete die Uni, dass sie die Antwort gern als Brief versenden wollen und daher die Adresse benötigen.

Die Angabe einer Adresse ist bei solchen Anfragen in der Regel nicht nötig, da Anfragen von jeder Person gestellt werden können. Die öffentliche Stelle kann einfach auf die E-Mail anworten. Die Uni beharrte jedoch auf der Angabe einer Adresse und so schaltete die Person den Landesbeauftragten für Datenschutz und Informationsfreiheit NRW (LDI NRW) ein. Der bestätigte, dass Anfrage und Antwort per E-Mai erfolgen müssen. Er schrieb in seiner Antwort auch von Ausnahmen, unter anderem kann bei einer Ablehnung der Anfrage die Adresse erfragt werden. Nach zwei Monaten Wartezeit kam die TU Dortmund dann zu dem Schluss, dass der Bescheid abgelehnt werden soll und fragte wieder nach der Adresse. Nach weiterer Vermittlung durch das LDI NRW schickte die Uni eine kurze Begründung über die Ablehnung. Sie beriefen sich auf den Schutz von Betriebs- und Geschäftsgeheimnissen nach § 8 IFG NRW.

An der Stelle begann der Antragsteller nun kreativ zu werden. Die Uni bat an, den Bescheid zuzusenden oder vor Ort abzuholen. Natürlich wollte die Person Letzteres, worauf die Uni meinte, dass die Gebäude wegen Corona verschlossen sein. Immerhin wurde eine Terminvereinbarung angeboten. In einer überraschenden Wendung verzichtete der Antragsteller nun auf die Abholung und brachte die DSGVO in Stellung. Der Art. 15 Abs. 3 Satz 1 DSGVO sagt:

Der Verantwortliche stellt eine Kopie der personenbezogenen Daten, die Gegenstand der Verarbeitung sind, zur Verfügung.

Im Rahmen der Anfrage wurden personenbezogene Daten verarbeitet. Insbesondere auf dem Bescheid sollte der Name und ggf. weitere Daten enthalten sein. Damit müsste der Bescheid im Rahmen der Anfrage nach der DSGVO an den Antragsteller geschickt werden.

Im weiteren Verlauf der IFG-Anfrage ist jedoch zu sehen, dass dies die Uni zunächst nicht gemacht hat und die Person das moniert. Es ist also spannend zu beobachten, wie die Anfrage weiter verläuft. Ich halte euch auf dem Laufenden.

cronjob