Zum Inhalt springen

Datenschutz und Sicherheit

Diese Seite beschreibt, welche personenbezogenen Daten Lagebuch verarbeitet, wo sie gespeichert werden, was ein Gerät verlässt und was die Feuerwehr selbst regeln muss. Sie richtet sich an Kommandantinnen und Kommandanten, Kreisbrandinspektionen und kommunale Datenschutzbeauftragte.

Stand: Version 0.5.0, September 2026. Lagebuch steht noch vor Version 1.0 und entwickelt sich schnell; maßgeblich ist jeweils die Fassung dieser Seite, die zur installierten Version gehört. Die Darstellung ist technisch und ausdrücklich keine Rechtsberatung.

  • Kein Konto, keine Cloud, kein Server. Lagebuch meldet sich nirgends an und überträgt von sich aus nichts.
  • Ein Einsatz ist eine Datei. Die .lagebuch-Datei liegt dort, wo sie gespeichert wurde, und gehört der Wehr.
  • Keine Telemetrie, keine automatisch versandten Absturzberichte, keine Updateprüfung. Es gibt im gesamten Programm keinen Aufruf, der Nutzungsdaten irgendwohin sendet.
  • Keine Logdateien. Das Programm schreibt heute kein Protokoll auf die Festplatte – ein Absturz hinterlässt nur einen kurzen Bericht ohne Fehlertexte und ohne Einsatzdaten (siehe unten).
  • Die Stammdaten sind nach der Installation leer. Namen und Telefonnummern kommen ausschließlich durch einen selbst ausgelösten Import ins Programm.
  • Die Mehrgeräte-Verbindung ist optional und richtet sich immer an genau das Gerät, dessen Adresse eingegeben wurde – TLS-gesichert, mit PIN.
  • Der Hersteller erhält keine Daten. CodeForFire betreibt keinen Dienst, an den etwas fließen könnte.

Personenbezogene Daten entstehen an zwei Stellen: in den Stammdaten der Wehr, die dauerhaft auf dem Gerät liegen, und im Einsatz selbst, der als einzelne Datei gespeichert wird.

Kategorie Enthaltene Angaben Wo gespeichert
Stammdaten: Personal Nachname, Vorname, Funktion, Funkrufname, Telefonnummer masterdata.db
Stammdaten: Fahrzeuge Wache, Funkrufname, Sitzplätze – keine Personen masterdata.db
Funktionen im Einsatz Name, Funkrufname, Abschnitt, Telefonnummer, von/bis Einsatzdatei
Atemschutzüberwachung Name jedes Truppmitglieds mit Position (Truppführer, Truppmann, 2. Truppmann), Druckwerte und Zeiten Einsatzdatei
Einsatztagebuch (ETB) Freitext bis 4000 Zeichen, Von/An, Richtung, „erfasst von“ Einsatzdatei
ETB-Korrekturen jede überschriebene Fassung bleibt erhalten, mit Zeitpunkt und Bearbeiter Einsatzdatei
Einsatzdaten Stichwort, Einsatznummer, Straße und Ortsteil, „abgeschlossen von“ Einsatzdatei
CO-Messprotokoll Name der Bewohnerin oder des Bewohners je Wohnung, ppm-Wert, Status, Schlüssel vorhanden Einsatzdatei
Kräfte Wache, Funkrufname, Stärke als Zahlen (ZF/GF/Mann, AGT), Status, Bemerkung – keine Namen Einsatzdatei
Aufgaben Auftrag, Zuständiger (Freitext), „angelegt von“, „erledigt von“, Zeiten Einsatzdatei
Beteiligte Name, Telefonnummer, Notiz und Aufenthaltsort (z. B. „im RTW …“, mit Uhrzeit) von Personen außerhalb der Feuerwehr (z. B. Eigentümer, Fahrzeughalter, Polizei), die Wohnung, in der sie angetroffen wurden, „angelegt von“ Einsatzdatei
Ausgabeliste Gerät, Name und Telefonnummer der Person, die es erhalten hat, Organisation oder weitere Kontaktangaben (Freitext), Bemerkung, Ausgabe- und Rückgabezeit, „ausgegeben von“, „zurückgenommen von“ Einsatzdatei
Dateien und Anhänge Fotos und PDFs, deren Originaldateiname und „hinzugefügt von“ Einsatzdatei
Änderungsprotokoll wer wann welche Aktion ausgeführt hat Einsatzdatei

