Privacy Policy

The Short Version

Platforms Covered by This Policy

This policy covers every release of Eldrfur Data Vault, on every platform:

There is one app now. Earlier versions of this policy described two: an original Java desktop build for Windows and Linux, and a newer one covering everything else. There is no longer a Java version, and every platform in the table above runs the same codebase, the same vault file format, the same encryption (AES-256-GCM with Argon2id) and the same SQLite schema.

This matters for reading the rest of this document. Where a section below names a platform, that is a REAL difference in what the operating system provides, not two different programs: AutoFill exists on iOS, macOS and Android because those systems have an AutoFill service, and the desktop exit behaviour differs because Windows, macOS and Linux end a program differently. Nothing here is a feature one build has and another lacks.

What Eldrfur Data Vault Does

Eldrfur Data Vault is a local or decentralized, user-centric, privacy-first, encrypted password and secrets manager. All valuable vault database fields are encrypted on your device before being stored or transmitted anywhere. Encryption uses AES-256-GCM with a key derived from your Master Password using Argon2id (Single-User) or the Master Password unlocks the Encryption Key (Multi-User). The developer cannot decrypt your vault under any circumstances. End-user is responsible for storage of their vault(s) and their Master Password and Recovery.

The only data that is not encrypted is for proper operation of the SQLite database and its framework, along with some of the metadata not needing to be encrypted to protect your privacy. The metadata includes things like the type of vault (single or multi-user).

What someone holding your vault file, but not your Master Password, can still work out. This is worth stating precisely rather than in general terms, because "encrypted" is often read as "nothing at all is visible".

Not visible: any field's contents, and, as of Build 13, any field's length. Until Build 13 the stored size of an encrypted field was exactly the size of what was in it, so the length of a password or a card number could be read off the file. Every field is now padded to a fixed step before encryption, so the stored size no longer tracks the real one.

Still visible: how many entries and folders the vault holds; which of an entry's fields are filled in and which are empty, which usually reveals what KIND of entry it is even though not one of its values can be read; whether an entry is marked a favourite; when each cloud provider was configured; the key-derivation settings, which tell an attacker how much work a guess costs them; and the vault format version. None of this exposes a secret, and all of it is a consequence of storing the vault in a standard SQLite file that other tools can open. It is listed here so the picture is complete.

What the Developer Does NOT Collect

All versions of Eldrfur Data Vault does NOT collect any of the following:

• Analytics or usage data of any kind
• Crash reports or diagnostic data sent anywhere
• Advertising identifiers or advertising data
• Device identifiers or hardware fingerprints
• Contact information
• Location data
• Browsing history
• In-app purchase history
• User content
• Telemetry of any kind

There is no analytics SDK, crash reporting framework, advertising network, or telemetry library in this app. The developer has no visibility into whether the app is installed, opened, or used by anyone, anywhere.

Online Data Connections

This is the complete list. If a connection is not in this table, the app does not make it.

Links out of Settings, and why they are in this table at all. Strictly, the app makes no request when you tap Privacy Policy or the Firefox source link: it hands the address to your own browser and takes no further part. The connection after that is your browser's, with your browser's cookies, extensions and history, not this app's.

It is listed anyway, because the sentence above this table says the list is complete, and somebody watching their own network after tapping an entry in this app's Settings would see traffic to www.azimoslabs.com. Finding that in this table beats working it out.

Nothing about it happens on its own. The app shows you the host it is about to send you to and waits for you to agree, and the page it opens is a plain document that is not personalised to you in any way. We do not learn that you opened it beyond whatever an ordinary web server log records for any visitor, which is an IP address, a time, and the page requested. There is no identifier, nothing from your vault, and nothing tying the visit to your copy of the app.

The reachability check, and why it exists. When sync is switched on, the app has to know whether there is actually a path to the internet before it tries to talk to your provider. Without that check, a laptop with Wi-Fi on but no route out spends minutes retrying every account in turn, which is what you would see as the app hanging at unlock or at lock.

The check is the smallest question that proves a path exists: a single DNS packet, 17 bytes, asking who the internet's root name servers are. That question contains no hostname, so it does not reveal your provider, your account, or anything you were about to sync. It is sent to Cloudflare's public resolver at 1.1.1.1, and if nothing answers within two seconds, to Quad9 at 9.9.9.9. If neither answers, the app falls back to asking your own system's configured resolver to look up one.one.one.one, because some networks block outbound DNS to anything but their own server, and treating that as "offline" forever would silently stop your sync.

Cloudflare and Quad9 will see your IP address and the time, the same as they would for any DNS lookup your device already makes. It is not sent to Azimos Labs, and we never learn that it happened. If cloud sync is off, the check never runs.

Two requests, not one, on Apple platforms. Turning on update checking enables two separate requests to the same file: one asks whether a newer version exists, the other asks whether there is a "Coming Soon" notice to show. Earlier versions of this policy described one request. That was inaccurate, and it is corrected here rather than quietly left alone.

