LarasDesk · Impressum

LarasDesk-Apps – Datenschutzerklärung

Stand: 2026-09-15

Diese Erklärung auf Englisch lesen

Diese Datenschutzerklärung gilt für alle Android-Apps von LarasDesk. Jede App beginnt mit einem Kurzprofil: was sie tut, was sie speichert, wo das gespeichert wird, was das Gerät verlässt und welche Berechtigungen sie nutzt. Danach folgen die Einzelheiten dazu, welche Daten verarbeitet werden, wo sie bleiben und wann überhaupt etwas das Gerät verlässt. Unterscheiden sich die Apps in einem Punkt, ist das ausdrücklich benannt.

1. Verantwortlicher

Verantwortlich für die Datenverarbeitung im Sinne der DSGVO ist:

Lara Knuth — Dresden AI Insights
Kurhausstr. 16, 01259 Dresden, Deutschland
Tel.: +49 1567 8333414
E-Mail: support@larasdesk.com
USt-IdNr.: DE458852148
Umsatzsteuerbefreit als Kleinunternehmerin gemäß § 19 UStG.

2. Für welche Apps diese Erklärung gilt

Nur die hier aufgeführten Apps sind erfasst. Eine App, die nicht in dieser Liste steht, hat eine eigene Erklärung. Kommt eine weitere App hinzu, wird sie hier ergänzt, bevor sie erscheint.

3. Was welche App überträgt — Überblick

Dieser Abschnitt ist die Kurzfassung. Die Einzelheiten stehen in den Abschnitten 5 bis 9.

Keine der vier Apps hat ein Konto, eine Anmeldung, Werbung, LarasDesk-eigene Analytics, Tracking-Cookies, eine Werbe-ID-Nutzung oder ein automatisches Crash-Reporting an LarasDesk. Die von Google selbst erhobenen ML-Kit-SDK-Metriken bei LarasScan sind in Abschnitt 5 offengelegt. LarasDesk bildet keine Nutzungsprofile.

4. Gemeinsame Grundsätze

5. LarasScan

Funktion, Speicherorte und Berechtigungen im Überblick

Funktion
Belege mit der Gerätekamera erfassen, den Text per Texterkennung auf dem Gerät (Google ML Kit) auslesen, daraus Datum, Händler, Betrag, MwSt-Satz und Kategorie ableiten, Belege lokal verwalten und durchsuchen sowie als CSV-/DATEV-Datei, Bild, PDF oder vollständiges JSON-Backup ausgeben.
Was die App speichert
Belegbilder, Seitenbilder und Scanner-PDFs, den erkannten OCR-Text, die daraus abgeleiteten Belegfelder, eigene Notizen, eine SHA-256-Hashkette je Beleg, die lokalen DATEV-Einstellungen (Berater- und Mandantennummer), die gewählte App-Sprache und — nur während eines laufenden Backup-Imports — ein lokales Bereinigungsjournal. Hinzu kommen ein lokales Datenfluss-Log und die Diagnosezustände aus Abschnitt 9: ein wartender Bericht mit Fehler-Fingerprint und Erstellungszeitpunkt, unterdrückte Fingerprints und die Berichtseinstellung.
Wo gespeichert wird
Ausschließlich auf dem Gerät: Datensätze, Verweise, Datenfluss-Log und Diagnosezustände aus Abschnitt 9 in der lokalen App-Datenbank (IndexedDB), App-Sprache und Bereinigungsjournal im WebView-Speicher (localStorage), Bilder und PDFs als Dateien im privaten App-Speicher sowie temporäre Exportkopien im privaten Cache-Ordner exports/. Es gibt kein Nutzerkonto, keinen LarasDesk-Server für Beleginhalte und kein Android-System-Backup.
Was das Gerät verlässt
Auf Ihre Aktion: Dateien, die Sie über das Android-Share-Sheet weitergeben, und ein optionaler Diagnose-Bericht, den Sie vorher vollständig sehen (Abschnitt 9). Ohne Ihr Zutun: die technisch notwendigen Verbindungsdaten der Modul- und Ressourcen-Abrufe von Google Play Services für Texterkennung und Document Scanner — die Module selbst kommen dabei auf das Gerät und gehen nicht von ihm weg — sowie die Betriebs- und Nutzungsmetriken, die das ML-Kit-SDK an Google sendet. Nach dem ersten initialisierten Diagnose-Versand kann Firebase App Check sein Integritätstoken automatisch aktualisieren. Beleginhalte werden nicht automatisch übertragen.
Berechtigungen
android.permission.INTERNET. Eine eigene Kamera-Berechtigung deklariert LarasScan nicht — die Aufnahme läuft im Document Scanner von Google Play Services.

Verarbeitete Daten

LarasScan verarbeitet folgende Daten ausschließlich lokal auf dem Gerät:

Lokale Speicherung

Belegdatensätze, OCR-Text, abgeleitete Felder, Hashwerte und lokale Dateiverweise werden in IndexedDB gespeichert. Native Belegbilder, Seitenbilder und Scanner-PDFs liegen als Dateien im privaten App-Speicher beziehungsweise App-Cache und werden über ihre Pfade referenziert. LarasScan überträgt diese Inhalte nicht automatisch. Nur eine bewusste Nutzeraktion kann ausgewählte OCR-Texte, Belegbilder, Scanner-PDFs, CSV-/DATEV-Dateien oder ein vollständiges JSON-Backup an das Android-Share-Sheet übergeben. Das vollständige Backup ist eine lesbare, nicht zusätzlich verschlüsselte JSON-Datei; es enthält Belegfelder, Notizen, OCR-Text, Hashwerte sowie Bild- und PDF-Bytes in Base64-Darstellung.

