LarasDesk · Imprint

LarasDesk Apps – Privacy Policy

Last updated: 2026-09-15

Diese Erklärung auf Deutsch lesen

This privacy policy applies to all LarasDesk Android apps. Each app starts with a short profile: what it does, what it stores, where that is stored, what leaves the device and which permissions it uses. The sections after that explain in detail which data is processed, where it stays, and in which cases anything leaves your device. Where the apps differ, that difference is stated explicitly.

1. Controller

The controller for data processing within the meaning of the GDPR is:

Lara Knuth — Dresden AI Insights
Kurhausstr. 16, 01259 Dresden, Germany
Phone: +49 1567 8333414
Email: support@larasdesk.com
VAT ID: DE458852148
VAT-exempt as a small-business operator under Section 19 UStG (German VAT Act).

2. Which apps this policy covers

Only the apps listed above are covered. An app that is not in this list has its own policy. If a further app is added, it will be listed here before it ships.

3. What each app transmits — overview

This section is the short version. The details are in sections 5 to 9.

None of the four apps has an account, a sign-in, advertising, LarasDesk-owned analytics, tracking cookies, advertising-ID usage or automatic crash reporting to LarasDesk. The ML Kit SDK metrics collected by Google itself in LarasScan are disclosed in section 5. LarasDesk does not create usage profiles.

4. Shared principles

5. LarasScan

Features, storage locations and permissions at a glance

Features
Capture receipts with the device camera, read the text with on-device recognition (Google ML Kit), derive date, merchant, amount, VAT rate and category from it, manage and search receipts locally, and export them as a CSV/DATEV file, an image, a PDF or a complete JSON backup.
What the app stores
Receipt images, page images and scanner PDFs, the recognised OCR text, the fields derived from it, your own notes, a SHA-256 hash chain per receipt, the local DATEV settings (tax adviser and client number), the selected app language and — only while a backup import is running — a local cleanup journal. These are joined by a local data-flow log and the diagnostic state described in section 9: a pending report with its error fingerprint and creation time, suppressed fingerprints, and the report preference.
Where it is stored
On the device only: records, references, the data-flow log and the diagnostic state described in section 9 in the local app database (IndexedDB), the app language and cleanup journal in WebView storage (localStorage), images and PDFs as files in private app storage, and temporary export copies in the private cache folder exports/. There is no user account, no LarasDesk server for receipt content and no Android system backup.
What leaves the device
On your action: files you pass on through the Android share sheet, and an optional diagnostic report that you see in full beforehand (section 9). Without your input: the technically necessary connection data of the module and resource requests to Google Play Services for text recognition and the document scanner — the modules themselves come onto the device rather than leaving it — plus the operational and usage metrics the ML Kit SDK sends to Google. After the first initialised diagnostic submission, Firebase App Check may refresh its integrity token automatically. Receipt content is never uploaded automatically.
Permissions
android.permission.INTERNET. LarasScan declares no camera permission of its own — capture runs inside the Google Play Services document scanner.

Data processed

LarasScan processes the following data exclusively on the device:

Local storage

Receipt records, OCR text, derived fields, hashes and local file references are stored in IndexedDB. Native receipt images, page images and scanner PDFs are kept as files in private app storage or the app cache and referenced by path. LarasScan does not transmit this content automatically. Only a deliberate action can hand selected OCR text, receipt images, scanner PDFs, CSV/DATEV files or a complete JSON backup to the Android share sheet. The complete backup is a readable JSON file that is not additionally encrypted; it contains receipt fields, notes, OCR text, hashes and image and PDF bytes in Base64 form.

For a file-based share action the app first writes the required cleartext copy into its private cache folder exports/. Before a later CSV/DATEV, image, PDF or diagnostic export it tries to remove the previous export folder. For the JSON backup it tries to delete the specific cache file roughly 30 seconds after handover; a later backup does not automatically clean up a failed earlier deletion.

Module delivery and SDK metrics: Google ML Kit

For text recognition, LarasScan declares the OCR model as a Google Play Services dependency. Google Play Services may therefore download it to the device automatically after installation from Google Play, before you first invoke OCR. The document scanner's libraries, models and other resources are downloaded dynamically before first use or when needed. These connections run directly between the device and Google and are not operated by LarasDesk. Google describes the details in its Android text-recognition documentation, document-scanner documentation and ML Kit terms.