Android does not contact the developer's server. Earlier builds ran the "Coming Soon" request on every platform, including Android, while this policy said Android used Google Play instead. The code, not the policy, was the thing that was wrong. The request is now switched off on Android, so what this document has always claimed is now actually true. If you had update checking turned on in an earlier build on Android, that build did contact azimoslabs.com roughly once a day, and the developer's web server logs would have recorded your IP address and the time, the same as any other web request. Nothing else was sent: no vault data, no identifier, no account.

Data Stored On Your Device(s)

The following is stored locally on your device only unless otherwise chosen and is never sent to the developer or any third party by the app it's self:

Vault database (vault.db)

This is a standard sqlite database framework file. Your encrypted entries includes but not limited to: labels, usernames, passwords, notes, SSH keys, VPN keys, passkeys, binary keys, and any other secrets you store. All credential fields are encrypted with AES-256-GCM before being written to disk. The database is a standard SQLite file. Database is read and decrypted into RAM on your device.

Vault location configuration

Stored in app preferences on your device: which cloud storage provider you have configured (if any), your auto-sync preferences, and the local path to your vault file. Contains no credentials or secrets with exception of when using rclone and your configuration is encrypted. Eldrfur will encrypt your rclone's password with your masterpassword and store the secret in it's config file locally.

Sync failure reason (on-device only). If a sync attempt to a cloud provider or local sync folder fails, the app stores a short category for what went wrong ("the server could not be reached", "the server did not accept the saved sign in details", and so on) and the time of the attempt in your device's local app preferences, so you can see why the last attempt failed when you check that provider's settings screen.

CORRECTION, and this one mattered on Apple platforms: until Build 13 the app stored the RAW error text here, which for a self-hosted server could contain that server's address. App preferences on iOS and macOS are always included in a device backup and cannot be excluded, so a self-hosted Nextcloud hostname could ride along into iCloud Backup. It now stores a fixed category instead, chosen from a list written into the app, so nothing derived from your server or your account is written to that file. The detailed message is still shown to you in the app for the current session; it is simply no longer saved. This is cleared automatically the next time a sync to that provider succeeds. Like the rest of this section, it never leaves your device and is not sent to the developer or anyone else.

PIN unlock data (if you enable PIN unlock)

Stored in your device's hardware-backed secure storage (iOS Keychain, macOS Keychain, or Android Keystore):

• An AES-256-GCM encrypted copy of your Master Password, wrapped with a key derived from your PIN using Argon2id
• The Argon2id salt and IV used for that wrapping
• A failed attempt counter (resets on success, wipes PIN data at 5 failures)
• Flags for whether PIN and biometric unlock are enabled
• A flag recording that you accepted the biometric legal disclaimer

Your Master Password is never stored in plaintext anywhere. Only the encrypted wrapper is kept, and only in hardware-backed storage that does not synchronize to iCloud Keychain or any other cloud service.

PIN unlock needs hardware-backed secure storage, so it is offered on iOS, macOS and Android. On Windows and Linux the vault is unlocked with your Master Password, alongside your operating system's own session security.

Biometric Data (iOS and macOS)

Eldrfur Data Vault does not access, store, or transmit biometric data. When biometric unlock is enabled, the app requests the operating system to authenticate you. The OS returns only a pass or fail. Your biometric data (fingerprint, face geometry, iris scan) should never leaves the device's secure hardware and is never accessible to this app.

Windows and Linux do not use biometric authentication in this app.

Operating System Device Backups

This section is about something separate from the cloud sync described below, and it is easy to confuse the two. Cloud sync is a feature of this app that you turn on and point at a provider. A device backup is something your phone or computer does on its own, to the whole device, whether or not this app is involved. Until now this policy said nothing about the second one, and it should have.

What a device backup is. iPhones and iPads back up to iCloud, or to a Mac or PC over a cable. Macs back up through Time Machine. Android devices back up to your Google account and can copy themselves directly to a new phone during setup. In each case the operating system decides which app files are included, and an app can ask to be left out.

Android: already excluded. This app tells Android not to include any of its data in either channel. Cloud backup to your Google account is switched off for this app (android:allowBackup="false"), and so is the direct device-to-device transfer used when you set up a new phone, which on Android 12 and later is a separate setting that has to be refused separately. Your vault file, this app's settings, and the preferences that record which sync provider you use are all excluded from both. Moving a vault to a new device is something you do deliberately through this app's own restore or sync screen, where you can see it happening.

iOS and macOS: your vault used to be included. As of this build it is excluded. On Apple platforms the vault file lives in a shared container so the AutoFill extension can read it, and until this build nothing marked that file as excluded from backup. The honest consequence was that if you had iCloud Backup or an encrypted local backup turned on, a copy of your vault.db went into it. This was not a deliberate choice and it was never disclosed here, which is the reason this section exists.

