How we think about it
Rarity keeps as little personal data as it can, keeps it for as short a time as it can, and keeps it where only the app and the people who run it can reach it. Most of the security work is in what we chose not to collect: no payment details, no addresses, no raw IP addresses.
What we do
- Encryption in transit: every connection to the app, the storefront widgets, Shopify and our email provider uses HTTPS. The app refuses storefront and webhook requests that fail Shopify's signature check.
- Encryption at rest: the production database and its backups sit on encrypted storage with our hosting provider. Merchant integration credentials are encrypted a second time inside the database.
- Access: production access is limited to the people who operate Rarity, behind multi-factor authentication. Secrets live in the host's environment configuration, never in code or chat.
- Access logging: the app records when a merchant views a collector's details. Host-level access to production is logged by the hosting provider.
- Isolation: every database query is scoped to the store making the request. Staging and production are separate apps with separate databases, and production data is never copied elsewhere.
- Data loss prevention: automatic encrypted backups, a restore procedure we test at least twice a year, and the access controls above.
- Abuse controls: bidder email verification, rate limits per bidder and per IP hash, risk scoring and merchant-controlled blocking.
- Dependencies: the app runs on maintained versions of its framework and libraries, and we review dependency advisories as part of each release.
What counts as an incident
Anything that leads, or could lead, to personal data being lost, altered, disclosed or accessed without authorisation. Examples: a leaked credential, a bug that shows one store's data to another, a compromised sub-processor, a lost backup. Downtime on its own is not a data incident, though we treat it with the same urgency.
How we respond
Who: the operator of Rarity, reachable at alex@gocallio.com, owns incident response end to end.
- Contain, within hours. Rotate exposed credentials, disable the affected path or take the app offline if needed.
- Assess, within 24 hours. Work out what data, which stores and how many people are affected, and how it happened.
- Notify, within 72 hours. See the next section.
- Fix and verify. Ship the fix, confirm it, and check whether the same weakness exists anywhere else.
- Review. Write up what happened and what changes so it doesn't happen again.
How merchants are told
Affected merchants are emailed at their store's contact address within 72 hours of us becoming aware of an incident that affects their data, even if our assessment is not yet complete. The email says what happened, what data and how many people are involved as far as we know, what we've done, what we recommend they do, and when the next update will come. We also post a notice in the app. Where a merchant needs to notify their own shoppers or a regulator, we give them what they need to do so.
How it's recorded
Every incident, including near-misses, is logged in a private incident register with: date detected, how it was detected, what was affected, timeline of actions, who was notified and when, root cause, and follow-up actions with owners. The register is kept for at least five years and is available to merchants and regulators on request as described in the DPA.
Reporting a vulnerability
If you've found a security problem in Rarity, email alex@gocallio.com with enough detail to reproduce it. We'll acknowledge within two business days, keep you informed, and won't take action against good-faith research that avoids accessing other people's data. Please don't run automated scanners against merchants' stores.