Drei Punkte verdienen besondere Aufmerksamkeit:

Das CO-Messprotokoll enthält Daten Dritter. Erfasst werden hier Namen von Personen, die nicht der Feuerwehr angehören und die der Erfassung nicht zugestimmt haben. Die Verarbeitung erfolgt zur Einsatzdurchführung, und genau dieser Teil der Einsatzdatei sollte bei der Festlegung von Löschfristen zuerst betrachtet werden. Der Name ist ein Freitextfeld und kann leer bleiben – die Wohnung lässt sich auch ohne ihn eindeutig über Haus, Stockwerk und Lage kennzeichnen.

Auch die Beteiligten sind Daten Dritter. Hauseigentümer, Fahrzeughalter oder die Ansprechperson der Polizei werden mit Name, Telefonnummer und Notiz erfasst. Diese Angaben stehen bewusst nur in dieser Liste und im PDF-Bericht – das ETB erhält beim Anlegen, Ändern oder Entfernen keinen Eintrag. Ein entfernter Eintrag ist damit aus der Einsatzdatei verschwunden; für Löschfristen gilt dasselbe wie für das CO-Messprotokoll. Für die Ausgabeliste gilt dasselbe: Wer ein Gerät erhalten hat – etwa die Presse oder eine Nachbarwehr –, steht mit Name und Telefonnummer nur dort und im PDF-Bericht, nicht im ETB.

Fotos enthalten mehr als das Bild. Lagebuch entfernt keine EXIF-Metadaten aus angehängten Bildern. Ein mit dem Diensthandy aufgenommenes Foto behält damit unter Umständen GPS-Koordinaten, Aufnahmezeit und Gerätemodell – auch im exportierten PDF-Bericht. Das ist bewusst so: Ort und Zeit eines Fotos von der Einsatzstelle stehen ohnehin im Bericht, und die eigentlich personenbezogenen Daten – Gesichter, Kennzeichen, das Innere einer Wohnung – stecken im Bild selbst, nicht in seinen Metadaten. Ein eingefügtes Bild (Zwischenablage) wird neu als PNG gespeichert und hat danach keine Metadaten mehr. Wer ein Foto ohne Metadaten anhängen will, entfernt sie vorher am Handy oder fügt das Bild ein, statt die Datei anzuhängen.

Eine neue Installation startet mit leeren Stammdaten. Es sind keine Namen, Funkrufnamen, Wachen oder Telefonnummern im Programm enthalten; die einzigen mitgelieferten Beispieldaten sind frei erfunden. Personenbezogene Daten gelangen nur durch einen ausdrücklichen Import in der Stammdatenverwaltung auf das Gerät. Diese Regel ist im Quelltext festgeschrieben und nicht bloß Konvention. Einzelheiten zur Stammdatenpflege stehen in docs/master-data.md.

Eine .lagebuch-Datei ist eine SQLite-Datenbank ohne Verschlüsselung. Sie liegt dort, wo sie beim Speichern abgelegt wurde – Lagebuch gibt keinen Ort vor. Neben der Datei können betriebsbedingt Hilfsdateien mit den Endungen -wal und -shm entstehen.

Anhänge liegen in der Einsatzdatei. Fotos und PDFs werden als Bytes in derselben Datei gespeichert wie alles andere; zu einem Einsatz gehört also genau eine Datei. Wer einen Einsatz kopiert, archiviert oder weitergibt, nimmt damit auch die Anhänge mit. Wer ihn löscht, löscht sie ebenfalls.