Für eine dateibasierte Share-Aktion schreibt die App die benötigte Klartextkopie zunächst in ihren privaten Cacheordner exports/. Vor einem späteren CSV-/DATEV-, Bild-, PDF- oder Diagnose-Dateiexport versucht sie, den bisherigen Exportordner zu entfernen. Beim JSON-Backup versucht sie etwa 30 Sekunden nach der Übergabe, die konkrete Cachedatei zu löschen; ein späteres Backup bereinigt eine fehlgeschlagene Altlöschung nicht automatisch.

Modulbereitstellung und SDK-Metriken: Google ML Kit

Für die Texterkennung deklariert LarasScan das OCR-Modell als Google-Play-Services-Abhängigkeit. Google Play Services kann es deshalb nach der Installation aus Google Play automatisch auf das Gerät laden, noch bevor Sie OCR erstmals aufrufen. Die Bibliotheken, Modelle und weiteren Ressourcen des Document Scanner werden dynamisch vor der ersten Nutzung beziehungsweise bei Bedarf geladen. Diese Verbindungen laufen direkt zwischen Gerät und Google und werden nicht von LarasDesk betrieben. Einzelheiten beschreibt Google in der Android-Dokumentation zur Texterkennung, der Dokumentation zum Document Scanner und den ML-Kit-Nutzungsbedingungen.

Nach Googles ML-Kit-Offenlegung für Android senden ML-Kit-SDKs Betriebs- und Nutzungsdiagnostik an Google, zum Beispiel Geräte- und App-Informationen, Geräte- oder Installationskennungen, Leistungsmetriken, API-Konfiguration, Feature-/Ereignisdaten und Fehlerdaten. Google gibt an, dass diese Daten während der Übertragung verschlüsselt werden und für Diagnose, Missbrauchsvermeidung und Verbesserung der Dienste verwendet werden. LarasScan erhält diese SDK-Metriken nicht und lädt keine Belegbilder oder OCR-Texte zu LarasDesk hoch; es gibt keine LarasDesk-eigenen Nutzungs-Analytics. Ergänzend gilt die Datenschutzerklärung von Google.

Die App protokolliert im Bereich „Privacy Status“ / „Network Log“, dass der Google-Play-Services-Pfad vor einem Scanner- oder OCR-Aufruf angesprochen wurde. Sie beobachtet jedoch weder den automatischen Modellabruf nach der Play-Installation noch einen tatsächlichen Download oder realen Verbindungsstatus. Der Eintrag ist ein transparenter Hinweis auf den möglichen Modulpfad, kein Netzwerkmonitor.

Berechtigungen

6. LarasMemo

Funktion, Speicherorte und Berechtigungen im Überblick

Funktion
Sprachmemos aufnehmen, sie auf dem Gerät in Text umwandeln, das Transkript bearbeiten und durchsuchen, eine Markdown-Vorschau erzeugen sowie alle Memos als ZIP-Datei sichern und wieder einlesen.
Was die App speichert
Die Sprachaufnahme (WAV-Datei und PCM-Segmente), ein Wiederherstellungs-Manifest je Aufnahme, den Transkript-Text, Memo-Metadaten wie Titel, Dauer, Zeitpunkt, Sprache und Status, die gewählte App-Sprache, ein lokales Datenfluss-Log und die Diagnosezustände aus Abschnitt 9: ein wartender Bericht mit Fehler-Fingerprint und Erstellungszeitpunkt, unterdrückte Fingerprints und die Berichtseinstellung. Die Markdown-Vorschau wird nur vorübergehend aus den Memo-Daten erzeugt und nicht als eigener dauerhafter Datensatz gespeichert.
Wo gespeichert wird
Ausschließlich auf dem Gerät: Memos, Transkripte, Metadaten, Datenfluss-Log und Diagnosezustände aus Abschnitt 9 in der lokalen App-Datenbank (IndexedDB, Datenbankname voicedesk), die App-Sprache im WebView-Speicher (localStorage), Audiodateien unter recordings/ und Wiederherstellungs-Manifeste als separate Dateien im privaten App-Speicher. Kein Konto, kein Cloud-Speicher, kein Android-System-Backup.
Was das Gerät verlässt
Auf Ihre Aktion: beim Bezug des lokalen Sprachpakets die technisch notwendigen Verbindungsdaten der Anfrage (Abschnitt 6) — das Sprachpaket selbst kommt dabei auf das Gerät —, von Ihnen geteilte Dateien und ein optionaler Diagnose-Bericht (Abschnitt 9). Ohne Ihr Zutun: Nach dem ersten initialisierten Diagnose-Versand kann Firebase App Check sein Integritätstoken automatisch aktualisieren. Sprachaufnahmen und Transkripte werden nicht übertragen — die Spracherkennung läuft vollständig offline auf dem Gerät.
Berechtigungen
RECORD_AUDIO, MODIFY_AUDIO_SETTINGS, FOREGROUND_SERVICE und FOREGROUND_SERVICE_MICROPHONE, POST_NOTIFICATIONS, INTERNET sowie FOREGROUND_SERVICE_DATA_SYNC aus der Play-Asset-Delivery-Bibliothek.

Verarbeitete Daten

