Privacy Policy — Tolar

Effective date: 19 August 2026
App: Tolar — Android package si.vstaric.tolar
Developer contact: vidstaric@gmail.com

Publisher checklist before going live — confirm/replace these placeholders: the developer's public/legal name, the contact email above, the effective date, and the final hosted URL. Everything else reflects the app's current behaviour as built.

The short version

Tolar keeps your loyalty cards and shopping list on your phone. There are no accounts and no logins, no advertising, and nothing that follows you across other apps or the web, and we never sell your data. Your cards, photos and list stay on the device unless you switch on Sync & Sharing — and then they leave only as data nobody but you and the people you share with can read. There are two optional features, and they are separate:

• Sync & Sharing (off until you turn it on) — your cards and shopping list are end-to-end encrypted on your device and backed up to / shared through our own sync server, so you can restore them on another device or share with people you choose. The server only ever holds encrypted data it cannot read (zero-knowledge), and this data is never shared with any third party. See section 8.
• Diagnostics (off until you turn it on) — sends crash reports, usage counts, which screens you open, sync timings and the shop names on your cards to Google, so we can find crashes and slow spots and add the shop logos we are missing. This is the one feature that shares data with a third party and it is not end-to-end encrypted. Apart from those shop names it never includes your card numbers, notes, photos or lists. See section 9.

With both switched off — the state of a fresh install — nothing leaves your device at all. That includes Google: the app ships Google's push-messaging component, because it is how sync learns something has changed, but it is held switched off until you turn on Sync & Sharing. Turning that on registers an installation identifier with Google (it identifies the installation, not you, and carries none of your content). Section 4 explains it.

1. Who we are

Tolar is an Android app that replaces physical loyalty/membership cards. You scan a card's barcode or QR code once (or take a photo of the card), and the app stores it locally so you can show a scannable code at the till. It also includes a simple local shopping/to-do list. The app is "local-first": it works fully offline with no registration. The optional Sync & Sharing feature (section 8) is the only path by which the content you create leaves your device, and only after you opt in; the optional Diagnostics feature (section 9) is the only path by which reports about how the app runs are sent to Google. Section 4 covers the one thing that is sent without either.

2. What information the app stores

All of the following is created by you and stored on your device, in the app's private storage. Unless you turn on Sync & Sharing (section 8), it is not transmitted to us or to anyone else. None of it goes to Google either, with one exception: if you turn on Diagnostics (section 9), the shop name from each card title is sent to Google so we can add the shop logos the app does not yet have. Nothing else in this table is ever sent there.

We do not collect: names, email addresses, phone numbers, contacts, location, or advertising IDs. The app cannot read an advertising ID at all — the permissions that would allow it are removed from the app's manifest.

Usage analytics, crash logs and the shop names on your cards are collected, but only while you have Diagnostics switched on (section 9). A device installation identifier is registered with Google only once you turn on Sync & Sharing (section 4).

3. Camera

Tolar uses the camera for two things, both performed entirely on the device:

1. Scanning barcodes/QR codes to read a card's code.
2. Taking photos of a card when it has no scannable code (or for a visual reference).

Barcode detection runs on-device using a bundled, offline recognition model. Camera frames are processed locally and never leave the device — they are not stored and not uploaded. A photo you choose to save leaves the device only if you turn on Sync & Sharing (section 8), and then only end-to-end encrypted; it is never sent to Google or to anyone else. You can decline or revoke the camera permission at any time in Android Settings; the rest of the app keeps working for cards you already saved.

4. Network access

With Sync & Sharing off and Diagnostics off — the state of a fresh install — the app sends nothing anywhere, to us or to Google. The app contains no advertising SDK and nothing that tracks you across other apps or websites.

That includes Google's Firebase push-messaging component, which the app ships because it is how the sync feature learns that something has changed. Left to itself that component starts up with the app and registers the device with Google straight away; the app switches it off in its manifest — before any of the app's own code runs — so on a device where you never turn on sync it registers nothing and contacts Google not at all.

What turning on Sync & Sharing registers with Google. Push has to be able to reach this device, so when you enable Sync & Sharing (section 8) the app switches that component on, and it registers two things with Google: a Firebase installation identifier and a push registration token.

What turning Sync & Sharing back off undoes. The app switches the component off again and, this time, also asks Google to delete the push token it issued, so nothing can be delivered to this device any more; the app's own record of what it registered is erased at the same time. The installation identifier is kept, because Diagnostics uses the same one and clearing it here would quietly reset that separate choice. One thing we cannot undo from the app: our server keeps the row it stored for this device until we add a way to delete it. That row holds the token we have just had cancelled, so it can no longer reach you.

Sync and Diagnostics stay separate switches — turning one on never turns the other on. Note though that Diagnostics, if you turn it on, also needs an installation identifier of its own: that is how Google keys a crash report to an install. So the identifier is registered by whichever of the two you enable first; the push token belongs to sync alone. With both off, neither exists.