Ein entfernter oder ersetzter Anhang wird in der Datei überschrieben, nicht nur als gelöscht markiert. Die Datei wird dadurch aber nicht kleiner: der frei gewordene Platz bleibt reserviert und wird wiederverwendet. Schlägt das Überschreiben in seltenen Fällen fehl, erhält der Lagebuchführer eine Meldung. Die Daten bleiben dann bis zum nächsten Öffnen des Einsatzes in der Datei, ebenso nach einem Absturz genau in diesem Moment. Beim Öffnen überschreibt Lagebuch alle Daten, die zu keinem Anhang mehr gehören.

Ältere Einsatzdateien werden beim Öffnen umgewandelt. Frühere Versionen legten Anhänge in einem Ordner neben der Datei ab, der denselben Namen trug, ergänzt um die Endung .files. Beim ersten Öffnen übernimmt Lagebuch die dort liegenden Anhänge in die Einsatzdatei und entfernt den Ordner. Was in dem Ordner liegt, aber zu keinem Anhang gehört, bleibt dort; ebenso Verknüpfungen, Dateien über der Größengrenze, unlesbare Dateien und Dateien, deren gespeicherte Größe nicht übereinstimmt. Solche Reste sind dann selbst zu löschen.

Alles Weitere liegt in einem einzigen Ordner:

Plattform Ordner
Windows %AppData%\Lagebuch\
Linux ~/.config/Lagebuch/
macOS ~/.config/Lagebuch/

Unter macOS ist das ~/.config und nicht ~/Library/Application Support: dorthin zeigt unter Unix der plattformübergreifend verwendete Standardpfad für Anwendungsdaten.

Datei oder Ordner Inhalt
masterdata.db die Stammdaten der Wehr, einschließlich der Namen und Telefonnummern
recent.json die zuletzt geöffneten Einsatzdateien mit vollständigem Pfad
last-save-folder.json der zuletzt zum Speichern verwendete Ordner
last-pdf-export.json der zuletzt für den PDF-Export verwendete Ordner
last-connection.json die zuletzt erfolgreich verbundene Gegenstelle, mit Stichwort des Einsatzes, Zeitpunkt und PIN, damit ein Wiederverbinden im Einsatz ohne Nachfragen geht; auf der Startseite mit „Letzte Verbindung vergessen“ löschbar (ältere Versionen: last-join-host.json, nur die Gegenstelle)
trust.json die gespeicherten Schlüssel-Fingerabdrücke der Gegenstellen
host-key.pem der private Schlüssel, mit dem dieses Gerät sich beim Freigeben ausweist; entsteht bei der ersten Freigabe, unter Linux und macOS nur für den eigenen Benutzer lesbar
attachment-cache/ Kopien der Anhänge, die ein verbundenes Gerät vom Gastgeber geladen hat
regions/ die heruntergeladenen Kartenpakete: Karte, Hydranten und Adressen eines Landkreises aus OpenStreetMap, Geländehöhen aus dem DGM5 der Bayerischen Vermessungsverwaltung; keine Einsatzdaten
crashes/ Absturzberichte, höchstens fünf, ohne Fehlertexte und ohne Einsatzdaten (siehe unten)

Beim Öffnen eines Anhangs legt Lagebuch zusätzlich eine Arbeitskopie im temporären Verzeichnis des Systems an, unterhalb von lagebuch/. Diese Arbeitskopien löscht Lagebuch beim nächsten Programmstart; eine Kopie, die dann noch in einem Betrachter geöffnet ist, bleibt bis zu einem späteren Start liegen.

Die Android-App speichert ausschließlich im app-eigenen Bereich: nichts auf der SD-Karte, nichts in frei zugänglichen Ordnern. Einsatzdateien, Stammdaten, der Anhang-Zwischenspeicher und die Exportdateien liegen dort. Beim Deinstallieren der App entfernt Android all diese Daten.