LarasMemo verarbeitet folgende Daten ausschließlich lokal auf dem Gerät:

Aufnahme über einen Vordergrund-Dienst

Auf Android läuft die Aufnahme in einem nativen Vordergrund-Dienst (MemoRecordingService, im Manifest mit android:foregroundServiceType="microphone" und android:exported="false" deklariert). Beim Laden des App-Plugins wird der Dienst intern gebunden, damit er bereitsteht; dadurch beginnen weder der Vordergrundbetrieb noch ein Mikrofonzugriff. Erst das Antippen der Aufnahme-Schaltfläche startet die Aufnahme-Sitzung, schaltet den Dienst in den Vordergrund und aktiviert das Mikrofon. Es gibt keinen Aufnahmestart beim Gerätestart und keinen Start durch andere Apps.

Vor der ersten Aufnahme fragt LarasMemo zur Laufzeit nach der Mikrofon-Berechtigung und ab Android 13 zusätzlich nach der Benachrichtigungs-Berechtigung. Wird eine der angeforderten Berechtigungen abgelehnt, startet keine Aufnahme; der bereits intern gebundene Dienst wird nicht in den Vordergrund versetzt und das Mikrofon nicht aktiviert. Während der Aufnahme zeigt Android eine dauerhafte Benachrichtigung („LarasMemo nimmt auf“) mit einer Aktion „Stoppen“; der Kanal larasmemo_recording ist stumm und mit niedriger Priorität angelegt.

Transkription auf dem Gerät

Die Sprache-zu-Text-Umwandlung läuft vollständig auf dem Gerät. LarasMemo bindet dafür die freie Bibliothek whisper.cpp (MIT-Lizenz) als mitkompilierten nativen Code ein (libwhisper_jni.so, Architektur arm64-v8a). Es wird keine Cloud-Spracherkennung angesprochen — kein Google Speech-to-Text, keine Web-Speech-API, kein LarasDesk-Server. Audio und Transkript verlassen dabei das Gerät nicht.

Lokale Speicherung

Memos, Transkripte und Metadaten werden in der lokalen Datenbank der App gespeichert (IndexedDB über Dexie; Datenbankname voicedesk). Die native WAV-Datei, die PCM-Segmente und das finalisierte Wiederherstellungs-Manifest bleiben zusätzlich im privaten App-Speicher. Aus Speicherschutz-Gründen wird der Audioinhalt einer nativen Aufnahme nur bis zu einer Länge von fünf Minuten zusätzlich in die App-Datenbank geladen; längere Aufnahmen bleiben ausschließlich als native Dateien erhalten. LarasMemo bietet derzeit keine Funktion zum Löschen eines einzelnen Memos oder seiner nativen Dateien. Vollständig entfernen lassen sich diese Daten durch Leeren der App-Daten in den Android-Einstellungen oder durch Deinstallation.

Die App bietet einen eigenen Backup-Export als ZIP-Datei sowie einen Import. Das ZIP enthält Transkripte, Metadaten und eine vorgerenderte Markdown-Kopie; Audio wird nur für Memos aufgenommen, deren Audioinhalt zusätzlich in der App-Datenbank vorliegt. Der Import liest ausschließlich die Datei, die im Dateiauswahl-Dialog ausgewählt wurde.

Bezug des lokalen Sprachpakets

Das Sprachpaket wird erst auf Knopfdruck geladen („Lokales Sprachpaket laden“). Es gibt zwei Wege:

In beiden Fällen wird nur eine Modelldatei angefordert; keine Audiodaten, Transkripte, Suchbegriffe, Memo-Metadaten oder Telemetrie werden hochgeladen. Für die Auslieferung werden technisch notwendige Verbindungsdaten übertragen: insbesondere öffentliche IP-Adresse, Zeitpunkt, angeforderter Modellpfad, übliche HTTP-Header sowie Verbindungs- oder Laufzeitinformationen. Die Empfänger können diese Daten einschließlich einer aus der IP abgeleiteten ungefähren Position nach ihren eigenen Bestimmungen protokollieren. Nach dem Download arbeitet die Transkription ohne Netzverbindung.

Berechtigungen

LarasMemo fordert keine weiteren gefährlichen Laufzeitberechtigungen für Kontakte, Standortdienste, Kalender, Telefonstatus oder Fotobibliothek an.

7. LarasCalendar

Funktion, Speicherorte und Berechtigungen im Überblick

