Security & privacy
What we protect, and what we do not.
A library holds records about minors. That deserves a page that states the limits plainly rather than a badge that says 'bank-grade encryption'.
Privacy
The strongest privacy property is structural
Bookleaf has no servers, no accounts, and no telemetry. Your students' names, ID numbers and borrowing histories live in a single file on the librarian's computer and are never transmitted anywhere.
That is not a policy we could change later by amending a privacy notice. There is no code in the product that sends your data out, because there is nowhere for it to go.
If we vanished tomorrow, your catalog would be exactly where it is now, and would keep working.
In practice this means
- We cannot read your catalog, your members, or your borrowing records. Nobody at Bookleaf can, at any time, for any reason.
- There is no data-processing agreement to negotiate, because we never become a processor of your data.
- A student's borrowing history — which is genuinely sensitive information — never leaves the building it was created in.
- Deleting the app and its database file deletes everything. There is no residual copy on anyone else's disk.
Protections
What version 1 defends against
Patron impersonation
Every request from a patron device carries a token issued by your own library, not just an ID number. Guessing a classmate's ID number does not get you their account.
PIN guessing
Failed logins are rate-limited per account: five failures locks the account for a minute, ten for five minutes, fifteen or more for fifteen. Sitting there trying PINs stops being viable quickly.
Stored PINs
PINs are stored as salted SHA-256 with a unique 16-byte salt per account, so two patrons who pick the same PIN do not produce the same stored value, and precomputed tables are useless.
Stolen backups
Exported backups are AES-256 encrypted with a key derived from your passphrase, and integrity-checked. A backup on a lost flash drive is not readable without the passphrase.
Limits
What version 1 does not defend against
These are real. We publish them because a school choosing library software deserves to make that decision with the facts, and because a vendor who lists no weaknesses is a vendor who has not looked.
Traffic on your Wi-Fi is not encrypted
Version 1 speaks plain HTTP on the local network, not HTTPS. Someone on the same Wi-Fi running packet capture software can read PINs as patrons log in, and capture session tokens. Full TLS is planned for the next version. Until then: deploy only on a network you control.
A rogue device could impersonate the library
Because that traffic is unencrypted, a device on the same Wi-Fi could in principle pretend to be the library server and collect patron logins. Same root cause, same fix, same version.
Short PINs cannot survive a stolen database file
A four-digit PIN has ten thousand possibilities. If someone copies library.db off the computer, salted hashing slows them down but does not stop them recovering PINs. The defence is physical: the librarian's computer should be no less secure than the cash box.
Reporting
Found something?
If you find a security issue in Bookleaf, please email support@bookleaf.site rather than posting it publicly, and give us a chance to ship a fix to the libraries running it.
We will tell you whether it is already known, what we intend to do, and roughly when — and we will credit you if you want the credit.