According to Google's ML Kit disclosure for Android, ML Kit SDKs send operational and usage diagnostics to Google, for example device and app information, device or installation identifiers, performance metrics, API configuration, feature/event data and error data. Google states that this data is encrypted in transit and used for diagnostics, abuse prevention and service improvement. LarasScan does not receive these SDK metrics and does not upload receipt images or OCR text to LarasDesk; there is no LarasDesk-owned usage analytics. The Google Privacy Policy also applies.

In its "Privacy Status" / "Network Log" area the app records that the Google Play Services path was addressed before a scanner or OCR call. It observes neither the automatic model fetch after Play installation nor an actual download or real connection state. The entry is a transparent hint at the possible module path, not a network monitor.

Permissions

6. LarasMemo

Features, storage locations and permissions at a glance

Features
Record voice memos, turn them into text on the device, edit and search the transcript, generate a Markdown preview, and back up all memos as a ZIP file and import them again.
What the app stores
The recording (WAV file and PCM segments), a recovery manifest per recording, the transcript text, memo metadata such as title, duration, timestamp, language and status, the selected app language, a local data-flow log, and the diagnostic state described in section 9: a pending report with its error fingerprint and creation time, suppressed fingerprints, and the report preference. The Markdown preview is derived transiently from the memo data and is not stored as a separate durable record.
Where it is stored
On the device only: memos, transcripts, metadata, the data-flow log and the diagnostic state described in section 9 in the local app database (IndexedDB, database name voicedesk), the app language in WebView storage (localStorage), audio files under recordings/, and recovery manifests as separate files in private app storage. No account, no cloud storage, no Android system backup.
What leaves the device
On your action: the technically necessary connection data of the request for the local speech package (section 6) — the package itself comes onto the device rather than leaving it —, files you share yourself, and an optional diagnostic report (section 9). Without your input: after the first initialised diagnostic submission, Firebase App Check may refresh its integrity token automatically. Recordings and transcripts are not transmitted — speech recognition runs entirely offline on the device.
Permissions
RECORD_AUDIO, MODIFY_AUDIO_SETTINGS, FOREGROUND_SERVICE and FOREGROUND_SERVICE_MICROPHONE, POST_NOTIFICATIONS, INTERNET, and FOREGROUND_SERVICE_DATA_SYNC contributed by the Play Asset Delivery library.

Data processed

LarasMemo processes the following data exclusively on the device:

Recording through a foreground service

On Android, recording runs inside a native foreground service (MemoRecordingService, declared in the manifest with android:foregroundServiceType="microphone" and android:exported="false"). The app binds the service internally when its plugin loads so it is ready; that does not start foreground mode or microphone access. Only tapping the record button starts the recording session, promotes the service to the foreground and activates the microphone. No recording starts at device boot, and other apps cannot start it.

Before the first recording, LarasMemo requests microphone permission at runtime and, on Android 13 and newer, notification permission. If either requested permission is denied, no recording starts; the service that is already bound internally is not moved into the foreground and the microphone is not activated. While recording, Android shows a persistent notification ("LarasMemo nimmt auf") with a "Stop" action; the channel larasmemo_recording is silent and set to low importance.

On-device transcription

Speech-to-text runs entirely on the device. LarasMemo embeds the free whisper.cpp library (MIT licence) as compiled native code (libwhisper_jni.so, arm64-v8a). No cloud speech recognition is contacted — no Google Speech-to-Text, no Web Speech API, no LarasDesk server. Audio and transcript do not leave the device.

Local storage

Memos, transcripts and metadata are stored in the app's local database (IndexedDB via Dexie; database name voicedesk). The native WAV file, PCM segments and finalised recovery manifest additionally remain in private app storage. To protect storage, the audio content of a native recording is loaded into the app database only up to a length of five minutes; longer recordings remain as native files only. LarasMemo currently has no function for deleting one memo or its native files. To remove them completely, clear the app data in Android settings or uninstall the app.

The app offers its own backup export as a ZIP file and a matching import. The ZIP contains transcripts, metadata and a pre-rendered Markdown copy; audio is included only for memos whose audio is also held in the app database. The import reads only the file selected in the file picker.