Funktion
Termine aus einer ICS-Datei oder aus eingefügtem ICS-Text importieren, Termine manuell anlegen und bearbeiten, sie in Tages-, Wochen- und Monatsansicht sowie über die Suche nutzen, Serientermine nach RFC 5545 auswerten, Auswertungen zur eigenen Terminlast anzeigen, Erinnerungen als lokale Benachrichtigung stellen und die Daten als ICS-Datei oder vollständiges JSON-Backup ausgeben.
Was die App speichert
Terminfelder wie Titel, Ort, Teilnehmer, Start- und Endzeit, Ganztägig-Status, Notizen und Serienregeln, Erinnerungen, Anhang-Metadaten und die Anhänge selbst, die gewählte App-Sprache sowie die Diagnosezustände aus Abschnitt 9: ein wartender Bericht mit Fehler-Fingerprint und Erstellungszeitpunkt, unterdrückte Fingerprints und die Berichtseinstellung. Statistiken werden bei der Anzeige aus den Termindaten berechnet und nicht separat gespeichert.
Wo gespeichert wird
Ausschließlich auf dem Gerät: Termine, Erinnerungen, Anhang-Metadaten und Diagnosezustände aus Abschnitt 9 in der lokalen App-Datenbank (IndexedDB, Datenbankname kalenderecho), die App-Sprache im WebView-Speicher (localStorage) und Anhänge als Dateien im privaten App-Sandboxspeicher. Kein Konto, kein Cloud-Speicher, kein Android-System-Backup.
Was das Gerät verlässt
Keine von der App initiierte Netzwerkübertragung. LarasCalendar deklariert keine Internet-Berechtigung und kann deshalb technisch keine Netzwerkverbindung aufbauen. Daten können das Gerät nur verlassen, wenn Sie eine Export-, Backup- oder Diagnosebericht-Datei selbst über das Android-Share-Sheet weitergeben.
Berechtigungen
POST_NOTIFICATIONS nur für Erinnerungen, dazu USE_EXACT_ALARM beziehungsweise SCHEDULE_EXACT_ALARM, RECEIVE_BOOT_COMPLETED und WAKE_LOCK für die pünktliche Zustellung nach einem Neustart. Kein Internet, kein Zugriff auf den Android-Kalender.

Verarbeitete Daten

LarasCalendar verarbeitet folgende Daten ausschließlich lokal auf dem Gerät:

Lokale Speicherung

Termine, Erinnerungen und Anhang-Metadaten werden in der IndexedDB-Datenbank kalenderecho gespeichert. Anhänge liegen auf Android als Datei im privaten App-Sandboxspeicher. Beim Löschen eines Termins oder Anhangs versucht die App, die zugehörigen lokalen Dateien ebenfalls zu löschen; lehnt das Betriebssystem den Zugriff ab, kann eine verwaiste Datei bis zum Löschen der App-Daten verbleiben.

Export, Voll-Backup und Wiederherstellung

LarasCalendar kann Termine als ICS-Datei exportieren und ein Voll-Backup als JSON-Datei erzeugen. Beides entsteht nur auf ausdrückliche Aktion und wird über das Android-Share-Sheet angeboten. Das Wiederherstellen liest ausschließlich eine Datei, die Sie selbst auswählen; Schema und Version werden geprüft, ungültige Dateien werden abgelehnt, ohne lokale Daten zu verändern. Vor dem Schreiben fragt ein Dialog, ob zusammengeführt oder ersetzt werden soll — „Ersetzen“ verlangt eine zusätzliche Bestätigung.

Berechtigungen

POST_NOTIFICATIONS ist die einzige gefährliche Berechtigung, die LarasCalendar auf Android zur Laufzeit anfordert, und sie wird nur angefragt, wenn Sie Erinnerungen verwenden möchten. Wird sie verweigert, bleiben Erinnerungen lokal gespeichert, werden aber nicht als Systembenachrichtigung angezeigt. Das zusammengeführte Manifest enthält außerdem die automatisch gewährten Systemberechtigungen RECEIVE_BOOT_COMPLETED und WAKE_LOCK sowie einen Boot-Empfänger der lokalen Benachrichtigungsbibliothek. Sie dienen ausschließlich dazu, lokale Erinnerungen nach einem Gerätestart wiederherzustellen und zum vorgesehenen Zeitpunkt auszuführen; es gibt keinen Push-Dienst, keinen auslösenden Server und keine Netzwerkübertragung.

Damit Erinnerungen zum eingestellten Zeitpunkt und nicht erst in einem Sammelfenster des Systems ausgelöst werden, nutzt LarasCalendar Androids Alarm-Schnittstelle für exakte Zeitpunkte. Dafür stehen im Manifest USE_EXACT_ALARM (ab Android 13) und SCHEDULE_EXACT_ALARM (bis einschließlich Android 12L). Beide sind keine gefährlichen Laufzeit-Berechtigungen und öffnen keinen Abfragedialog: USE_EXACT_ALARM wird Kalender-Apps beim Installieren gewährt, SCHEDULE_EXACT_ALARM ist auf älteren Android-Versionen als Sonderzugriff „Wecker und Erinnerungen“ in den Systemeinstellungen entziehbar. Ist der Zugriff nicht aktiv, werden Erinnerungen weiterhin gespeichert und geplant, können aber verzögert erscheinen; die App zeigt diesen Zustand an und öffnet auf Ihre Aktion hin die zuständige Systemeinstellung. Ein Zeitpunkt-Alarm greift auf keine Daten zu und überträgt nichts.

Insbesondere fordert die App folgende Berechtigungen nicht an: Zugriff auf den Android-Kalender (READ_CALENDAR / WRITE_CALENDAR), breiten externen Speicherzugriff, Internet-Zugriff oder Berechtigungen für Kamera, Mikrofon, Standort und Kontakte.

8. LarasVault

Versionshinweis, ergänzt am 14. September 2026: Bis einschließlich Version 1.0.1 wird die Passphrase nicht dauerhaft gespeichert. Die nachfolgend beschriebene optionale Gerätespeicherung und Passphrase-Änderung sind für Version 1.1.0 vorbereitet; dieser Hinweis bestätigt noch keine Veröffentlichung dieser Version.

Funktion, Speicherorte und Berechtigungen im Überblick

