Every byte that leaves the device.

The retailer catalogue: no requests at all

Every country's list of retailers is compiled into the app. All 12 (see the full list) together are a little over a hundred kilobytes, so there is nothing worth fetching. A new list arrives with a new version of the app.

That was the app's only unprompted outbound request, and it is gone. An install with backup left off, which is the default, makes no network requests whatsoever.

Backup, and what goes to Google

Two different things, with two different answers.

Android's own backup is on. Your cards, your settings and the backup key are included in Android's Auto Backup and in device-to-device transfer, so a new phone set up from a Google backup (or straight from your old phone over a cable) arrives with your cards already in it. This is Android's mechanism rather than ours: it goes into your Google account, no CardJar code makes the request, we never receive it and have no way to ask for it. On Android 9 and later it is encrypted against your screen lock before it leaves, so Google holds something it cannot read either. Turning it off is a setting on your phone, not in our app: Settings, then Google, then Backup.

An exported file goes wherever you put it. Export seals all your cards into one file with a passphrase you choose, and hands it to your phone's file saver. It opens on any phone with that passphrase and on none without it. Nobody holds a copy of it, not Google and not us, which is the same fact as nobody else being able to read it.

Google Drive, switched off in this release

The Drive backup is built but turned off, and this version of the app makes no request to Drive at all. When it is switched on it will ask for one scope, https://www.googleapis.com/auth/drive.appdata, which can only see a private folder this app created, not your documents and not anything else in your Drive. This page will be rewritten to describe it on the day that happens.

Reading your cards does not send them anywhere

Importing pictures reads two things out of each one: the barcodes, and the words printed around them. The words are what let a card whose scheme publishes no number format still arrive with the right name on it. The camera does the same when you scan a card, reading the frame the barcode was found in, once. The name is printed on the card you are holding up just as it is on a screenshot of it. Every one of those readers runs on your phone, from models built into the app rather than fetched, so scanning and importing both work in aeroplane mode and make no request while they work.

Nothing about the pictures or the camera frames leaves the phone: not the image, not the text read out of it, not the name it produced, and not the fact that you scanned or imported anything at all. Frames from the camera are never saved anywhere. They are read as they arrive and released. The words are held only long enough to compare them against the retailer list already inside the app, and are then dropped along with everything else about the frame.

That is the entire list

• No analytics in the app. The website counts page views, and says how below.
• No third-party crash reporter.
• No advertising identifier, no attribution, no fingerprinting.
• No card number, name, colour or count is ever sent anywhere.
• Android's own backup is on, and carries your cards into your own Google account. It is the one item on this list that is not "nothing", it is Android doing it rather than the app, and the section above is the full account of it.

Sharing

A share link carries the card in the part of the URL after the #, which browsers never send to a server. The card travels between the two devices and nowhere else, even when the person receiving it opens the link in a browser rather than in the app. The page it lands on is static, has no backend, and could not record a card number if it wanted to.

The watch

If you use the Wear OS app, your favourite cards travel from your phone to your watch over the link the two devices already have with each other as a paired pair. Nothing about that reaches us. Only favourites travel, and only the parts the watch draws.

The watch keeps its own copy so it works with your phone out of range. If you would rather a card were not on your wrist, do not favourite it.

The launcher's long-press menu

Holding the app icon down offers to add a card, and lists up to three of your cards to open straight away, on Android and on iOS Home Screen quick actions, both asking the same question of the same jar. Naming a card there hands its name to your launcher, which is another app on your phone: it draws that menu, and what it remembers afterwards is its own. Only the name and the colour ever go, never the number.

Switch the fingerprint, face or PIN lock on and no card is listed at all, because a menu of shop names readable from a locked phone would give away most of what that lock is for. The entry for adding a card stays, since it names nothing.

Delete a card, or switch that lock on, and the app stops offering it and switches off any copy of it you had pinned to your home screen. What it cannot do is take the name back: only your launcher can remove a pinned icon, and anything it has already noted is out of the app's hands. That is true of anything you put on a home screen, and it is why this menu names as little as it does.

What is stored on the device

Everything: your cards, held in the app's private storage, protected by your phone's own encryption and, if you switch it on, a fingerprint, face or PIN lock. That is the point of the app. It works in aeroplane mode because your cards are simply there.

Uninstalling removes all of it from the phone. Android's backup copy in your Google account outlives the uninstall for a while, as it does for every app; you can delete it yourself from Google One's backup settings without asking us. Any file you exported is yours and stays wherever you put it.

This website

cardjar.app is a static site on Cloudflare Pages, and it counts its page views with Google Analytics. That is the one thing on this page that is not nothing, so here is exactly what it does and does not do. The app is unaffected: nothing on your phone or your watch reports anything to anybody, which is what the rest of this page is about.

The counter is told that a page was opened, and which page. It sets a cookie, as an ordinary analytics tag does, so a second visit from the same browser is recognised as the same browser. Google is given the address of the page, the site you arrived from, and what any web server sees of a request: a rough location worked out from your IP address, and which browser you used. Advertising features, Google Signals and personalisation are switched off, so nothing here is used to build an advertising profile. If your browser sends Global Privacy Control or Do Not Track, nothing loads and nothing is counted.

The share page at /c, where a card sent to you is opened, is why that is written so carefully. The card is in the part of the link after the #, which your browser never transmits to anyone, and an analytics tag left as it comes reports the whole address of the page including that part. On that page the counter is never given the address at all: it is handed cardjar.app/c, built from the site's own name and that one letter, so there is no code path by which the card could reach Google even by mistake. The card is not in Cloudflare's request logs either, and could not be.

Everything else a page here asks for, the stylesheet, the fonts and the pictures, is served from this domain.

Children

CardJar is not directed at children and collects no personal data from anyone, regardless of age.

Changes

If this policy ever changes, the change ships with a version of the app and this page is updated at the same time. There is no back channel through which the app's behaviour could change without a new version.

Contact

hello@convertcase.net