LarasDesk · Imprint

LarasDesk Apps – Privacy Policy

Last updated: 2026-08-24

Diese Erklärung auf Deutsch lesen

This privacy policy applies to all LarasDesk Android apps. What an individual app does is described in its listing on the Google Play Store. This document explains 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:

2. Which apps this policy covers

• LarasScan — Android package com.larasdesk.schnellscan, codebase identifier schnellscan.
• LarasMemo — Android package com.larasdesk.voicedesk, codebase identifier voicedesk.
• LarasCalendar — Android package com.larasdesk.kalenderecho, codebase identifier kalenderecho.
• LarasVault — Android package com.larasdesk.larasvault, codebase identifier larasvault.

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.

• LarasCalendar and LarasVault cannot send anything, technically. Neither app declares the internet permission (android.permission.INTERNET). Without it Android cannot open a network connection for the app — regardless of what the app might attempt. Data leaves the device only if you yourself hand a file to another app through the Android share sheet.
• With LarasMemo, you initiate every transfer of content or a report. The local speech-package download starts only on a button press (section 6); the optional diagnostic report is submitted only after preview and a click (section 9). Recordings and transcripts are not transmitted in either case. After the first initialised diagnostic submission, however, Firebase App Check may refresh its integrity token automatically without another tap on “Send”.
• LarasScan does not upload receipt content to LarasDesk automatically. Receipt images, OCR text and exports are handed over only through a sharing or submission action you expressly choose. Independently of that, Google Play Services may download the OCR model automatically after installation from Google Play and fetch further scanner resources dynamically; the ML Kit SDK also sends operational and usage metrics to Google. After the first initialised diagnostic submission, Firebase App Check may refresh its integrity token automatically (sections 5 and 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

• Local first. Content is processed on the device and stored there — in the app's local database (IndexedDB) and in private app storage that other apps cannot read.
• No automatic cloud backup. All four apps disable the Android system backup (android:allowBackup="false", android:fullBackupContent="false", android:dataExtractionRules). Switching devices therefore does not carry the data over by itself.
• Sharing only through the share sheet. Exports and backups are created only on your action. Where a file goes afterwards is your choice in the Android share sheet. The target may be a local app or a cloud service; from that choice onwards the target's terms apply, not ours.
• Temporary export files. To hand over a file, the apps write a copy into a private cache folder exports/. LarasCalendar and ordinary LarasScan file exports clear the previous export cache before a later export. LarasMemo, LarasVault and the LarasScan JSON backup schedule deletion roughly 30 seconds after a successful handover; after a failed handover, the generated copy is deleted immediately on paths that have already created it. Every cleanup is best effort and is not queued for a permanent retry on failure. A copy may therefore remain until Android clears the cache, until app data is cleared, or until the app is uninstalled.
• No cleartext traffic. The apps are configured with android:usesCleartextTraffic="false"; the WebView loads locally bundled files only, and mixed content as well as WebView debugging are disabled in release builds.
• The shipped artefact is authoritative. For permissions, the merged manifest of the actually published app bundle governs; Android and library components may add technically required system permissions to it.

5. LarasScan

Data processed

LarasScan processes the following data exclusively on the device:

• Receipt images captured actively through the in-app camera.
• Text extracted from those images by on-device OCR (Google ML Kit).
• Fields derived from that text (date, merchant, amount, VAT rate, category).
• A SHA-256 hash chain computed per receipt for local consistency checks.
• Free-text notes you add to a receipt.
• Local DATEV settings, in particular the tax adviser and client numbers.
• Scanner page and PDF metadata including local file and page paths.
• The selected or detected app language; it is stored locally in WebView storage (localStorage).
• During a running or not yet fully cleaned backup import, a local cleanup journal in localStorage holding a technical import ID, status, local file paths, receipt IDs and hashes. It is removed once file cleanup succeeds.
• When you deliberately share, temporary readable export copies in the app cache under exports/: CSV/DATEV files, image and PDF copies, diagnostic exports and a JSON backup that is not additionally encrypted.

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

• Receipt capture: LarasScan itself declares no CAMERA permission. The capture interface and any required permission handling are provided by the Google Play Services document scanner inside the scan you deliberately start.
• Internet (android.permission.INTERNET): for the ML Kit module downloads described above, for Google Play Services components the document scanner needs to initialise, and for the consent-based submission of optional diagnostic reports (section 9).

6. LarasMemo

Data processed

LarasMemo processes the following data exclusively on the device:

• Voice recordings. On Android a native foreground service records 16-bit PCM audio at 16 kHz mono and writes segment files plus a combined WAV file at recordings/<memoId>/memo.wav into private app storage. The PCM segments remain as durable local copies after the WAV has been created successfully.
• A recovery manifest per recording (recovery_<memoId>.json) in private app storage: recording ID, start time, sample rate, channel count, segment length, segment file names, and flags indicating whether the last segment is complete and the recording has been finalised. The manifest remains stored after successful finalisation; it contains no audio and no transcript text.
• Transcript text produced from the recording on the device. The text is editable in the app; changes are stored locally.
• Memo metadata: title, recording duration, creation time, memo language, transcription status and any error marker, the detected language tag, and bar values for the decorative waveform display.
• Markdown preview text generated inside the app (produced locally, never sent automatically).
• Data-flow log entries: timestamp, direction (local/inbound/outbound), a target or reason identifier for events that actually occurred and, when sharing, the local file name. That name may contain a sanitised component derived from the memo title. The log exists purely for local transparency and is not transmitted as part of a diagnostic report.

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:

• Delivery through Google Play (production path): the speech package is an on-demand Play asset pack (model_pack) delivered by Google Play on request. The recipient of the technically required connection data is Google; Google's privacy terms apply.
• Direct download (fallback for development and sideload installs): if Play delivery is unavailable, the app fetches the model file over HTTPS from huggingface.co. The request may follow HTTPS redirects to delivery or CDN infrastructure. Recipients are Hugging Face, Inc. and the infrastructure/CDN providers involved.

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

• Microphone (android.permission.RECORD_AUDIO): to capture voice memos, requested at runtime before the first recording. If denied, recording does not start.
• Modify audio settings (android.permission.MODIFY_AUDIO_SETTINGS): technically required so the WebView's microphone request can be resolved. No system settings are changed permanently.
• Foreground service (android.permission.FOREGROUND_SERVICE) and microphone type (android.permission.FOREGROUND_SERVICE_MICROPHONE): so an ongoing recording does not break when the app moves to the background.
• Notifications (android.permission.POST_NOTIFICATIONS): requested at runtime from Android 13 on, used solely for the recording notification. There are no advertising or marketing notifications.
• Internet (android.permission.INTERNET): for the speech-package download and the optional diagnostic submission. The download and report transfer each begin with your action; after the first initialised diagnostic submission, Firebase App Check may refresh its integrity token automatically.
• Data-sync foreground service (android.permission.FOREGROUND_SERVICE_DATA_SYNC): contributed to the merged manifest by the Google Play Asset Delivery dependency. There is no separate runtime dialog for it.

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

7. LarasCalendar

Data processed

LarasCalendar processes the following data exclusively on the device:

• ICS calendar text that you actively bring in through file import or text entry. There is no direct access to Google, Outlook or Android calendar providers.
• Event fields extracted from the ICS text such as SUMMARY, DTSTART, DTEND, UID, LOCATION, DESCRIPTION, ATTENDEE and VALARM.
• Manually created or edited event data: title, location, attendees, start and end time, all-day flag, notes, reminders and attachment metadata (file name, MIME type, size).
• Attachments you select; on Android they are copied into private app sandbox storage.
• Derived statistics (total meeting time, heatmap by weekday and hour, top series, densest weekday).
• Locally generated ICS export files and full-backup files in JSON format ("schema": "larascalendar.backup") containing all event fields plus attachments as Base64-encoded file content.

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.

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

Data processed

LarasVault processes the following data exclusively on the device:

• Manually imported photos and files.
• File metadata: file name, MIME type, size, import time and a local storage reference.
• Local cryptographic metadata: salt, IV, KDF iteration count, local vault duplicate salt and an HMAC-SHA-256 duplicate identifier.
• Temporary preview and export data, decrypted locally only after a user action.
• Backup files, created only on an explicit action, containing already-encrypted file bytes, readable file metadata, crypto metadata and an encrypted verifier block. Cleartext file content and the passphrase are not included.
• The selected app language; it is stored locally in WebView storage (localStorage).

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. LarasDesk stores no passphrase, no cloud key and no recovery key. Exact duplicates are detected locally through an HMAC-SHA-256 identifier; it is never uploaded.

If the passphrase is forgotten, the encrypted files cannot be recovered. That limit is part of the product promise: there is no provider-side unlock.

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 the already-encrypted file bytes and their crypto metadata, but no cleartext content and no passphrase. On restore, the passphrase is checked locally against the verifier block before any data is changed; it is not stored 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 the restore dialog has been opened, LarasVault locks the vault 30 seconds after the app moves to the background or its window is covered. The passphrase is never stored permanently. Auto-lock resets the app state but does not guarantee physical erasure from memory. The locking behaviour is pure on-device logic 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. There is no face recognition or other ML analysis, 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

• LarasCalendar and LarasVault transmit nothing and cannot: they have no internet permission. The report leaves the device only if you share it yourself through "Export report".
• LarasScan and LarasMemo additionally show a send button — but only after you have expanded and seen the exact content. On your consent the report is transmitted over HTTPS to the controller's diagnostic endpoint.

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 of access under Art. 15 GDPR;
• Right to rectification under Art. 16 GDPR;
• Right to erasure under Art. 17 GDPR;
• Right to restriction of processing under Art. 18 GDPR;
• Right to be informed under Art. 19 GDPR;
• Right to data portability under Art. 20 GDPR;
• Right to withdraw consent given under Art. 7(3) GDPR;
• Right to lodge a complaint under Art. 77 GDPR — the authority responsible for us is the Saxon Data Protection and Transparency Commissioner.

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: lara.knuth@larasdesk.com

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.