Security

We collect as little as we can, keep each place's data apart, and say plainly what we do.

What we do

Collect less. We don't ask customers who they are. We leave cost, supplier and margin columns out of imported items.
Per-place isolation. Database access rules and checks in our code keep each place's records apart.
Visit-gated access. An assistant can read only the one place its user is checked in to, during an active visit. Only a new check-in extends it.
Encryption. HTTPS everywhere with HSTS. Square tokens are encrypted with a per-place key. Backups are encrypted at rest.
Abuse controls. Rate limits on check-in codes, sign-ins, uploads and text messages, with daily caps on texts. Check-in codes are single-use, short-lived and stored only as hashes.
Authorization. Assistants connect through OAuth 2.1 with PKCE and short-lived tokens. Unrecognized clients aren't accepted, and staff replies by text need a reply code and a verified number.
Least access. No standing employee access to a place's data; any access is logged and shown to the owner. Secrets live in server configuration, and production servers refuse to start with test settings.
Review. We had our code security-reviewed before launch and have fixed, or written down, what the review found.

If you find a security problem, please email security@askthesign.com. Machine-readable contact: security.txt.

Tell us what you found, how to reproduce it, and what you think the impact is.
We aim to acknowledge reports within 3 business days and keep you updated.
Please give us reasonable time to fix a problem before disclosing it, and don't access, change or delete other people's data, disrupt the service, or run tests against real places or customers beyond what is needed to show the issue.
If you act in good faith under these guidelines, we won't pursue legal action against you.
We don't run a paid bug bounty yet, but will credit you if you like.