About the identifier itself:

• It identifies the app installation on this device, not you. It is not linked to your name, email or phone number — we hold none of those — and it is not linked to your sync identity.
• It carries no card, photo, list or setting content.
• Uninstalling the app discards it; a reinstall registers a new one.

Also for transparency: the build includes Google's on-device ML Kit barcode library, and the install package declares the INTERNET permission (added automatically by that library and by the Firebase components). Barcode recognition uses a bundled model and works fully offline, for example in airplane mode.

When you turn on Sync & Sharing (section 8), the app additionally connects to our sync server to upload and download your end-to-end-encrypted cards and shopping list. All such traffic is encrypted in transit (HTTPS/TLS) and end-to-end encrypted, so neither the network nor our server can read the contents.

When you turn on Diagnostics (section 9), the app additionally sends crash and performance reports to Google over HTTPS.

5. Accounts and cloud

There are no user accounts, no email, and no passwords — ever. Identity is purely cryptographic: when you enable sync, your device generates a key pair and a random identifier, and your recovery phrase (not a password we hold) is the only way to restore your data on a new device.

With sync off there is no sync server involved at all. With sync on, your data is stored on our own self-hosted sync server, but only as encrypted blobs the server cannot decrypt (zero-knowledge): the encryption keys never leave your devices and the people you share with. We do not use a third-party cloud provider to process your content, and your cards, photos and list are never sold, and never shared with any third party. Google receives none of it through sync, whatever the Diagnostics setting is; the one thing Diagnostics itself sends to Google — the shop name from a card title — is described in section 9, and it never travels by this route.

6. Backups and device transfer

Your loyalty-card database and card photos are excluded from Android's automatic cloud backup (Google Drive) and from device-to-device transfer. This is deliberate: these items can contain sensitive barcode values and card images, so the app keeps them on-device rather than letting the platform copy them off.

Practical consequence with sync off: if you uninstall the app or switch phones, your saved cards and photos are not automatically carried over. The optional Sync & Sharing feature (section 8) is the supported way to back up and move your data between your own devices, end-to-end encrypted.

7. Children's privacy

Tolar does not knowingly collect any personal information from anyone, including children. It asks for no name, email, phone number or age, has no ads, and does not track anyone across other apps. With sync on, the only content that leaves the device is end-to-end encrypted; with Diagnostics on, the reports that go to Google describe the app's behaviour, not the person using it. Both are features the user explicitly enables. The app is a barcode-scanner utility and is not directed at children.

8. Sync & Sharing (optional, opt-in)

Tolar includes an optional, opt-in synchronisation and sharing feature that is off by default. You enable it in the app's Sync settings; until you do, none of your data leaves the device.

When enabled, it works as follows:

• What is sent: your loyalty cards (title, notes, barcode value/format, and any card photos) and your shopping/to-do list. These are the only data types transmitted, and only while the feature is on.
• End-to-end & zero-knowledge: everything is encrypted on your device before it is sent. Our server stores only ciphertext plus the public keys/identifiers needed to route it. We cannot read your data.
• No accounts: identity is a device-generated key pair; a recovery phrase is the only key. There is no password reset — if you lose the phrase and all your devices, the encrypted data cannot be recovered (by us or anyone).
• Self-hosted: the encrypted data is processed on our own server, not a third-party cloud, and is not shared with any third party.
• Sharing: you can connect with other people you choose and share cards/lists with them; shared data is encrypted to those recipients' keys. You can revoke a connection, which stops future sharing (anyone who already received data cannot be made to forget it).
• Turning it off: disabling sync stops syncing; your data remains on the device.

9. Diagnostics (optional, opt-in)

Tolar includes an optional, opt-in Diagnostics setting — Settings → Diagnostics → "Share diagnostics" — that is off by default. Until you turn it on, nothing described in this section is collected or sent.

This is the one part of the app that shares data with a third party. When you turn it on, crash and usage reports are sent to Google, using Firebase Crashlytics, Google Analytics for Firebase and Firebase Performance Monitoring. Unlike your synced cards, these reports are not end-to-end encrypted: they are encrypted in transit, but Google can read them, and so can we in our Firebase console.

What is sent while it is on:

• Crash reports — where in our code the app crashed (class, method, file and line for each frame), the type of error, and, for a crash that closes the app, the technical error message. We write those messages so they cannot contain your content: they name fields, counts and status codes, never card titles, notes, barcode values or item names. For errors the app catches and recovers from, the message is stripped out entirely before the report is sent.
• Usage counts — three counters: that a card was added (and whether it had a barcode or a photo), how many list items were added at once, and whether sync was switched on or off. Plus Google's own standard events, such as app opened and app updated.
• Which screens you open — a name from a fixed list we wrote (cards, card_detail, settings and about eight others). Never anything identifying which card you opened.
• The shop names on your cards. For each card in your wallet we send either the name of a shop the app already recognises — one of the retailers whose logo we ship — or, when we do not recognise it, the shop name taken from the card's title. This is the one piece of your own content that Diagnostics sends. It is here for one purpose: the app draws a shop logo on each card from a list of retailers built into it, and this is the only way we can learn which shops are missing from that list.
  
  Before it is sent, the title is reduced: every digit is removed, so a membership number cannot travel with it; anything after the first three words is dropped; and a title that is nothing but a number is not sent at all. It is sent once per card, not each time you look at your cards, so it does not tell Google how often you shop anywhere.
  
  Please note what this reduction cannot do: the title is text you wrote, so if you have titled a card with something other than a shop name — a person's name, say — that is what gets sent. If you would rather send none of it, leave Diagnostics off, or turn it off; it is off unless you switch it on.
• Performance timings — how long the app took to start, and how long sync requests took, together with their result codes and sizes.
• Device and app details — model, operating-system version, free memory and storage, app version, and the installation identifier from section 4.

What is never sent, by design and not merely by policy:

• Your content, apart from the shop names described above. No card or membership numbers, no barcode or QR values, no notes, no card photos, no shopping-list items, no section names, no display names. This is structural rather than a promise: the only text an event can carry is a name from a list we wrote or a shop name reduced as described above, and the app would fail to build if someone tried to attach anything else to one.
• No sync identity. Your cryptographic account identifier is never attached to a report, so a crash report cannot be tied to your data on the sync server.
• No web addresses. Sync timings are reported against a placeholder address and a generic description of the request ("fetch a card blob"), never the real address — so no identifiers, and not even the address of your sync server if you host your own.
• No advertising ID, and the app cannot read one.
• We do not use any of it for advertising, marketing or profiling, and we do not sell it.

Turning it off stops all three immediately, and discards reports that have not yet been uploaded. Reports Google already received can be deleted on request — see section 10.

10. Data retention and deletion

You control your data completely:

• Delete an individual card or list item inside the app at any time.
• Delete your account and everything with it, from inside the app: Settings → Delete account & data. See below for exactly what that does.
• Clear all app data, or uninstall the app, via Android Settings to remove everything on the device permanently.
• With sync off, there is nothing for us to delete on our side, because we never receive your data.
• With Diagnostics on, switching it off stops collection at once. To have diagnostics already sent to Google deleted from our Firebase project, email us at the address below.

Deleting your account

Settings → Delete account & data is permanent and needs no email to us. It asks our server to erase the account first, then wipes this phone. It removes:

• every card, photo and list on the device, and the encryption keys for them, so nothing left behind is readable;
• your account on the server, together with the cards, shopping-list slices, connections, sharing requests and responses, push registrations and pairing codes stored against it;
• your Diagnostics setting, and any reports not yet sent.

Three things it cannot reach, and we would rather say so here than have you discover it later:

• People you shared with keep their copies. Anything you shared was decrypted on their device and is theirs now. No deletion of ours reaches another person's phone.
• A list or roster you shared stays on the server. It belongs to the people you shared it with too, so removing it would take their copy with it. It still carries an unreadable trace of this account, but the account itself is gone: nothing can open it, and nothing can be delivered to it.
• Uploaded photo files stay on the server. They are stored by content, not by owner, so the identical file can belong to more than one account — deleting "yours" could take someone else's. What remains is an unreadable, unreferenced blob that no account points at and that nobody, including us, can decrypt.

If the server cannot be reached when you delete, nothing is deleted at all and you can simply try again — the app tells you so rather than half-finishing. You can also choose to wipe just this phone in that situation, but doing so destroys the key that proves the account is yours, so the server copy could then only be removed by emailing us at the address below.

11. Changes to this policy

If the app's data practices change, we will update this policy and revise the effective date at the top. The current version is always the one published at the address above.

How you will hear about it. Material changes that introduce any new data transmission will be announced before they take effect. If you use Sync & Sharing, the app can show you a notice in-app: notices travel on the sync connection the app is already using, so they reach you without the app contacting us for any new reason, and with Sync & Sharing off the app still sends nothing anywhere (section 4). If you do not use sync, the published policy page and the Play Store listing are where changes are announced.

What counts as accepting them. We do not ask you to tick a box, and we do not keep a record of who has read this policy — that record would itself be information about you that we currently do not hold, and we would rather not start. Continuing to use the app after a change has been published is what constitutes acceptance of it. If you do not agree with a change, you can stop using the app and delete your data at any time (section 10); nothing you have stored is held hostage by a policy you did not accept.

We cannot force the Play Store to ask you to re-accept anything — installing or updating an app there is an agreement between you and Google, not between you and us — so the published page above is the authoritative record of what applies and from when.

12. Contact

Questions about this policy or the app's privacy practices: vidstaric@gmail.com

This policy describes Tolar (Android si.vstaric.tolar), including the optional, opt-in Sync & Sharing and Diagnostics features.