Downloading the local speech package

The speech package is fetched only on a button press ("Load local speech package"). There are two paths:

In both cases only a model file is requested; no audio, transcripts, search terms, memo metadata or telemetry are uploaded. Technically necessary connection data is transmitted for delivery: in particular the public IP address, timestamp, requested model path, usual HTTP headers and connection or runtime information. Recipients may log this data, including an approximate location derived from the IP address, under their own terms. After the download, transcription works without a network connection.

Permissions

LarasMemo requests no further dangerous runtime permissions for contacts, location services, calendar, phone state or the photo library.

7. LarasCalendar

Features, storage locations and permissions at a glance

Features
Import appointments from an ICS file or pasted ICS text, create and edit them manually, use them in day, week and month views and through search, expand recurring appointments according to RFC 5545, view statistics about your own meeting load, set reminders as local notifications, and export the data as an ICS file or a complete JSON backup.
What the app stores
Appointment fields such as title, location, attendees, start and end time, all-day status, notes and recurrence rules, reminders, attachment metadata and the attachments themselves, the selected app language, and the diagnostic state described in section 9: a pending report with its error fingerprint and creation time, suppressed fingerprints, and the report preference. Statistics are calculated from the appointment data when displayed and are not stored separately.
Where it is stored
On the device only: appointments, reminders, attachment metadata and the diagnostic state described in section 9 in the local app database (IndexedDB, database name kalenderecho), the app language in WebView storage (localStorage), and attachments as files in private app sandbox storage. No account, no cloud storage, no Android system backup.
What leaves the device
No app-initiated network transfer. LarasCalendar declares no internet permission, so Android does not let it open any network connection. Data can leave the device only if you pass on an export, backup or diagnostic-report file yourself through the Android share sheet.
Permissions
POST_NOTIFICATIONS for reminders only, plus USE_EXACT_ALARM or SCHEDULE_EXACT_ALARM, RECEIVE_BOOT_COMPLETED and WAKE_LOCK so reminders still arrive on time after a restart. No internet access and no access to the Android calendar.

Data processed

LarasCalendar processes the following data exclusively on the device:

Local storage

Events, reminders and attachment metadata are stored in the IndexedDB database kalenderecho. On Android, attachments are files in private app sandbox storage. When you delete an event or attachment the app tries to delete the associated local files as well; if the operating system refuses that access, an orphaned file may remain until app data is cleared.

Export, full backup and restore

LarasCalendar can export events as an ICS file and create a full backup as a JSON file. Both are produced only on an explicit action and offered through the Android share sheet. Restoring reads only a file you select yourself; schema and version are validated and invalid files are rejected without changing local data. Before writing, a dialog asks whether to merge or replace — "replace" requires an additional confirmation.

Permissions

POST_NOTIFICATIONS is the only dangerous permission LarasCalendar requests at runtime on Android, and it is requested only if you want to use reminders. If denied, reminders remain stored locally but are not shown as system notifications. The merged manifest also contains the automatically granted system permissions RECEIVE_BOOT_COMPLETED and WAKE_LOCK plus a boot receiver from the local-notifications library. They are used solely to restore local reminders after device startup and run them at the scheduled time; there is no push service, triggering server or network transfer.

So that reminders fire at the time you set rather than in a batched system window, LarasCalendar uses Android's exact-time alarm interface. The manifest therefore declares USE_EXACT_ALARM (from Android 13) and SCHEDULE_EXACT_ALARM (up to and including Android 12L). Neither is a dangerous runtime permission and neither opens a request dialog: USE_EXACT_ALARM is granted to calendar apps at install time, while on older Android versions SCHEDULE_EXACT_ALARM can be withdrawn as the special access “Alarms & reminders” in the system settings. If that access is not active, reminders are still stored and planned but may arrive late; the app shows this state and, on your action, opens the relevant system setting. A timed alarm accesses no data and transmits nothing.

In particular, the app does not request access to the Android calendar (READ_CALENDAR / WRITE_CALENDAR), broad external storage access, internet access, or permissions for camera, microphone, location or contacts.

8. LarasVault

Version note, added on 14 September 2026: Up to and including version 1.0.1, the passphrase is not persisted. The optional device storage and passphrase change described below are prepared for version 1.1.0; this notice does not confirm that version has been published.

