Security

Two things protect your records today. They never leave the phone, and the books sit behind the fingerprint.

A third thing does not protect them yet: the records are not encrypted on the device. This page says which is which, because the difference is what anybody deciding what to put in actually needs to know.

1. What protects your records today

They never leave the phone

There is no server, no account and no synchronisation service, so there is no database of merchants to break into and no password of yours to steal. The most common way records like these are lost is that somebody else was holding them. Nobody else is holding these.

Inside the application there is no code that reaches the network at all: no request, no beacon, no socket, no tracking pixel. The policy the browser enforces is default-src 'self', so the app may load its own files and nothing else, from anywhere else.

The screen at rest shows nothing

The counter shows no takings, no totals, no history and no customer names. A phone passed across a counter, glanced at over a shoulder or taken out of a hand shows a number pad. There is no way to reach the books by accident: it takes a deliberate press and hold, and it is not on a menu.

The books sit behind the fingerprint

Opening the books asks for the fingerprint the handset already carries. If the fingerprint has been set up and the sensor does not confirm, the books stay shut and say so.

One honest qualification. If nothing has ever been enrolled on the phone, there is no fingerprint to ask for, and the books open. The app does not pretend to have a lock it has not been given.

There is no export-everything button

Every export is deliberate, scoped to what it carries, dated, named for a purpose, and recorded where you can see it afterwards. A complete takings record is valuable to more people than a lender, and building the honest version of this product means building the ability not to show it.

2. What does not protect them yet

The records are written to the phone’s storage in the clear. They are not encrypted at rest.

The fingerprint gate guards the interface, not the data. It decides whether the books open on screen. It does not scramble what is on the disk. So anybody who can reach the browser’s storage for this site can read the record: who owes you money, how much, and since when. In practice that means somebody with the unlocked phone and the knowledge to look, a handset passed on or sold without being wiped, or a forensic examination of the device.

Two vaults are specified, with the raw event log encrypted under a key wrapped by your fingerprint or a PIN. Neither exists yet. It is a build rather than a patch: a key, a wrapping, a migration for the records already written in the clear, and a way back when the credential is gone. Shipping half of it would be worse than the current state, because a half-encrypted store reads as a protected one.

It is recorded as an open finding alongside the code and it is the largest item on that list. Until it lands, the practical advice is the ordinary advice: put a screen lock on the phone, and do not leave the handset where somebody can pick it up unlocked.

We would rather tell you this than let you assume the fingerprint is doing more than it does.

3. Backups, and the one thing to know before you send one

A backup is compressed, not locked. Whoever receives it can read it.

The backup travels through the phone’s own sharing sheet as a compressed file. Compression is not encryption. If you send it through a messaging app, the book arrives readable, and it contains the names and the amounts. If you save it to the phone’s shared storage instead, other apps on the phone can read it there.

Send a backup to your own other phone, and nowhere else. The product carries that warning at the moment you send, not only here.

4. Splitting your key between people you trust

There is a recovery option that splits a key into pieces, so that several trusted people each hold one and a set number of them together can rebuild it. It uses the browser’s cryptographic random source and refuses to run where no such source exists, rather than quietly falling back to a weaker one.

Each piece carries how many pieces are needed and which split it belongs to, and the rebuilt key is checked against a fingerprint of the original before it is handed back. Too few pieces, or pieces from two different splits, are refused with the reason. It will not return a plausible wrong key and call it right, which is the failure that would strand somebody standing in a shop holding two pieces of paper.

Read this before you choose a split. If any two pieces can rebuild the key, then any two of those holders can rebuild it without you. That is the same property that lets them help you when your phone is gone. Choose the split, and the holders, with both directions in mind.

5. Losing the phone

If the phone is lost, stolen, reset or cleared, and no backup exists, the records are gone. Nobody can restore them, because nobody else has a copy. There is no support route that recovers them and we will not imply there is one.

Clearing the browser’s site data for edenkesef.app has the same effect as losing the phone. It is not an unlikely event: it is what happens when somebody tidies up a browser.

The app asks the browser to mark its storage as worth keeping, so it is not quietly cleared when the phone runs low on space. The browser may say yes or no. The books report which answer was given, in those terms, and never assume it was yes.

6. How the app itself is delivered

• Served over HTTPS only. The .app domain family is on the browsers’ preload list at the registry level, so a connection to this address is never attempted unencrypted in the first place.
• Strict TLS between the edge and the origin, with a minimum of TLS 1.2, certificate transparency monitoring, and DNSSEC active on the zone. The domain was hardened before it had anything to serve, which is the right order.
• A content security policy of default-src 'self' on the app and on this site, so no third-party script, font, stylesheet, frame or beacon can load, and the page cannot be framed by another site.
• Once installed, the app runs from a copy of its own files held on the phone, so an update is something the app takes deliberately and never something that changes underneath a sale in progress.

7. The camera

Camera frames are handed to the phone’s own barcode and label reader and to nothing else. They are never captured to an image, encoded, written to storage or transmitted. What is kept is the result, not the picture.

8. How we find and fix this sort of thing

Security findings are written up beside the code, with what was wrong, what changed, what is still open and who it is waiting on. Every fix carries a test that was first run against the old code and watched to pass wrongly, because a check that cannot fail is not a check.

The open items are not hidden in that file and they are not hidden on this page. Section 2 is the largest of them.

9. Telling us about a problem

If you think you have found a weakness, please tell us before telling anybody else, and give us a reasonable chance to fix it. Write to EICCIO Advisors, Lot 55, Public Road, La Grange, West Bank Demerara, Region 3, Guyana.

Please do not include real merchant records, real customer names or real phone numbers in a report. A description of the route is enough, and it avoids making the problem worse in the course of reporting it.

EDEN Kesef is owned and operated by EICCIO Advisors. This page describes how the product works and is written for transparency. It is not legal advice.
Back to EDEN Kesef · Privacy · Cookies and storage · Terms of use