What that copy is, stated plainly: it is the same encrypted file your sync providers get. Every credential field in it is already encrypted with AES-256-GCM using a key derived from your Master Password, so it cannot be read by Apple, by anyone with access to the backup, or by us. What it is not is a copy you chose to make. This app's position is that you decide where your vault goes, and a backup you were never asked about does not meet that standard even when the file inside it is unreadable.

What changed. This build marks the vault file, its database sidecar files, and every backup copy the app keeps beside it as excluded from device backup on iOS and macOS, using the same mechanism the app already applies to its AutoFill diagnostic log. The flag is re-applied every time the vault file is replaced, because a restore, an import, a sync that swaps in a downloaded copy, or a Master Password change all produce a new file that would not otherwise carry it. New backups do not contain your vault.

Build 13 correction, covering every vault rather than one. As first shipped, this exclusion was applied only to the vault that happened to be open. If you keep more than one vault, the others sat in the same folder with no flag on them and went into device backups exactly as before. That was a real gap between what this section promised and what the app did. Every vault the app knows about is now marked, along with its sidecar and backup files, not just the active one.

What still cannot be excluded, stated plainly. The app's own preferences file is written by the operating system's standard settings mechanism, and on iOS and macOS that file is always included in a device backup with no way for an app to opt out. It holds each vault's display name, the file path you chose for it, which sync provider it uses, and its size. It holds no credentials, no vault contents, and since Build 13 no server addresses. Android excludes this file along with everything else.

What that fix does not do, so it is not overstated. Excluding a file is a flag the operating system honors going forward; it is not encryption and it is not retroactive. Backups already taken keep the copy they have until those backups are deleted or overwritten by the OS's own rotation. The change also has nothing to do with the PIN unlock data described above, for a separate reason: that material is stored with the ThisDeviceOnly keychain setting, which already keeps it out of every backup and every device transfer. It does not move to another device under any circumstances, and it never did.

Backups you already have still contain a copy. Excluding a file stops new backups from including it. It does nothing to backups already taken, and it is not encryption. If your vault was on an Apple device before this build, assume the copy is in whatever backups existed then, until those are deleted or the OS rotates past them.

What you control. You can turn off device backup entirely in your OS settings, or turn it off for this app specifically where your OS offers that. You can delete existing backups through the same settings. Or you can leave it as it is, decide that an encrypted backup of an already-encrypted file is an acceptable trade for the convenience, and change nothing. That is a legitimate choice and this section exists so that it can be one.

Cloud Storage (Optional, User-Controlled)

Cloud backup is entirely optional and disabled by default. If enabled, you select from providers you already have accounts with. The developer operates no server, has no account on your behalf with any provider, and receives nothing from any of these flows.

What is sent to the cloud: Only the vault.db file. Because all credential fields are encrypted before leaving your device, the provider receives an opaque binary file and cannot read its contents. They just see the framework of an sql database and some metadata.

iCloud Drive (iOS and macOS only)

Your vault.db is stored in an app-specific iCloud container (iCloud.com.azimoslabs.dataVault) under your Apple ID. (Earlier versions of this policy named a stormtheory container. That was a stale name left over from before the company rename; the container the app actually uses is the one given here.) This container is not visible to other apps. Authentication is handled entirely by the OS using your existing Apple ID. iCloud sync is offered only on Apple platforms, because it is Apple's own service. This is all governed by Apple's Privacy Policy.

Google Drive (NOT PRESENT in any current release)

There is no Google Drive sync in the app you have. Earlier versions of this policy described one. That description was written against work that was started and then switched off before release: the feature is disabled in the code, there is no way to reach it in the app, and it makes no connection to Google of any kind.

This correction is being made rather than the paragraph simply deleted, because a privacy policy for a product like this one should not describe a Google data flow that does not exist. If Google Drive support is ever finished and shipped, it will be described here before it is switched on, not after.

Nextcloud

If you connect to a Nextcloud server, your vault.db is stored in a folder you choose (default EldrfurVault) on the Nextcloud server you specify. The app talks directly to your server over WebDAV using your username and a Nextcloud app password that you create and can revoke at any time from your Nextcloud security settings.

On HTTPS, and on plain HTTP. Normally this is HTTPS. The app also lets you enter a plain http:// address, because people run Nextcloud on their own network where that is a reasonable thing to do. It is not silent about it: the first time you use a given http:// address in a session, the app stops and tells you that your username and app password will cross the network in the clear and that anyone on that network can read them, and it will not connect until you say to go ahead. The agreement is not remembered between sessions and is tied to that exact address. Earlier versions of this policy said "HTTPS" without qualification, which was not accurate and hid a choice that is yours to make. The app password is recommended over your account password precisely because it is scoped and revocable. Your Nextcloud server URL, username, and app password are stored encrypted in your vault (AES-256-GCM, the same scheme as every other provider) under your control; they are never sent to the developer. Because the vault file is already encrypted on your device before upload, your Nextcloud server (whether self- hosted or provider-hosted) only ever receives an opaque encrypted file. The app communicates only with the server address you enter; no third-party server is involved. Governed by the privacy policy of whoever operates your Nextcloud instance (for self-hosted servers, that is you). Nextcloud "All about privacy".