Von selbst: nichts. Es gibt im gesamten Programm genau fünf Wege, auf denen Daten das Gerät verlassen können, und alle fünf werden von der Bedienerin oder dem Bediener ausgelöst:

  1. Die Mehrgeräte-Verbindung. Sie richtet sich an genau die Adresse, die im Verbindungsdialog eingegeben wurde. Einzelheiten im nächsten Abschnitt.
  2. Angeklickte Links. Wetter, Karten oder Hydrantenplan aus den Stammdaten werden an den Standardbrowser des Systems übergeben. Lagebuch selbst ruft die Seite nicht ab.
  3. Der PDF-Bericht. Er wird dorthin geschrieben, wo er im Speicherdialog abgelegt wird. Was danach mit ihm geschieht, liegt bei der Wehr – er enthält den vollständigen Einsatz einschließlich der eingebetteten Anhänge.
  4. Der Absturzbericht unter Android. Erst wenn auf der Startseite TEILEN angetippt wird, geht er an das Teilen-Menü von Android; wohin, bestimmt die dort gewählte App. Er enthält keine Fehlertexte und keine Einsatzdaten.
  5. Kartenpakete. Unter Stammdaten → Karten lädt LISTE LADEN das Verzeichnis der Kartenpakete aus CodeForFire/lagebuch-geodata und HERUNTERLADEN ein Paket samt seiner Gebietsgrenze von GitHub (raw.githubusercontent.com, github.com und dessen Download-Server). Dabei sieht GitHub die IP-Adresse des Geräts und welches Paket geladen wird – keine Einsatzdaten. Lagebuch prüft jedes Paket vor dem Entpacken gegen die Prüfsumme im Verzeichnis. Danach zeichnet Lagebuch Karte und Hydranten ausschließlich aus dem Paket auf dem Gerät, und die Adresssuche auf der Lagekarte fragt nur das Paket, keinen Suchdienst; niemand außerhalb des Geräts erfährt, wo ein Einsatz liegt.

Nicht vorhanden sind: Nutzungsstatistiken, automatisch versandte Absturzberichte, Updateprüfungen, Werbe- oder Analysebibliotheken sowie Schriftarten oder Kartenkacheln, die während der Arbeit von fremden Servern nachgeladen werden.

Lagebuch schreibt keine Protokolldateien. Das ist für den Datenschutz von Vorteil – es entsteht kein zweiter Ort mit personenbezogenen Daten.

Die eine Ausnahme ist ein Absturzbericht: Beendet ein unerwarteter Fehler das Programm, legt Lagebuch im Ordner crashes/ im Programmordner (unter Android im app-eigenen Bereich) eine kleine Textdatei an. Sie enthält die Programmversion, den Zeitpunkt, das Betriebssystem und die Art des Fehlers mit der Stelle im Programmcode – keine Fehlertexte und keine Einsatzdaten, denn gerade Fehlertexte können Namen oder Dateipfade enthalten. Beim nächsten Start weist die Startseite auf den Bericht hin, damit er einer Fehlermeldung beigelegt werden kann. Unter Android ist der app-eigene Bereich ohne Root nicht erreichbar; dort bietet die Startseite den Bericht stattdessen über TEILEN an. Lagebuch behält die fünf neuesten Berichte und löscht ältere selbst.

Ein Gerät kann einen Einsatz im Netzwerk freigeben, andere Geräte treten ihm bei. Der Gastgeber führt den maßgeblichen Stand; es gibt keinen dritten Rechner und keinen Dienst dazwischen.

Transport. Fester Port 5859, ausschließlich HTTPS (TLS 1.2 oder 1.3, je nach Betriebssystem). Einen unverschlüsselten Zugang gibt es nicht.

Zertifikat. Für jede Freigabe wird ein eigenes Zertifikat erzeugt: ECDSA P-256, SHA-256, rund 24 Stunden gültig. Es wird nie auf die Festplatte geschrieben und beim Beenden der Freigabe verworfen. Der Schlüssel darin bleibt dagegen derselbe: Er entsteht bei der ersten Freigabe und liegt in host-key.pem. So erkennen beigetretene Geräte den Gastgeber auch nach einem Neustart oder bei einem neuen Einsatz wieder.