Funktion
Fotos und Dateien in einem mit einer Passphrase geschützten Tresor ablegen, sie nach dem Entsperren ansehen oder exportieren, den Tresor automatisch sperren lassen sowie ein Backup mit verschlüsselten Dateiinhalten und lesbaren Dateimetadaten erzeugen und wieder einspielen.
Was die App speichert
Die verschlüsselten Datei-Bytes, Dateimetadaten wie Name, MIME-Typ, Größe und Importzeitpunkt, die kryptografischen Metadaten (Salt, IV, Zahl der KDF-Iterationen, Duplikatkennung), die gewählte App-Sprache und die Diagnosezustände aus Abschnitt 9: ein wartender Bericht mit Fehler-Fingerprint und Erstellungszeitpunkt, unterdrückte Fingerprints und die Berichtseinstellung. Ab Version 1.1.0 kann auf unterstützten Android-Geräten nach Ihrer bewussten Auswahl zusätzlich eine verschlüsselte, an diesen Tresor gebundene Passphrase-Kopie gespeichert werden.
Wo gespeichert wird
Ausschließlich auf dem Gerät: Einträge, Krypto-Metadaten und Diagnosezustände aus Abschnitt 9 in der lokalen App-Datenbank (IndexedDB), die App-Sprache im WebView-Speicher (localStorage) und die Chiffrate als Dateien im privaten App-Speicher. Verschlüsselt wird lokal mit AES-GCM-256; der Schlüssel wird mit PBKDF2-SHA-256 und mindestens 600.000 Iterationen aus Ihrer Passphrase abgeleitet. Es gibt kein Konto, keinen Cloud-Schlüssel, keinen Recovery-Key und kein Android-System-Backup.
Was das Gerät verlässt
Keine von der App initiierte Netzwerkübertragung. LarasVault deklariert keine Internet-Berechtigung und kann deshalb technisch keine Netzwerkverbindung aufbauen. Daten können das Gerät nur verlassen, wenn Sie eine Export-, Backup- oder Diagnosebericht-Datei selbst über das Android-Share-Sheet weitergeben.
Berechtigungen
Keine gefährlichen Android-Berechtigungen und keine Internet-Berechtigung. Der Dateiimport läuft über den System-Dateipicker. Für die optionale Gerätespeicherung ab Version 1.1.0 nutzt die App Androids Systemdialog zur Bestätigung durch starke Biometrie oder Geräte-PIN, -Muster beziehungsweise -Passwort; biometrische Vorlagen erhält LarasVault nicht.

Verarbeitete Daten

LarasVault verarbeitet folgende Daten ausschließlich lokal auf dem Gerät:

Verschlüsselung

Importierte Dateien werden vor der dauerhaften Speicherung lokal verschlüsselt. Der Schlüssel wird auf dem Gerät mit PBKDF2-SHA-256, mindestens 600.000 Iterationen und einem zufälligen Datei-Salt aus der eingegebenen Passphrase abgeleitet. Die lokale Datenbank enthält einen verschlüsselten Prüftext zur Passphrase-Prüfung; dieser Prüftext ist keine Kopie Ihrer Passphrase. LarasDesk erhält weder die Passphrase noch einen Cloud-Schlüssel oder Recovery-Key. Exakte Duplikate werden lokal über eine HMAC-SHA-256-Kennung erkannt; sie wird nicht hochgeladen.

Optionale Passphrase-Speicherung auf diesem Gerät ab Version 1.1.0

Die Option „Auf diesem Gerät sicher speichern“ verschlüsselt die Passphrase mit AES-256-GCM. Der separate, nicht exportierbare Schlüssel liegt im Android Keystore und muss durch die sichere Gerätehardware geschützt sein. Im privaten Einstellungsspeicher der App liegen nur die verschlüsselte Kopie, ihr IV und eine Bindung an die aktuelle Tresorkonfiguration. Diese Bindung wird bei der Verschlüsselung mitgeprüft. Speichern und Laden erfordern jeweils eine erfolgreiche Bestätigung im Android-Systemdialog. Wer diese Gerätebestätigung ausführen kann, kann damit auch den Tresor entsperren.

Ohne geeignete Hardware oder eingerichtete Gerätesperre bleibt die manuelle Eingabe verfügbar; es gibt keinen Ersatzspeicher im Browser, in localStorage oder in IndexedDB. Die Gerätekopie und ihr Schlüssel werden weder in LarasVault-Backups noch im Android-System-Backup mitgegeben. Sie können die gespeicherte Kopie entfernen, ohne Tresordateien zu löschen. Eine Passphrase-Änderung oder das Ersetzen des Tresors macht die bisherige Bindung unbrauchbar; erneutes Speichern benötigt eine neue Gerätebestätigung.

Während der aktiven Nutzung muss die Passphrase im Arbeitsspeicher von Java und JavaScript im Klartext vorliegen. Die App schreibt sie nicht in Diagnose- oder Bridge-Parameterprotokolle. Sie garantiert weder vollständiges physisches Löschen des Arbeitsspeichers oder Flash-Speichers noch Schutz bei einem kompromittierten App-Prozess oder manipulierten Betriebssystem. Einzelheiten zur Plattform beschreibt die Android-Keystore-Dokumentation.

Eine vergessene Passphrase kann LarasDesk nicht wiederherstellen. Die gespeicherte Gerätekopie kann den aktuellen Tresor noch entsperren, solange das ursprüngliche Gerät, sein Schlüssel und die Gerätebestätigung verfügbar sind. Bei Verlust oder Zurücksetzen des Geräts ersetzt sie weder ein Backup noch die dazugehörige Passphrase.