Proton Drive (All platforms)

Your vault.db is stored in by default the EldrfurVault folder on your Proton Drive. The app authenticates from your device to Proton's servers directly using your existing Proton account information, performing the login on-device via Proton's SRP protocol (your password is never sent to Proton; SRP proves knowledge of it without transmitting it). If Proton challenges the login with a human-verification (CAPTCHA) step, that challenge is presented in-app and solved by you; the app forwards only the resulting verification token. Two-factor authentication, if enabled on your account, is handled the same way.

Once authenticated, Proton's own end-to-end encryption applies on top of the vault's AES-256-GCM encryption, so on Proton Drive the file is encrypted twice before storage. Your Proton session tokens are held on device and never shared with the developer. Proton Drive is governed by Proton's Privacy Policy.

Note: native Proton Drive sync is available on every platform this app runs on: iOS, macOS, Android, Windows and Linux. (Earlier versions of this policy said iOS and macOS only, and described a separate rclone or Proton Drive Client arrangement for the old Java desktop build. Both were true when written and neither is now.) The app communicates directly with Proton's official API endpoints over HTTPS; no third-party server is involved.

How the app identifies itself to Proton, disclosed because you would rather read it here than find it in a packet capture. The Proton connection is built on rclone's open-source Proton API bridge, and it identifies itself to Proton using rclone's application name and version rather than this app's. That is not an attempt to hide anything from you: Proton applies an upload compatibility behaviour to that identifier, and without it uploads fail outright. The practical effect is that your Proton account activity shows rclone rather than Eldrfur Data Vault. Nothing additional is sent, and Proton receives the same already-encrypted file either way.

PDF Viewing and Document/Key Export

If you store a PDF file in the vault and open it for viewing, the file is decrypted in memory on your device and displayed locally. No PDF content is transmitted anywhere. Rendering uses the pdfx package on mobile and PDFium on the desktop, and both operate entirely offline.

Build 3 addition: exporting a document or a stored key file. Build 3 added an explicit Share/Export action - available on the document viewer and on "Binary Keys" entries - that lets you send a specific, individually-decrypted file to another app on your own device, or save it using your device's own file system, through Apple's standard native share sheet (the same system share menu every app on your device uses). This happens ONLY when you tap Share/Export yourself, for one item at a time - it is never automatic, and the destination (which app, or Save to Files) is always your own choice from your device's own share menu, never chosen by this app. A temporary copy of the file is written to your device's own private app storage only for the moment the share sheet is open, then overwritten and deleted immediately after - regardless of whether you completed the share or cancelled it. (This policy used to say "overwritten with zeros", which claims more than any app can deliver. The app does ask the operating system to overwrite the file's contents, but modern storage does not guarantee that the original bytes on the physical medium are the ones replaced. The request is made on every path; the guarantee is the operating system's to give, and it does not give it.) This is entirely on-device: nothing about what you exported, or that you exported anything, is sent to the developer or to any third party.

Vault Import and Export (Build 14 onward)

Build 14 added the ability to write your whole vault to a single encrypted file, and to read one back in. This is a third way data can leave the app, alongside the optional cloud sync and the single-document export already described above, and it is the first one that writes everything to one place.

It is always something you do, never something the app does. There is no automatic export, no scheduled backup, no watched folder, and no export on first run or on update. Nothing is written until you have chosen a format, typed a password twice, picked a location, and pressed the button.

No network connection is involved, in either direction. The "Online Data Connections" table above is still the complete list. An export writes a file to the filesystem and stops; an import reads a file you point it at. Neither contacts anything, including the developer. If you then put that file in a synced folder, your sync provider has it, because you put it there.

What an export contains, and how it is protected

The password is one you choose for the file, and it is not stored anywhere. There is no recovery, by the developer or by anyone, because there is nothing anywhere that could perform one. The same floor applies as to a Master Password.

The Bitwarden format is not ours and it is weaker than ours. It is included so you can move your data to Bitwarden if you want to, which is your data and your decision. PBKDF2 is an older key-derivation function than Argon2id and is cheaper to attack with specialised hardware. If you are exporting for safekeeping rather than for moving to Bitwarden, the Eldrfur format is the one to use. The app says which format it is writing and does not choose for you.