Features, storage locations and permissions at a glance

Features
Keep photos and files in a vault protected by a passphrase, view or export them after unlocking, have the vault lock itself automatically, and create and restore a backup with encrypted file contents and readable file metadata.
What the app stores
The encrypted file bytes, file metadata such as name, MIME type, size and import time, the cryptographic metadata (salt, IV, number of KDF iterations, duplicate identifier), the selected app language, and the diagnostic state described in section 9: a pending report with its error fingerprint and creation time, suppressed fingerprints, and the report preference. From version 1.1.0, supported Android devices can also store an encrypted passphrase copy bound to this vault, after you deliberately enable that option.
Where it is stored
On the device only: entries, crypto metadata and the diagnostic state described in section 9 in the local app database (IndexedDB), the app language in WebView storage (localStorage), and the ciphertexts as files in private app storage. Encryption happens locally with AES-GCM-256; the key is derived from your passphrase with PBKDF2-SHA-256 and at least 600,000 iterations. There is no account, no cloud key, no recovery key and no Android system backup.
What leaves the device
No app-initiated network transfer. LarasVault declares no internet permission, so Android does not let it open any network connection. Data can leave the device only if you pass on an export, backup or diagnostic-report file yourself through the Android share sheet.
Permissions
No dangerous Android permissions and no internet permission. File import runs through the system file picker. For optional device storage from version 1.1.0, the app uses Android's system authentication dialog with strong biometrics or the device PIN, pattern or password; LarasVault does not receive biometric templates.

Data processed

LarasVault processes the following data exclusively on the device:

Encryption

Imported files are encrypted locally before they are stored permanently. The key is derived on the device with PBKDF2-SHA-256, at least 600,000 iterations and a random per-file salt from the passphrase you enter. The local database contains encrypted known text used to check the supplied passphrase; this verifier is not a copy of your passphrase. LarasDesk receives neither the passphrase nor a cloud key or recovery key. Exact duplicates are detected locally through an HMAC-SHA-256 identifier; it is never uploaded.

Optional passphrase storage on this device from version 1.1.0

The “Save securely on this device” option encrypts the passphrase with AES-256-GCM. Its separate, non-exportable key resides in Android Keystore and must be protected by secure device hardware. The app's private preferences contain only the encrypted copy, its IV and a binding to the current vault configuration. That binding is authenticated as part of encryption. Saving and loading each require successful authentication in Android's system dialog. Anyone who can complete that device authentication can also use it to unlock the vault.

Without suitable hardware or an enabled device screen lock, manual entry remains available; there is no fallback storage in a browser, localStorage or IndexedDB. Neither the device copy nor its key is included in LarasVault backups or Android system backups. You can remove the saved copy without deleting vault files. Changing the passphrase or replacing the vault invalidates its previous binding; saving again requires fresh device authentication.

During active use, the passphrase must exist as plaintext in Java and JavaScript working memory. The app does not write it to diagnostic or bridge-parameter logs. It guarantees neither complete physical erasure of working memory or flash storage nor protection when the app process or operating system is compromised. Platform details are described in the Android Keystore documentation.

LarasDesk cannot recover a forgotten passphrase. The saved device copy may still unlock the current vault while the original device, its key and device authentication remain available. If the device is lost or reset, that copy replaces neither a backup nor its passphrase.

Changing the passphrase from version 1.1.0

The app checks the current passphrase before making changes. It then encrypts all vault files with the new passphrase and fresh random values and generates new verifier and duplicate identifiers. Only after that succeeds completely, and if the vault has not changed in the meantime, are file references and configuration replaced together. An earlier failure leaves the previous vault authoritative. Old native ciphertext files are then deleted on a best-effort basis; a cleanup failure is reported.

Previously exported backups remain unchanged and still require the old passphrase. They cannot merge into the newly encrypted vault. An explicitly confirmed “Replace” can restore their old vault configuration. Create a new backup after changing the passphrase and keep each backup's corresponding passphrase separately.

Local backup and restore