Passphrase ändern ab Version 1.1.0

Vor Änderungen prüft die App die aktuelle Passphrase. Danach verschlüsselt sie alle Tresordateien mit der neuen Passphrase und frischen Zufallswerten und erstellt neue Prüf- und Duplikatkennungen. Erst wenn dies vollständig gelungen ist und der Tresor sich nicht zwischenzeitlich verändert hat, werden Dateiverweise und Konfiguration gemeinsam ausgetauscht. Zuvor auftretende Fehler lassen den bisherigen Tresor maßgeblich. Die anschließende Löschung alter nativer Chiffratdateien erfolgt Best Effort; eine fehlgeschlagene Bereinigung wird angezeigt.

Bereits exportierte Backups ändern sich dabei nicht und benötigen weiterhin die alte Passphrase. Sie können nicht mit dem neu verschlüsselten Tresor zusammengeführt werden. Ein ausdrücklich bestätigtes „Ersetzen“ kann deren alte Tresorkonfiguration wiederherstellen. Erstellen Sie nach einer Passphrase-Änderung ein neues Backup und bewahren Sie die jeweils passende Passphrase getrennt auf.

Lokales Backup und Wiederherstellung

Das Backup wird ausschließlich im Datenschutz-Bereich der App und nur durch eine bewusste Aktion gestartet; es gibt kein automatisches und kein zeitgesteuertes Backup. Die JSON-Datei (larasvault-backup-<Datum>.json) enthält verschlüsselte Datei-Bytes, lesbare Dateimetadaten (Name, MIME-Typ, Größe, Importzeitpunkt und IDs), Krypto-Metadaten und einen verschlüsselten Verifier-Block. Die Dateimetadaten sind nicht verschlüsselt. Klartext-Dateiinhalte, Passphrase und Geräteschlüssel sind nicht enthalten. Bei der Wiederherstellung wird die Passphrase lokal gegen den Verifier-Block geprüft, bevor Daten verändert werden; sie wird dabei nicht dauerhaft gespeichert. Im Modus „Ersetzen“ werden nach dem erfolgreichen Austausch der Datenbankeinträge die zuvor referenzierten nativen Chiffratdateien nur Best Effort gelöscht. Schlägt diese Bereinigung fehl, können nicht mehr referenzierte verschlüsselte Dateien bis zum Leeren der App-Daten oder zur Deinstallation zurückbleiben.

Automatisches Sperren

Sobald eine Passphrase eingegeben oder ein sensibler Dialog geöffnet wurde, sperrt LarasVault den Tresor 30 Sekunden nachdem die App in den Hintergrund wechselt oder ihr Fenster verdeckt wird. Auto-Lock leert aktive Passphrase-Felder und schließt Vorschauen und sensible Dialoge; es garantiert keine physische Löschung aus dem Arbeitsspeicher. Ab Version 1.1.0 bleibt eine bewusst gespeicherte verschlüsselte Gerätekopie erhalten, wird aber erst nach einer erneuten Gerätebestätigung geladen. Anzeigen und Verbergen betrifft nur das jeweilige Eingabefeld. Das Sperrverhalten arbeitet lokal ohne Netzwerkverbindung.

Berechtigungen und was nicht stattfindet

Die App deklariert keine gefährlichen Android-Berechtigungen und keine Internet-Berechtigung. Dateiimport erfolgt über den System-Dateipicker, Export über einen FileProvider im app-eigenen Cache. Importierte Fotos werden nicht auf Gesichter oder andere Inhalte analysiert. Es gibt keine automatische Galerie-Übernahme, keine EXIF-Bearbeitung, kein Cloud-Backup, kein Konto und keine Sync-Funktion.

9. Optionale Diagnose-Berichte

Alle vier Apps können nach einem unerwarteten Fehler einen technischen Bericht erzeugen. Er entsteht lokal, wird beim nächsten Start vollständig angezeigt und niemals automatisch verschickt.

Was in einem Bericht steht

App-Version und Buildnummer, Plattform, Android- und WebView-Version, Sprache, Zeitpunkt, Fehlertyp, die bereinigte Fehlermeldung samt Stacktrace sowie bis zu fünf technische Bedienschritte aus einer festen Liste von Ereignisnamen (etwa „Aufnahme gestartet“, „ICS-Import gestartet“ oder „Tresor entsperrt“). Vorgesehene Felder für Inhalte gibt es nicht: keine Belegbilder, OCR-Texte, Beträge, Händlernamen, Audiodaten, Transkripte, Termininhalte, Tresor-Dateien, Dateinamen, Passphrasen oder Schlüssel — und keine Nutzer-, Geräte- oder Installationskennung.

E-Mail-Adressen, Dateipfade, IP-Adressen und lange Ziffernfolgen werden im Text vorher durch Platzhalter ersetzt. Diese Bereinigung verringert das Risiko, garantiert aber weder vollständige Entfernung noch Anonymität — Fehlermeldung und Stacktrace bleiben freie technische Textfelder. Deshalb wird der exakte Inhalt vor jeder Weitergabe vollständig angezeigt. Höchstens ein Bericht wartet gleichzeitig, und er ist auf 50 KB begrenzt.