The Bitwarden export also loses data, and the app tells you what before it runs. Bitwarden has four kinds of entry and this app has nine. Stored documents and binary key files are not in a Bitwarden export at all, because Bitwarden's export format has nowhere to put file contents; SSH, VPN and passkey entries come across as secure notes with their fields attached. Before the export runs you are shown a list of your own entries, by name, that will not be in the file. Nothing is removed from your vault either way.

Where an exported file goes, and what else can reach it

On Windows, macOS and Linux you choose the location in your operating system's own save dialog. On iOS and Android there is no such dialog, so the file is written into this app's own documents area and the full path is shown to you; you can then move or share it with your files app.

An exported file is an ordinary file, and your operating system treats it like one. This matters and is easy to miss: the "Operating System Device Backups" section above describes work done to keep vault.db out of iCloud and Time Machine backups. That exclusion does not follow an exported backup file. A file you save into Documents is inside whatever your OS backs up, and a file you save into a synced folder is inside whatever that service syncs. The file is encrypted, so what is copied is ciphertext and a salt, not your passwords. But the copy exists, and this policy would rather say so than let you infer otherwise from the section above.

Importing

An import reads the file, compares it against what is already in your vault, and shows you what it would change before changing anything. Nothing in your vault is ever deleted by an import, in any mode or behind any setting: an import adds and updates only. Entries in your vault that the file does not mention are listed and left alone.

If you ask for it, a snapshot of your vault is written first, as an ordinary encrypted Eldrfur backup under a password you choose, so the import can be undone. Its location is shown to you afterwards. If you decline the snapshot the app says plainly that the import cannot be undone.

A Bitwarden file's own protection is shown to you before you type its password, and the app does not refuse a weakly protected one. Bitwarden protects an encrypted export with one of two key-derivation functions, PBKDF2-SHA256 or Argon2id, chosen by your Bitwarden account rather than per export. This app reads both. Before the password prompt it shows which one your file used and the actual work factor it was written with, and if that is weaker than Bitwarden's current defaults it says so in plain words at that moment. The file still opens. A file you made yourself is yours to import, and a password manager that refuses to read your own older backup is not protecting you; what would not be acceptable is opening it without telling you. What you import is unaffected either way, because the protection in question is on the file, not on its contents.

The decrypted contents of an import never leave the app's Rust core. The screen that lets you compare an entry in the file against the one in your vault works on "same" and "differs" markers rather than on the values themselves; pressing Reveal on one field fetches that one value and nothing else. This is the same engineering reason the vault's own cryptography lives there, and it is described here because an import is the one operation that briefly holds an entire second vault's worth of secrets in memory.

The report afterwards

After an import you are shown a report of exactly what happened: what was added, what was updated, which folder names merged, which dates could not be read and were replaced, and anything the file held that this app has no column for. You can copy it, and you can choose to keep it inside your vault as an ordinary note entry. It is not saved anywhere unless you ask, because that report names your entries and folders, and a plain file listing them next to your encrypted vault would undo the point of encrypting it.

AutoFill and Passkeys (iOS, macOS and Android)

The iOS and macOS versions include an optional AutoFill Credential Provider extension. If you enable Eldrfur as an AutoFill provider in iOS or macOS Settings, the system may ask the extension to supply a saved login when you are signing in to an app or website. When this happens, the extension reads credentials from your local vault on-device, after you authenticate, and hands the chosen credential to the requesting app through the operating system.

AutoFill operates entirely on-device. Credentials are never transmitted to the developer or any third party; they are passed only to the app you are signing in to, through Apple's AuthenticationServices framework, and only when you select an entry. The extension accesses the same local, encrypted vault as the main app via a shared app group; it cannot decrypt anything without your authentication. AutoFill is disabled until you explicitly enable it in iOS or macOS Settings.

Android. Android has its own equivalent, using Android's Autofill and Credential Manager services, and it can also create and use passkeys. It works the same way in every respect that matters here: it reads the same local encrypted vault, it needs your authentication, and nothing it handles leaves the device. Earlier versions of this policy described AutoFill as an iOS and macOS feature only, which is out of date.

One platform difference worth naming rather than glossing: on iOS and macOS the label recording which vault AutoFill is pointed at is kept in the access controlled keychain, as described above. On Android the equivalent two values, the vault's display name and its file path, are kept in the app's ordinary settings file rather than in the Android Keystore. Neither is a secret and neither is transmitted anywhere, and Android excludes that file from every backup channel, but on Android they are readable by anything that can already read the app's private storage, which in practice means a rooted device or a forensic extraction. Every actual key and credential on Android is in the hardware-backed Keystore, not there.

AutoFill is single-vault at a time. If you have more than one vault, only one can be the active AutoFill vault at once - this is a deliberate design choice, not a limitation on what data is protected. The AutoFill configuration screen (Settings › Passwords › AutoFill Passwords, tapping this app) shows a plain-text, non-secret label naming which vault is currently configured, stored device-only in the same shared, access- controlled keychain group as the rest of AutoFill's material - it is never transmitted anywhere and contains nothing about the vault's contents, only the display name you gave it.