The backup is started only in the app's privacy area and only by a deliberate action; there is no automatic and no scheduled backup. The JSON file (larasvault-backup-<date>.json) contains encrypted file bytes, readable file metadata (name, MIME type, size, import time and IDs), crypto metadata and an encrypted verifier block. File metadata is not encrypted. Plaintext file contents, the passphrase and the device key are not included. On restore, the passphrase is checked locally against the verifier block before any data is changed; it is not persisted in the process. In “replace” mode, previously referenced native ciphertext files are deleted on a best-effort basis after the database rows have been replaced successfully. If that cleanup fails, unreferenced encrypted files may remain until app data is cleared or the app is uninstalled.

Automatic locking

Once a passphrase has been entered or a sensitive dialog has been opened, LarasVault locks the vault 30 seconds after the app moves to the background or its window is covered. Auto-lock clears active passphrase fields and closes previews and sensitive dialogs; it does not guarantee physical erasure from memory. From version 1.1.0, a deliberately saved encrypted device copy remains stored but is loaded only after fresh device authentication. Showing and hiding affect only the respective input field. Locking works locally without any network connection.

Permissions and what does not happen

The app declares no dangerous Android permissions and no internet permission. File import runs through the system file picker, export through a FileProvider in the app's own cache. Imported photos are not analysed for faces or other content. There is no automatic gallery ingestion, no EXIF editing, no cloud backup, no account and no sync.

9. Optional diagnostic reports

All four apps can produce a technical report after an unexpected error. It is created locally, shown in full at the next start, and never sent automatically.

What a report contains

App version and build number, platform, Android and WebView version, language, timestamp, error type, the scrubbed error message with its stack trace, and up to five technical breadcrumbs from a fixed list of event names (such as "recording started", "ICS import started" or "vault unlocked"). There are no fields intended to carry content — no receipt images, OCR text, amounts, merchant names, audio, transcripts, event content, vault files, file names, passphrases or keys — and no user, device or installation identifier.

Email addresses, file paths, IP addresses and long digit sequences are replaced with placeholders beforehand. This scrubbing lowers the risk but guarantees neither complete removal nor anonymity — the error message and stack trace remain free technical text fields. That is why the exact content is displayed in full before any handover. At most one report waits at a time, and it is capped at 50 KB.

Alongside a waiting report, the app stores its technical error fingerprint and creation time locally. After a decline, the fingerprint is suppressed locally for that app version; the app also stores your “ask” or “never collect” preference. A waiting report remains stored until it has been sent successfully, deliberately declined, or deleted successfully after a permanent server rejection. Merely closing the preview does not delete it; if deletion fails, it remains local. These diagnostic records, the preference and — where an app keeps a data-flow log — its entries have no separate automatic expiry. They remain until the relevant action, or until app data is cleared or the app is uninstalled.

What happens to a report — per app

You can discard a report instead; the same error is then not reported again in this app version. "Never collect and stop asking" turns the feature off permanently.

The submission path for LarasScan and LarasMemo

Before sending, the app initialises Firebase App Check with the Google Play Integrity provider. App Check protects the diagnostic endpoint from unauthorised or abusive requests. An integrity token is fetched from Google and sent to the endpoint as an X-Firebase-AppCheck header; Google may process app, device and integrity signals for this under its own privacy terms. The token is not a field of the report. This initialisation happens only at submission time — so before the first report you deliberately send, there is no attestation connection either. Afterwards App Check may refresh its token automatically.

The Cloud Functions and the technical metadata are located in europe-west3 (Frankfurt). The raw report is stored in a private Cloud Storage bucket in US-EAST1; a pure EU-location commitment is therefore explicitly not made. The backend path uses Google/Firebase. Reports and metadata become due for deletion 30 days after receipt; a daily process removes due records in limited batches, and technical delays may push actual deletion beyond that point.

If a Slack webhook is enabled in the backend, the controller uses the Slack service for internal notification and technical error triage. Only the app name, app version, platform, operating-system version, a technical error fingerprint and the internal document ID are passed to Slack; the raw report and stack trace are not. The Firebase backend's automatic 30-day cleanup does not apply to this metadata. It is retained according to the settings of the Slack workspace in use and deleted there manually or under that workspace rule.

Without a configured diagnostic endpoint — the value is set only when the app version is built — the send button is absent entirely and the report stays purely local.

10. Legal bases