Kennung. Aus dem Schlüssel ergibt sich eine zwölfstellige Kennung, etwa 7K2Q-M9XD-4HPA. Der Gastgeber zeigt sie an, wenn man auf seine PIN klickt. Einen Schlüssel mit derselben Kennung zu errechnen, würde Jahre dauern; stimmt die Kennung, der Schlüssel aber nicht, weist das Programm die Verbindung ohne Rückfrage ab.

Vertrauen. Beim ersten Verbinden merkt sich das beitretende Gerät den SHA-256-Fingerabdruck des Schlüssels der Gegenstelle in trust.json. Meldet sich unter derselben Adresse später ein anderer Schlüssel – ein anderer Rechner, ein verlorener host-key.pem oder jemand, der sich dazwischenschaltet –, bricht die Verbindung ab und die Meldung nennt dessen Kennung. Erst wenn sie mit der Anzeige am Gastgeber übereinstimmt, vertraut „Kennung stimmt – vertrauen“ genau diesem Schlüssel. Zeigt der Gastgeber keine Kennung, läuft dort eine ältere Version; die Meldung sagt das. Fingerabdrücke aus älteren Versionen werden beim nächsten Verbinden nur dann still übernommen, wenn die Gegenstelle noch dasselbe Zertifikat vorlegt, sonst fragt das Programm nach der Kennung. Eine Möglichkeit, ein beliebiges Zertifikat zu akzeptieren, gibt es nicht.

PIN. Der Beitritt verlangt eine vierstellige PIN, die für jede Freigabe neu und kryptografisch zufällig erzeugt und auf dem Gastgeber nur im Arbeitsspeicher gehalten wird; ein beigetretenes Gerät merkt sie sich in last-connection.json. Sie wird bei jeder Anfrage mitgeschickt. Der Gastgeber zählt falsche Eingaben über alle Gegenstellen hinweg: Nach zehn Fehlversuchen nimmt er keine neuen Geräte mehr an, auch nicht mit der richtigen PIN, und meldet das im Einsatz. Erst „Neue PIN“ öffnet den Beitritt wieder. Bereits verbundene Geräte arbeiten währenddessen weiter.

Was übertragen wird. Nach jeder Änderung erhält jedes verbundene Gerät den vollständigen Stand des Einsatzes: Einsatzdaten, das gesamte ETB einschließlich der aufbewahrten Korrekturfassungen, Funktionen mit Namen und Telefonnummern, Kräfte, Atemschutztrupps mit den Namen der Truppmitglieder, Aufgaben, Beteiligte mit Namen und Telefonnummern, die Ausgabeliste mit Namen und Telefonnummern, CO-Messprotokoll, Änderungsprotokoll und die Liste der Anhänge. Anhänge selbst werden nur auf Anforderung übertragen (höchstens 25 MB je Datei).

Der Gastgeber gibt seine Stammdaten weiter. Damit beide Geräte dieselben Fahrzeuge, Funkrufnamen und Einsatzzeiten verwenden, überträgt der Gastgeber seinen vollständigen Stammdatensatz – einschließlich der Personalliste mit Namen und Telefonnummern – an jedes beitretende Gerät. Das beitretende Gerät speichert diesen Satz nicht dauerhaft; er gilt nur für die Dauer der Sitzung, und danach arbeitet das Gerät wieder mit seinen eigenen Stammdaten. Wichtig für die Bewertung: Die Personalliste ist ein dauerhafter Datenbestand der ganzen Wehr, kein einzelnes Ereignis – eine weitergegebene PIN öffnet also mehr als den Einsatz, für den sie ausgegeben wurde.