Zusammen mit einem wartenden Bericht speichert die App lokal dessen technischen Fehler-Fingerprint und Erstellungszeitpunkt. Nach einer Ablehnung wird der Fingerprint für diese App-Version lokal unterdrückt; außerdem speichert die App Ihre Einstellung „fragen“ oder „nie erfassen“. Ein wartender Bericht bleibt gespeichert, bis er erfolgreich gesendet, bewusst verworfen oder nach einer dauerhaften Server-Ablehnung erfolgreich gelöscht wurde. Das bloße Schließen der Vorschau löscht ihn nicht; schlägt eine Löschung fehl, bleibt er lokal. Diese Diagnoseeinträge, die Einstellung und — soweit die App ein Datenfluss-Log führt — dessen Einträge haben keine eigene automatische Ablauffrist. Sie bleiben bis zur jeweiligen Aktion beziehungsweise bis zum Leeren der App-Daten oder zur Deinstallation erhalten.

Was mit einem Bericht passiert — je nach App

Sie können einen Bericht stattdessen verwerfen; derselbe Fehler wird dann in dieser App-Version nicht erneut gemeldet. Über „Nie erfassen und nicht mehr fragen“ schalten Sie die Funktion dauerhaft ab.

Der Versandweg bei LarasScan und LarasMemo

Vor dem Senden initialisiert die App Firebase App Check mit dem Google-Play-Integrity-Anbieter. App Check dient dem Schutz des Diagnose-Endpunkts vor unberechtigten oder missbräuchlichen Aufrufen. Dabei wird ein Integritätstoken von Google abgerufen und als X-Firebase-AppCheck-Header an den Endpunkt gesendet; Google kann dafür App-, Geräte- und Integritätssignale nach den eigenen Datenschutzbestimmungen verarbeiten. Das Token ist kein Feld des Berichts. Diese Initialisierung findet erst beim Versand statt — vor dem ersten bewusst gesendeten Bericht besteht also auch keine Attestierungsverbindung. Danach kann App Check sein Token automatisch aktualisieren.

Die Cloud Functions und die technischen Metadaten liegen in europe-west3 (Frankfurt). Der Rohbericht wird in einem privaten Cloud-Storage-Bucket am Standort US-EAST1 abgelegt; eine reine EU-Standortzusage wird deshalb ausdrücklich nicht gemacht. Der Backendpfad nutzt Google/Firebase. Bericht und Metadaten werden 30 Tage nach Eingang zur Löschung fällig; ein täglich laufender Prozess entfernt fällige Datensätze in begrenzten Stapeln, technische Verzögerungen können die tatsächliche Löschung darüber hinaus verschieben.

Ist im Backend ein Slack-Webhook aktiviert, nutzt die Verantwortliche den Slack-Dienst zur internen Benachrichtigung und technischen Fehler-Triage. Ausschließlich App-Name, App-Version, Plattform, Betriebssystemversion, ein technischer Fehler-Fingerprint und die interne Dokument-ID werden an Slack übergeben; Rohbericht und Stacktrace nicht. Für diese Metadaten gilt nicht die automatische 30-Tage-Bereinigung des Firebase-Backends. Sie werden nach den Aufbewahrungseinstellungen des verwendeten Slack-Workspace gespeichert und dort manuell beziehungsweise nach der Workspace-Regel gelöscht.

Ohne konfigurierten Diagnose-Endpunkt — der Wert wird erst beim Erstellen der App-Version gesetzt — entfällt der Senden-Knopf vollständig, und der Bericht bleibt rein lokal.

10. Rechtsgrundlagen

Soweit Daten lokal verarbeitet werden, geschieht dies auf Grundlage von Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung — Bereitstellung der App-Funktionalität) und Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Funktion und Sicherheit der App).

Die beim ausdrücklich angeforderten Sprachpaket-Abruf von LarasMemo erforderliche Übertragung technischer Verbindungsdaten an Google Play beziehungsweise Hugging Face beruht ebenfalls auf Art. 6 Abs. 1 lit. b DSGVO. Für die weitergehende Verarbeitung durch diese Empfänger gelten deren eigene Bestimmungen und Rechtsgrundlagen; das gilt auch für die ML-Kit-Diagnostik von Google bei LarasScan.

Der optionale Diagnose-Bericht ist darauf ausgelegt, personenbezogene Daten und direkte Kennungen zu vermeiden, und wird nur nach aktiver Zustimmung und Vorschau übertragen. Falls die Prüfung trotz Bereinigung und Vorschau personenbezogene Daten in einem gesendeten Bericht zeigt, beruhen Übertragung und Verarbeitung dieses Berichts auf Ihrer Einwilligung nach Art. 6 Abs. 1 lit. a DSGVO, beschränkt auf den vorab angezeigten Bericht zu diesem Vorfall.

Soweit die für App Check/Play Integrity verarbeiteten Schutzsignale, die technischen Backend-Metadaten oder die bedingt an Slack übergebenen Triage-Metadaten personenbezogen sind, beruht ihre Verarbeitung auf Art. 6 Abs. 1 lit. f DSGVO. Das berechtigte Interesse liegt im Schutz des Diagnose-Endpunkts vor Missbrauch sowie in der internen Benachrichtigung, Zuordnung und Behebung technischer Fehler. Diese Rechtsgrundlage ersetzt nicht die Einwilligung für den Inhalt des vorab angezeigten Diagnose-Berichts.

11. Rechte der Betroffenen

Das geltende Datenschutzrecht gewährt Ihnen gegenüber dem Verantwortlichen hinsichtlich der Verarbeitung Ihrer personenbezogenen Daten die nachstehenden Betroffenenrechte:

Widerspruchsrecht