Where data is processed locally, this is based on Art. 6(1)(b) GDPR (performance of a contract — providing the app's functionality) and Art. 6(1)(f) GDPR (legitimate interest in the function and security of the app).

The transfer of technical connection data required for LarasMemo's explicitly requested speech-package download to Google Play or Hugging Face is likewise based on Art. 6(1)(b) GDPR. Further processing by those recipients is governed by their own terms and legal bases; the same applies to Google's ML Kit diagnostics in LarasScan.

The optional diagnostic report is designed to avoid personal data and direct identifiers and is transmitted only after active consent and preview. Should review nevertheless show personal data in a submitted report despite scrubbing and preview, transmission and processing of that report rest on your consent under Art. 6(1)(a) GDPR, limited to the report displayed and sent for that incident.

Insofar as the protection signals processed for App Check/Play Integrity, the technical backend metadata or the triage metadata conditionally passed to Slack are personal data, their processing rests on Art. 6(1)(f) GDPR. The legitimate interest is protecting the diagnostic endpoint from abuse and internally notifying, assigning and resolving technical errors. This legal basis does not replace consent for the content of the diagnostic report displayed in advance.

11. Data subject rights

Applicable data protection law grants you the following rights against the controller with regard to the processing of your personal data:

Right to object

IF WE PROCESS YOUR PERSONAL DATA ON THE BASIS OF OUR OVERRIDING LEGITIMATE INTEREST AFTER BALANCING INTERESTS, YOU HAVE THE RIGHT AT ANY TIME TO OBJECT TO THAT PROCESSING WITH EFFECT FOR THE FUTURE ON GROUNDS RELATING TO YOUR PARTICULAR SITUATION.

IF YOU EXERCISE YOUR RIGHT TO OBJECT, WE WILL STOP PROCESSING THE DATA CONCERNED. WE RESERVE THE RIGHT TO CONTINUE PROCESSING IF WE CAN DEMONSTRATE COMPELLING LEGITIMATE GROUNDS THAT OVERRIDE YOUR INTERESTS, RIGHTS AND FREEDOMS, OR IF THE PROCESSING SERVES THE ESTABLISHMENT, EXERCISE OR DEFENCE OF LEGAL CLAIMS.

How these rights work in practice here

Because the apps do not transmit content to the provider, access and erasure can be satisfied on the device. In LarasScan, LarasCalendar and LarasVault you can delete individual entries inside the app. LarasMemo currently has no deletion function for one memo; there, remove all local memos together with native WAV, PCM and manifest files by clearing app data in Android settings or uninstalling the app. Those two complete-erasure paths are Android system actions. A backup you have shared yourself is outside our reach.

For a diagnostic report submitted with your consent (section 9): it is designed to avoid direct attribution and becomes due for deletion after 30 days. You can request earlier deletion informally through the contact address, stating the approximate time of submission.

12. Duration of storage

The duration of storage is determined by the respective legal basis, the purpose of processing and — where applicable — the relevant statutory retention period.

Where processing is based on explicit consent under Art. 6(1)(a) GDPR, the data concerned is stored until you withdraw your consent. Where processing is based on Art. 6(1)(f) GDPR, the data is stored until you exercise your right to object under Art. 21(1) GDPR, unless we can demonstrate compelling legitimate grounds for processing that override your interests, rights and freedoms, or the processing serves the establishment, exercise or defence of legal claims.

Unless stated otherwise elsewhere in this policy, stored personal data is erased once it is no longer necessary for the purposes for which it was collected. App data stored locally on your device remains until you delete it, clear the app data, or uninstall the app.

13. Contact

Please direct questions about data processing to support@larasdesk.com or call +49 1567 8333414. The competent supervisory authority is the Saxon Commissioner for Data Protection and Transparency.

Data you provide when contacting us by email or by telephone — for a call this also covers your phone number and the information you give during the conversation — is processed exclusively to handle your request and for the associated technical administration. Calls are not recorded. The legal basis is our legitimate interest in answering your request under Art. 6(1)(f) GDPR; if your contact aims at concluding a contract, Art. 6(1)(b) GDPR applies in addition. Your data is erased once your request has been dealt with conclusively, unless statutory retention obligations apply.

14. Changes to this privacy policy

This policy will be updated when the functionality of an app changes — for example if a version adds online sync, a direct calendar-provider import, or further export paths. If an app is added, it will be listed in section 2. The current version is always available at this address.