AutoFill setup hand-off. The app registers a private, app-only URL scheme (eldrfurvault://) used solely to let the AutoFill configuration screen open the main app directly to its AutoFill setup screen when you tap "Open Eldrfur to Set Up AutoFill." This is an on-device hand-off between the extension and the app only; it carries no vault data, credentials, or identifiers of any kind, and nothing about it is ever sent anywhere.

Optional AutoFill diagnostic log. For troubleshooting, you can turn on a local diagnostic log for the AutoFill extension (off by default) from PIN / AutoFill settings. When enabled, it records operational detail about what the extension is doing - which steps ran, timing, and non-secret identifiers like which website requested a fill - to a size-capped file inside the shared app group container on your device. It never records your Master Password, PIN, vault entries, or decrypted credentials. You can view or clear this log at any time from the same settings screen, and turning the toggle off deletes the existing log file. Nothing in this log is ever transmitted anywhere; it exists only for you (or, if you choose to share it yourself, whoever you send it to) to read on-device.

The Clipboard

When you copy a password, a TOTP code or any other value out of the app, it goes to your device's clipboard, and the clipboard is shared with every other app on your device. This is how copying works on every operating system, and there is no version of it that is private to one app. Three things are worth knowing.

The app clears it for you. Anything copied from the app is erased from the clipboard after a timeout, 30 seconds by default, which you can change in settings. If you copy something else in the meantime, the app leaves your newer clipboard alone rather than wiping it.

On Android 13 and later, the system briefly shows what you copied. Android displays a small preview of clipboard contents at the bottom of the screen. For a password that means it is legible on screen for a few seconds. Android offers apps a way to mark clipboard content as sensitive so the preview is hidden, and the framework this app is built on does not currently expose it. This is a real limitation and is stated here rather than left for you to discover.

Until Build 13, a password copied from the AutoFill screen could leave your device. On iOS and macOS, content placed on the ordinary clipboard is eligible for Apple's Universal Clipboard, which forwards it to your other signed-in Apple devices over Handoff, and Handoff is on by default. The main app was not affected. The AutoFill extension was: it used the ordinary clipboard with no restriction, so a password copied there could appear in the clipboard of another Mac or iPad you own. It is now marked local to the device, given an expiry, and cleared on a timer like everything else. If you used Copy Password inside the AutoFill screen on an earlier build, assume that value reached your other Apple devices' clipboards at the time.

Screen Capture, Screenshots and App Switcher Previews

The app asks the operating system to keep vault content out of screenshots, screen recordings and the small preview your device shows when switching apps. What is actually possible differs by platform, so here is the honest version rather than a blanket claim.

Where the table says the app covers its own content, that is genuinely all that can be done: those systems provide no way for an app to be left out of a capture, and a screenshot taken by you or by software running as you will succeed. On Windows, support for the real block was added in Build 13; before that, Windows was handled the same way as Linux.

There is also a setting to allow screenshots for the current session, for when you need one. It is off by default and resets every time you lock the vault or close the app. It is never a lasting setting.

Fonts

Every typeface the app uses (Cinzel, Cinzel Decorative, Source Serif 4, Source Code Pro) is a font file bundled directly inside the app at build time. They load from disk, the same as any other app asset - never from a network request, on any platform, on any build (debug or release), on first launch or any later launch. The app makes no request of any kind to Google, or to any other font provider, for any reason.

CORRECTION (this policy previously said otherwise): an earlier version of this document described a Google Fonts network fetch that does not reflect this app's actual behavior - the fonts have been fully bundled as local assets this entire time, and the one remaining unused reference to the google_fonts package (kept only for a network-disabling settings flag it never needed) has been removed outright. That earlier wording was a documentation error, not a description of something the app ever did in this codebase; it is corrected here so this document matches the code exactly, not just in intent.

App Update Checks

Everywhere except Android: once every 24 hours, after you unlock your vault, the app automatically checks a small remote file over HTTPS to see if a newer version is available. You can also trigger this check yourself anytime via Settings › Check for Updates › Check Now, which does the same thing on demand rather than waiting for the 24-hour cycle. Either way, the request sends no personal data, no vault data, and no user identifier - it is a plain, unauthenticated request for a static file listing the current version number (a timestamp is added to the request only to prevent an intermediate cache from serving a stale answer; it identifies nothing about you or your device). If a newer version is found, you decide what happens next: dismiss it, tell the app not to remind you again for that specific version, or open the update link yourself. Nothing downloads or installs automatically. This check is OFF by default and must be turned on in Settings › Check for Updates.

There are two requests here, not one. The same toggle also enables a second request, to the same static file, asking whether there is a "Coming Soon" notice to show you. It sends exactly as much as the first one, which is to say nothing about you, and it is listed separately in the Online Data Connections table above because it is a separate connection and this policy previously described only one.

Android: uses Google Play's own official In-App Updates feature instead of the check described above - genuinely different infrastructure, not this app's own server. This means Google Play itself (which you are already connected to as the source the app was installed from) is asked whether a newer version exists, using Google's own SDK built for this exact purpose. If you accept, Google Play downloads the update directly in the background; the app never has its own copy of that file or any part of the process, and never sees anything beyond whether an update is available. Same behavior otherwise: off by default, on-demand "Check Now" available, and nothing installs without you choosing to restart and finish it.

Android does not contact the developer's server at all, which is what this section has always said and is now actually true in the code. Builds before 13 also ran the "Coming Soon" request described above on Android, contradicting this paragraph. That is disclosed in the Online Data Connections table near the top of this document, including what those earlier builds sent and what a server log would have recorded.

Windows and Linux make these requests too, and this document used to say they did not. It said so by describing them as "the Java desktop version", which did not perform update checks. That stopped being true in Build 14, when this app started shipping for Windows and Linux: there is one codebase now, the update check is gated only on Android, and so a Windows or Linux install with the toggle ON makes the same two requests an iOS or macOS install makes. It is still OFF by default and still sends nothing about you.

The one difference worth naming: the version manifest lists a download link per platform and currently has none for Windows or Linux, so the request is made and the answer carries no link to offer you. Corrected here rather than quietly fixed, because the table above states it is the complete list, and for two platforms it was not.

Third-Party Libraries

This app uses third-party open source libraries for cryptography, database access, and platform integration. These libraries operate locally on your device and do not transmit data independently. The main libraries are:

The main vault's encryption (session key handling, master password verification, AES-256-GCM, and Argon2id key derivation, including PIN unlock's own wrapping) runs through a native Rust layer bundled with the app (via flutter_rust_bridge), using the well-established aes-gcm and argon2 Rust crates - this reduces how long key material needs to exist in the app's own memory compared to a pure-Dart implementation, though the encryption scheme itself (AES-256-GCM + Argon2id) is unchanged. pointycastle (AES-256-GCM) and an embedded pure-Dart Argon2id implementation (ported from BouncyCastle, Apache 2.0; no third-party Argon2 package) remain in use specifically for the AutoFill extension's own key wrapping - a deliberately separate, lighter-weight profile sized to fit the AutoFill extension's stricter memory limit (see "AutoFill" above). Also: sqlite3 (SQLite), flutter_secure_storage (hardware keychain), local_auth (biometric), icloud_storage (iCloud), http (Proton Drive API over HTTPS), pdfx (PDF rendering), file_selector (local file selection on macOS/ desktop - iOS uses a small custom native channel instead of a third-party picker package, after the third-party file_picker plugin repeatedly broke the iOS build), share_plus (Build 3 addition - the native OS share sheet for the document/key export feature described in "PDF Viewing & Document/Key Export" above; operates entirely on-device, see that section). Fonts are bundled locally as font files at build time - no font-related network request of any kind, on any platform, on any build; there is no Google-Fonts-package dependency of any kind (removed entirely in Build 3 - see the Fonts section below for the full correction). Native Proton Drive support uses a small bundled Go-based bridge, built on rclone's open-source Proton API bridge, that talks to Proton's official API over HTTPS; it runs in-process, opens no network ports, and transmits nothing to the developer. See the Proton Drive section above for how it identifies itself to Proton.