Anhänge auf dem beitretenden Gerät. Geladene Anhänge liegen im Ordner attachment-cache/, solange das Gerät mit dem Einsatz verbunden ist. Beim Verlassen des Einsatzes löscht Lagebuch sie. Endet das Programm vorher durch einen Absturz, löscht es sie beim nächsten Start. Wird es danach nicht mehr gestartet, bleiben sie liegen; deshalb steht der Ordner weiter auf der Löschliste unten.

Reichweite. Der Gastgeber nimmt Verbindungen auf allen Netzwerkschnittstellen des Geräts an; eine Einschränkung auf bestimmte Adressbereiche findet nicht statt. Die im Programm angezeigte Adresse ist nur ein Vorschlag, den man am beitretenden Gerät eintragen kann. Praktisch heißt das: Erreichbarkeit im Netz plus PIN ist die gesamte Zugangskontrolle. Im vorgesehenen Einsatzfall – die eigenen Geräte im eigenen WLAN – ist das angemessen; in einem offenen Netz ist es das nicht. Theoretisch funktioniert jedes Netz, über das die Geräte den Gastgeber erreichen, etwa ein VPN wie Tailscale; getestet ist das nicht.

Android kann beitreten, aber selbst keinen Einsatz freigeben. Die App ist ein Begleitgerät.

  • Datenhaltung ausschließlich lokal, ohne Konto und ohne Serverdienst.
  • Transportverschlüsselung mit TLS und Fingerabdruck-Bindung an die Gegenstelle, ohne Rückfallebene auf eine ungeprüfte Verbindung.
  • PIN-Pflicht beim Beitritt, mit Bremse gegen systematisches Durchprobieren: nach zehn Fehlversuchen ist der Beitritt gesperrt, bis eine neue PIN erzeugt wird.
  • Anhänge nur als JPEG, PNG, GIF, WebP oder PDF; Dateiname und Dateityp werden geprüft, damit sich keine ausführbare Datei als Bild ausgeben kann. Dateinamen werden bereinigt, Pfadangaben entfernt, die Länge begrenzt.
  • Beim Öffnen eines Anhangs prüft das Programm, dass es sich um eine echte Datei im eigenen Arbeitsverzeichnis handelt, bevor es sie an das Betriebssystem übergibt.
  • Nachvollziehbare Änderungshistorie: Korrekturen im ETB überschreiben nichts.
  • Keine Telemetrie, keine Protokolldateien, keine Drittanbieter-Dienste.
  • Überprüfbare Installationsdateien: zu jedem Release gehören SHA-256-Prüfsummen und ein Sigstore-Herkunftsnachweis, siehe Downloads prüfen.
  • Festplattenverschlüsselung des ELW-Laptops und der Tablets. Die Einsatzdatei und masterdata.db sind unverschlüsselt; der Schutz der Daten im Ruhezustand ist Aufgabe des Betriebssystems (BitLocker, LUKS, FileVault, Android-Geräteverschlüsselung).
  • Bildschirmsperre und Zugang zum Gerät. Wer am Laptop sitzt, sieht die Stammdaten.
  • Ablage und Archivierung der Einsatzdateien, einschließlich Sicherung und Zugriffsschutz auf dem Ablageort. Beides betrifft nur noch die eine Datei.
  • Löschfristen für Einsatzdateien, PDF-Berichte und die Personalliste festlegen und umsetzen; siehe Aufbewahren und Löschen.
  • Umgang mit dem PDF-Bericht, der den vollständigen Einsatz enthält: Versandweg, Empfängerkreis, Ablage.
  • Weitergabe der PIN im Einsatz: an wen sie gegeben wird und dass sie nicht über den Einsatz hinaus verwendet wird.
  • Auswahl der Netzverbindung für den Mehrgerätebetrieb: eigenes WLAN, nicht das offene Gäste-WLAN der Einsatzstelle. Wer stattdessen ein VPN wie Tailscale einsetzt, betritt ungetestetes Gelände.

Die folgenden Punkte sollen die Bewertung erleichtern; sie ersetzen die Prüfung durch die oder den zuständigen Datenschutzbeauftragten nicht.