WENN WIR IM RAHMEN EINER INTERESSENABWÄGUNG IHRE PERSONENBEZOGENEN DATEN AUFGRUND UNSERES ÜBERWIEGENDEN BERECHTIGTEN INTERESSES VERARBEITEN, HABEN SIE DAS JEDERZEITIGE RECHT, AUS GRÜNDEN, DIE SICH AUS IHRER BESONDEREN SITUATION ERGEBEN, GEGEN DIESE VERARBEITUNG WIDERSPRUCH MIT WIRKUNG FÜR DIE ZUKUNFT EINZULEGEN.

MACHEN SIE VON IHREM WIDERSPRUCHSRECHT GEBRAUCH, BEENDEN WIR DIE VERARBEITUNG DER BETROFFENEN DATEN. EINE WEITERVERARBEITUNG BLEIBT ABER VORBEHALTEN, WENN WIR ZWINGENDE SCHUTZWÜRDIGE GRÜNDE FÜR DIE VERARBEITUNG NACHWEISEN KÖNNEN, DIE IHRE INTERESSEN, GRUNDRECHTE UND GRUNDFREIHEITEN ÜBERWIEGEN, ODER WENN DIE VERARBEITUNG DER GELTENDMACHUNG, AUSÜBUNG ODER VERTEIDIGUNG VON RECHTSANSPRÜCHEN DIENT.

Wie sich diese Rechte hier praktisch erfüllen

Da die Apps Inhalte nicht an den Anbieter übertragen, lassen sich Auskunft und Löschung gerätelokal erfüllen. In LarasScan, LarasCalendar und LarasVault können Sie einzelne Einträge in der App löschen. LarasMemo bietet derzeit keine Löschfunktion für ein einzelnes Memo; dort entfernen Sie alle lokalen Memos samt nativen WAV-, PCM- und Manifestdateien durch Leeren der App-Daten in den Android-Einstellungen oder durch Deinstallation. Diese beiden vollständigen Löschwege sind Android-Systemaktionen. Ein selbst weitergegebenes Backup liegt außerhalb unseres Zugriffs.

Für einen mit Zustimmung übermittelten Diagnose-Bericht (Abschnitt 9) gilt: Er ist darauf ausgelegt, eine direkte Zuordnung zu vermeiden, und wird nach 30 Tagen zur Löschung fällig. Eine frühere Löschung können Sie formlos über die Kontaktadresse mit ungefährer Versandzeit anfragen.

12. Dauer der Speicherung personenbezogener Daten

Die Dauer der Speicherung bemisst sich anhand der jeweiligen Rechtsgrundlage, am Verarbeitungszweck und – sofern einschlägig – zusätzlich anhand der jeweiligen gesetzlichen Aufbewahrungsfrist.

Bei der Verarbeitung auf Grundlage einer ausdrücklichen Einwilligung gemäß Art. 6 Abs. 1 lit. a DSGVO werden die betroffenen Daten so lange gespeichert, bis Sie Ihre Einwilligung widerrufen. Bei der Verarbeitung auf Grundlage von Art. 6 Abs. 1 lit. f DSGVO werden diese Daten so lange gespeichert, bis Sie Ihr Widerspruchsrecht nach Art. 21 Abs. 1 DSGVO ausüben, es sei denn, wir können zwingende schutzwürdige Gründe für die Verarbeitung nachweisen, die Ihre Interessen, Rechte und Freiheiten überwiegen, oder die Verarbeitung dient der Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen.

Sofern sich aus den sonstigen Informationen dieser Erklärung nichts anderes ergibt, werden gespeicherte personenbezogene Daten im Übrigen dann gelöscht, wenn sie für die Zwecke, für die sie erhoben wurden, nicht mehr notwendig sind. Lokal auf Ihrem Gerät gespeicherte App-Daten bleiben so lange erhalten, bis Sie sie löschen, die App-Daten leeren oder die App deinstallieren.

13. Kontakt

Anfragen zur Datenverarbeitung bitte an support@larasdesk.com oder telefonisch an +49 1567 8333414. Zuständige Aufsichtsbehörde ist die Sächsische Datenschutz- und Transparenzbeauftragte.

Die im Rahmen einer Kontaktaufnahme per E-Mail oder Telefon übermittelten Daten — bei einem Anruf auch die Rufnummer und die von Ihnen im Gespräch gemachten Angaben — verarbeiten wir ausschließlich zur Bearbeitung Ihres Anliegens und der damit verbundenen technischen Administration. Gespräche werden nicht aufgezeichnet. Rechtsgrundlage ist unser berechtigtes Interesse an der Beantwortung Ihres Anliegens gemäß Art. 6 Abs. 1 lit. f DSGVO; zielt Ihre Kontaktierung auf den Abschluss eines Vertrages ab, ist zusätzliche Rechtsgrundlage Art. 6 Abs. 1 lit. b DSGVO. Ihre Daten werden nach abschließender Bearbeitung der Anfrage gelöscht, sofern keine gesetzlichen Aufbewahrungspflichten entgegenstehen.

14. Änderungen dieser Datenschutzerklärung

Diese Erklärung wird angepasst, wenn sich der Funktionsumfang einer App ändert — beispielsweise wenn eine Version einen Online-Sync, einen direkten Kalender-Provider-Import oder weitere Exportwege hinzufügt. Kommt eine App hinzu, wird sie in Abschnitt 2 ergänzt. Die jeweils aktuelle Fassung ist unter dieser Adresse abrufbar.