Build 14 additions, all in the Rust layer and all local only: pbkdf2, hmac, sha2, aes, cbc and subtle implement the PBKDF2 and AES-256-CBC that Bitwarden's file format uses, and exist only so a Bitwarden export can be read and written. They are never used for your own vault, which stays on Argon2id and AES-256-GCM. serde, serde_json and base64 read and write the JSON and base64 that both backup formats are made of, and unicode-normalization compares two names that look identical but are stored as different byte sequences, so importing does not create a second copy of a folder you already have. On Linux only, pdfium-render binds Google's PDFium for in-app PDF preview; PDFium itself is a separate work under its own BSD-3-Clause licence, whose notice ships inside the Linux application bundle. None of these open a network connection.

Where to see the full list: Settings has an "Open Source Licenses" screen. Build 14 fixed a real omission there. That screen automatically collects the licence of every Dart package, which is most of this app, but compiled Go and compiled Rust never appear as Dart packages and so were missing from it. The Go modules behind Proton Drive had been added by hand; the Rust crates had not, and had been absent since Build 8 even though they were in the shipped binary. All thirteen are now listed. The licences themselves never changed and nothing about your data was affected; a notice you were entitled to see was not being shown, and now is.

Android only, worth calling out separately: Google Play's own In-App Updates library (Play Core) is the one exception to "these libraries operate locally and do not transmit data independently" above - by design, it communicates directly with Google Play to check for and download app updates (see "App Update Checks" above). This is the same relationship you already have with Google Play as the source the app was installed from, not a new third party this app introduces on its own - but unlike every other library in this list, it genuinely does talk to an external server, so it is listed separately rather than folded into the "local only" description above it.