Verantwortlicher im Sinne von Art. 4 Nr. 7 DSGVO ist die Feuerwehr beziehungsweise ihr Träger, in der Regel die Kommune. Die Entscheidung über Zwecke und Mittel der Verarbeitung trifft die Wehr, nicht CodeForFire.

Keine Auftragsverarbeitung. CodeForFire stellt ein Programm zur Verfügung und betreibt keinen Dienst. Es gibt keine Schnittstelle, über die personenbezogene Daten an CodeForFire gelangen könnten, und folglich keine Verarbeitung im Auftrag nach Art. 28 DSGVO. Ein Auftragsverarbeitungsvertrag ist daher nicht erforderlich – es gibt keinen Auftragsverarbeiter. Auch eine Drittlandsübermittlung findet nicht statt.

Rechtsgrundlage. Die Einsatzdokumentation ist für Feuerwehren regelmäßig eine gesetzlich vorgesehene Aufgabe; in Bayern ergibt sie sich aus dem Bayerischen Feuerwehrgesetz und dem Satzungsrecht des Trägers. Welche Rechtsgrundlage konkret herangezogen wird, bestimmt der Träger.

Verzeichnis von Verarbeitungstätigkeiten (Art. 30 DSGVO). Die Bausteine dafür stehen auf dieser Seite:

Angabe im Verzeichnis Abschnitt hier
Kategorien betroffener Personen und Daten Welche Daten verarbeitet Lagebuch?
Speicherorte Wo liegen die Daten?
Empfänger und Übermittlungen Was das Gerät verlässt
Technische und organisatorische Maßnahmen Technische und organisatorische Maßnahmen
Löschfristen Aufbewahren und Löschen – die Fristen selbst legt der Träger fest

Betroffenenrechte in der Praxis. Auskunft und Berichtigung erfolgen über die Einsatzdatei und die Stammdaten; Löschung bedeutet, die betreffenden Einträge oder die Datei zu entfernen. Eine Besonderheit ist ausdrücklich zu benennen: Korrekturen im Einsatztagebuch überschreiben die Vorfassung nicht, sondern bewahren sie mit Zeitpunkt und Bearbeiter auf. Das ist für die Dokumentationsintegrität gewollt – ein Einsatztagebuch, dessen Einträge sich spurlos ändern lassen, wäre als Nachweis wertlos. Berichtigung heißt dort also Ergänzung, nicht Überschreiben. Wer eine Vorfassung tatsächlich beseitigen will, muss den gesamten Eintrag löschen.

Lagebuch hat keine Funktion „alle Daten löschen“, und eine Einsatzdatei lässt sich auch nicht aus dem Programm heraus löschen. Das Entfernen geschieht im Dateimanager des Systems. Vollständig ist es erst, wenn folgende Punkte abgearbeitet sind.

Windows, Linux, macOS

  1. Jede .lagebuch-Datei (ältere Versionen speicherten .fwincident), an allen Orten, an denen Einsätze gespeichert wurden (Anhaltspunkte liefern recent.json und last-save-folder.json), samt etwaiger -wal- und -shm-Dateien.
  2. Bei Einsatzdateien, die noch nie in einer neueren Version geöffnet wurden, den gleichnamigen .files-Ordner. Auch ein beim Umwandeln zurückgebliebener Rest (siehe „Die Einsatzdatei“) liegt dort.
  3. Aus dem Programmordner (%AppData%\Lagebuch\ beziehungsweise ~/.config/Lagebuch/): masterdata.db, recent.json, last-save-folder.json, last-pdf-export.json, last-connection.json, last-join-host.json (von älteren Versionen), trust.json und den Ordner attachment-cache/.
  4. Exportierte PDF-Berichte an ihren Ablageorten (den zuletzt verwendeten nennt last-pdf-export.json).
  5. Den Ordner lagebuch im temporären Verzeichnis des Systems. Lagebuch leert ihn bei jedem Start selbst; übrig sind darin normalerweise nur die Arbeitskopien seit dem letzten Start.

