How we protect your clients
Your clients’ names, numbers and notes are locked with your shop’s own key before we store them. Other shops can’t see them, and our team can’t open them unless you say so.
dibbo hasn’t opened yet, so this page describes how it’s built. Anything that isn’t built yet is marked, with when it’s planned.
Your client list is locked to your shop
Every shop has its own key. Client details are locked with it before they’re saved. That key is itself locked by a key service that sits outside our database.
So a copy of our database, one of our backups, or a break-in at our database provider shows scrambled text, not your clients.
And if a client goes to your shop and the one down the road, someone holding a copy of our database still can’t tell it’s the same person.
- A client books
They type their name and number on your booking page.
- Encrypted with your key
Each business has its own key, and that key is locked by one held outside our database.
- Stored as ciphertext
A copy of the database or a backup shows only this.
Locked with your key
- Client names, phone numbers and emails
- Every note, on clients and on bookings
- The texts and emails we send for you, and who they went to
Not locked, so dibbo can find open times
- Appointment times, prices and whether a booking is confirmed
- Your shop’s own details, like its name, services and barbers’ names
These are still walled off from other shops, like everything else.
Other shops can’t see your clients
Each shop’s data is walled off inside the database itself, not only in our app. If our code ever forgot to check which shop you’re in, the database would still refuse to hand over another shop’s clients.
We test it the hard way: tests act as every kind of login and try to reach data they shouldn’t. They only pass when every attempt is refused.
A chair renter on their own book is a separate shop too. You can’t see their clients, and they can’t see yours.
Who sees what in your shop
Everyone gets their own login. Ask about a client that isn’t theirs, and a barber gets the same answer as for a client who doesn’t exist.
| Owner | Everything, including payouts and closing the shop. Downloading the client list, when it comes, is owner-only too. |
|---|---|
| Admin | Runs the shop day to day. Can’t change where the money goes or close the shop. |
| Front desk | The whole book and every client’s contact details. No setup and no group messages. |
| Barber | Their own book, and only the clients they’ve had an appointment with. |
Owners and admins get a shop log: sign-ins, role changes, changes to payments and settings, and every time someone opens a client’s notes.
Our team can’t just look
- Nobody at dibbo has everyday access to your shop’s data.
- To look at client details, say to help fix a problem, we need your recorded OK first.
- When we do, it goes in your shop log for owners and admins to see.
- Our own accounts for code, hosting, the database and payments are protected with hardware security keys.
Signing in
- Owners and admins must use a second step to sign in. Barbers can use a passkey, like Face ID or a fingerprint, instead of a password.
- Risky actions ask you to sign in again unless you just did, in the last 10 minutes: changing your payout account, adding admins, deleting in bulk, and closing the shop. Downloading your client list, sending a group message and changing your web address or text number will too, as they arrive.
- A phone stays signed in for up to 30 days. See every signed-in device, and sign out of all of them at once.
- Remove someone from your team and they’re signed out straight away.
- Your clients never make an account. Their links to see, confirm, change or pay for a booking work for that one booking only, and expire.
What we don’t do
- We’re not a marketplace. There’s no directory, so your clients never get shown other shops through dibbo.
- We don’t sell your client list, and we don’t share it with other shops.
- No ad trackers or outside scripts on our pages. The one exception is Stripe’s card form, only on the page where a client pays.
- We set no cookies on our public pages.
- No client names, numbers or messages in our logs. Logs are deleted after 30 days.
- Card details go into Stripe’s form and stay with Stripe. They never reach dibbo.
- Our texting and email providers get only what they need to deliver a message: the number or address, and the words.
If you leave, your data goes too
Close your shop and we delete your shop’s keys and all of its data.
Copies of the locked keys also sit in our backups for a set window. Until those backups age out, the data could still be restored from them. After that, nothing can bring it back. We’ll publish exactly how long before the first shops join.
When a client asks you to delete their details, we delete them. Backups age out the same way.
Owners can download a locked copy of all their shop’s data. Coming next
For the technical
The same promises in engineering terms, for you or whoever looks after your tech. This is the design dibbo is built and reviewed against.
Show the details
- Field encryption
- Client names, phone numbers, emails, notes, and message bodies and recipients are encrypted field by field with AES-256-GCM and a random 96-bit nonce. Each ciphertext is bound to its shop, table, column and row as associated data, so moved ciphertext fails to decrypt.
- Keys
- Each shop has its own root key, stored only wrapped by a key-encryption key held in a key service outside the database. Separate subkeys are derived with HKDF: one encrypts, another builds search indexes. Unwrapped keys live in zeroizing memory, cached for at most five minutes.
- Search without plaintext
- Exact lookups by phone or email use per-shop HMAC-SHA256 blind indexes, exact match only. The same number gives a different index in every shop. Name search decrypts per request; there are no plaintext, prefix or n-gram indexes on names.
- Tenant isolation
- Forced PostgreSQL row-level security on every shop table, with the shop set per transaction from the session, never from the URL. One least-privilege database role per service with column-level grants. Payment, message, consent and audit records are append-only by grant. Tests connect as each role and assert that forbidden reads and writes fail.
- Backend
- Only Rust services touch data or keys, with unsafe code forbidden. Decrypted values are wrapped in a type that cannot be printed or serialized. The web frontends hold no database credentials and no keys.
- Network
- TLS 1.2 or higher everywhere and HSTS with preload on dibbo.io. The servers take no inbound connections: traffic arrives through an outbound Cloudflare Tunnel, and every API except provider webhooks requires a Cloudflare Access token. Database connections verify the server certificate. Webhooks are signature-checked over the raw body within a replay window.
- Browser
- The only cookies are the console’s __Host- session and sign-in cookies: Secure, HttpOnly, SameSite=Lax. A strict Content Security Policy on every frontend: hash-based on this site, which is prerendered, and nonce-based on the console. The console can’t be framed, runs no third-party script, and keeps no client data in browser storage. Shop sites on dibbo.io run no shop-written code.
- Sign-in and sessions
- MFA required for owners and admins; passkeys offered. Sensitive actions need a forced re-authentication within the last ten minutes. Server-side sessions, stored only as a hash, slide up to 30 days and are revoked on sign-out, removal or deactivation.
- Client links
- Each link a client gets carries a 128-bit random capability token, stored hashed, valid for one booking and one purpose, single-use for changes, and expiring. Those pages are never cached, send no referrer, and the token is redacted from our logs.
- Logs
- Three layers keep personal data out of logs and error reports: the decrypted-value type, a redaction layer for phone and email patterns, and never logging request or response bodies. Retention is 30 days.
- Supply chain and accounts
- cargo-deny and a daily cargo-audit, pinned lockfiles, gitleaks and CodeQL in CI, and container images signed and verified at deploy. Hardware-key MFA and least-privilege tokens on every infrastructure account, with a quarterly access review.
Still to come
Here’s what isn’t done yet. We don’t hold SOC 2 or any other security certification today, and nobody outside dibbo has tested it yet. Here’s the plan. The order is on our roadmap.
Before the first shops join
- An automatic check that a copy of our database shows no readable client details
- Tests proving every role, and every other shop, is refused what it shouldn’t see
- A restore drill that includes the key service, since a backup without its keys restores nothing readable
- A written internal security review against our launch checklist
- Privacy policy, data processing agreement and list of providers, reviewed by a lawyer
Before we open to everyone
- An independent penetration test, and fixing what it finds
- A SOC 2 gap analysis: a first look at what that standard would take
After launch
- Restore, rebuild and key-change drills every quarter
- Work toward SOC 2 readiness
- A shorter wait before deleted data is gone from our backups too
Questions
Something else? Email hello@dibbo.io.
Can dibbo’s team read my clients’ notes?
What happens if dibbo’s database gets hacked?
Can my barbers see all my clients?
Do you sell or share my client list?
If I leave dibbo, is my data deleted?
Has dibbo had an outside security audit?
Found a security problem?
Email hello@dibbo.io with “Security” in the subject, and the steps to reproduce it. Please don’t look at or change anyone else’s data while you test. The same details are in our security.txt.
Keep your clients to yourself
No commission and no new-client fees. Get early access and we’ll help you set up your shop.