Data Not Shared With Third Parties

The developer does not share any data with any third party because the developer does not collect any data. The app contains no advertising networks, data brokers, analytics providers, or data-sharing integrations of any kind.

Two narrow exceptions, both described in full above and both optional: when the update check is turned on (off by default), a version-number request goes to either the developer's own server (iOS/macOS) or Google Play (Android) - see "App Update Checks" for exactly what that does and does not send. Otherwise, third parties are only ever involved when you choose to store your own vault data with your own account on another provider (Proton, Nextcloud, iCloud, or a folder you pick), at which point that provider's own policies apply to what you have chosen to store with them.

Data Security

All vault credentials are encrypted with AES-256-GCM, a standard authenticated encryption algorithm, before being stored. The encryption key is derived from your Master Password using Argon2id, a memory-hard algorithm designed to resist brute-force attacks. The Master Password is never stored in the vault database or anywhere on the device in plaintext.

Build 13 strengthened how each field is stored, and one of the three changes fixed a real weakness rather than adding a precaution. Described plainly:

1. Every field now gets its own unique encryption nonce. Previously all the encrypted fields in one record shared a single one. Reusing a nonce with this kind of encryption is a genuine break, not a theoretical one: someone holding your vault file could use a field whose content they could guess, such as a record's type or its creation date, to recover parts of the other fields in the same record. This was found during Build 13 and fixed. It required no action from you and no change to your Master Password.
2. Every field is now sealed to the exact record and column it belongs to. A field copied from one record and pasted onto another inside the vault file is now refused rather than accepted, so someone who can write to your vault file cannot swap your throwaway password onto your bank entry and have the app fill it.
3. Every field is now padded to a fixed step before encryption, so the stored size of a field no longer reveals how long the real value is.

Your vault is upgraded to the new format once, automatically, the first time you unlock it after updating. A complete copy of the file as it was before the upgrade is saved next to it first and is not deleted, and the app tells you where it is. If anything goes wrong the upgrade stops and leaves your vault exactly as it was.

Deleted entries. As of Build 13 the space a deleted entry occupied is overwritten in the database file rather than left as free space still holding the old encrypted bytes. Before this, a deleted entry's encrypted data could remain inside the file and be uploaded again with every subsequent sync.

One thing this does not protect against, stated because it is still true. If you sync your vault through a provider, and that provider (or anyone who can alter what it stores) keeps an older copy of your file, they can put an older version of a single field back. Every check in the app passes, because that older field is genuinely yours and genuinely valid. The practical effect is that a password you changed could silently revert to the previous one. Guarding against this properly needs a change to the vault format and is not in this build. It is listed here rather than left unsaid.

PIN unlock wraps the Master Password with a second Argon2id-derived key before storing it in hardware-backed secure storage. The PIN itself is never stored anywhere. A self detructive Pin after so many fails. With an option of using biometrics for a more of a "two factor" approach.

User is solely responsible for choosing a strong Master Password and keeping it secure. If user loses their Master Password, the user's vault data cannot be recovered by the developer or by anyone else without possible years of brute force. Users are also solely responsible for choosing trusted devices and staying current with their chosen service provider's own policies.

Children

This app is not directed at children under the age of 13. The developer does not knowingly collect information from children or commuicate with any users via the Eldrfur Data Vault. This is an utility app and nothing more.

Changes to This Policy

If this policy changes in a way that affects how currently released user data is handled, outside of correcting a mistake in wording, the updated policy will be posted at this URL with a revised date. Any change that reduces privacy protections will be called out explicitly in the change notice in a table to be created below.

Contact

Questions about this privacy policy or the app's data practices:

[email protected]

App Store and Google Play Privacy Nutrition Label Reference

The following summarizes this policy in the format used by Apple App Store and Google Play Store privacy disclosure screens.

Data collected by this app: None.

Data linked to you: None.

Data used to track you: None.

Data not linked to you: None.

All data created in this app stays on the user's device or in cloud storage the user controls under their own account. The developer collects nothing, stores nothing server-side, and has no access to any user data.

Android-specific note for Google Play's own Data Safety form: the "None" answers above describe what this app itself collects, which is still accurate on Android. Separately, Google Play's own In-App Updates SDK (used only if the optional update check is turned on - see "App Update Checks" above) is a Google-operated feature governed by Google Play's own privacy policy, not something this document can speak for - worth listing as a used SDK on Google Play's own disclosure form, even though it does not change what this app collects.

Change Log