Danach ist der Programmordner selbst entbehrlich; Lagebuch legt ihn beim nächsten Start leer wieder an.

Android

Die App deinstallieren. Damit entfernt Android sämtliche oben genannten Daten, weil alles im app-eigenen Bereich liegt.

Wichtig: Sicherungskopien, Netzlaufwerke und USB-Sticks, auf denen Einsatzdateien abgelegt wurden, erfasst das nicht. Sie gehören in das Löschkonzept der Wehr.

Vollständigkeit ist hier wichtiger als ein guter Eindruck.

  • Die Installationspakete sind noch nicht signiert. Betriebssysteme warnen deshalb beim ersten Start. Die SignPath Foundation hat das Projekt abgelehnt; eine Bewerbung bei OSSign ist frühestens im Februar 2027 möglich, weil dort ein Mindestalter von sechs Monaten vorausgesetzt wird. Bis dahin sind Prüfsumme und Herkunftsnachweis der belastbare Ersatz. Einzelheiten in der Roadmap.
  • Die erste Verbindung zu einer Gegenstelle ist ungeprüft. Der Fingerabdruck wird beim ersten Kontakt übernommen und ab dann erzwungen. Abgeglichen wird die Kennung erst, wenn sie sich ändert; beim ersten Mal fragt das Programm nicht danach. Wer genau in diesem Moment im selben Netz sitzt und sich aktiv dazwischenschaltet, würde statt des Gastgebers übernommen. Das ist eine bewusste Entscheidung: Synchronisiert wird im eigenen Netz des ELW, mit wenigen bekannten Geräten, und eine Pflichtabfrage bei jedem neuen Gerät würde im Einsatz weggeklickt, statt verglichen – und damit auch die Warnung bei einem geänderten Schlüssel entwerten, die wirklich etwas aufdeckt. Wer das Risiko ausschließen will, verbindet neue Geräte nur in einem Netz, in dem kein fremdes Gerät sein kann.
  • Die PIN hat vier Stellen. Das genügt, weil nach zehn Fehlversuchen der Beitritt gesperrt bleibt, bis jemand eine neue PIN erzeugt: Ein Angreifer hat so höchstens zehn Versuche unter 10.000 je Erneuerung. Er kann den Beitritt aber absichtlich sperren; neue Geräte kommen dann erst nach „Neue PIN“ hinein, verbundene arbeiten weiter.
  • Erreichbarkeit plus PIN ist die gesamte Zugangskontrolle. Wer beides hat, darf am Einsatz alles ändern.
  • Der Name in „Wer dokumentiert?“ wird nicht überprüft. Er dient der Zuordnung in der Anzeige, nicht der Berechtigung. Ein verbundenes Gerät kann einen beliebigen Namen angeben.
  • EXIF-Daten in angehängten Fotos werden nicht entfernt – siehe oben. Das ist eine bewusste Entscheidung, keine offene Aufgabe (Issue #384).
  • Das Dateiformat ist vor Version 1.0 nicht eingefroren. Ältere Dateien werden beim Öffnen migriert; ab 1.0 gilt die Zusage, dass eine Datei dauerhaft lesbar bleibt.
  • Es gibt keine Protokolldateien – zum Schutz der Daten gut, zur Fehlersuche schlecht. Nach einem Absturz bleibt nur ein Absturzbericht ohne Fehlertexte (siehe oben); was vor dem Absturz geschah, zeigt er nicht.

Dieselben Punkte stehen – auf Englisch und aus der Sicht eines Sicherheitsforschers – auch in SECURITY.md.

  • Fragen zum Datenschutz, zur Installation oder zum Betrieb im ELW gerne unter Fragen & Antworten stellen.
  • Sicherheitslücken bitte nicht öffentlich melden, sondern vertraulich über SECURITY.md.
  • Fehler oder Lücken in dieser Seite: bitte ein Issue öffnen. Eine Seite, der ein Datenschutzbeauftragter nicht vertrauen kann, nützt niemandem.