Data and privacy
This page describes what the code running at granitegranted.com does with
data today. Granite’s privacy policy is
the legal statement.
What Granite stores
About a person. Granite signs people in with ChirpAuth and asks only for
the openid scope. It learns a ChirpAuth subject id for the person, specific
to Granite, and no email address or name. It stores:
| Data | Contents |
|---|---|
| Approval requests | Everything the app sent (see File a request), the app’s id for the person (requester_user_ref), the requesting app and agent, timestamps, and the outcome. The callback_secret is stored encrypted. |
| Decisions | Who decided, approve or deny, approved scopes and limits, the reason, when, and the signature chain. |
| Grants | Subject, resources, scopes, limits, expiry, status, and when it was revoked. A revocation is also kept as a signed record on the person’s decision log, naming who revoked it: the person, the app, or a verified service. |
| App links | Which person an app’s x-user-id refers to, recorded when the person claims a request or confirms a connection. |
| Connections | Connection requests and whether the person confirmed them. |
| Devices | For people using Granite’s Android app: a Firebase Cloud Messaging push token and the platform. |
| Notification setting | minimal or detailed push text. |
| Warden key list | The id and algorithm of each Warden passkey the person registered. The public key itself is held by ChirpAuth. |
About apps. The app id, display name, description, and a hash of the app’s secret. Each registration, rename and secret change is also kept as a signed record naming the operator who made it.
Logs. Operational logs (request ids, errors) are kept for 14 days.
Granite runs on AWS in the us-east-1 region (United States). Push
notifications go through Google’s Firebase Cloud Messaging and always carry
the request’s title and risk level; with the detailed setting they also
name the app, action and resource.
How long
Granite deletes nothing on a schedule. Requests, decisions and grants are kept after they are decided, withdrawn, expired or revoked. Logs are the exception, at 14 days.
Who sees what
- The app that filed a request can read it, including the outcome, the
person’s
reasonif they gave one, and, once the request is bound, the person’s Granite id (owner_uid). That id is the same for every app. - A service checking a grant sees the grant, including
owner_uid. - The decision webhook omits
owner_uid. - The person sees everything above that concerns them, and can download
it:
GET /v1/me/export, or “Export my data” in the app. The export holds their requests, decisions and revocation records (with the signed end of their decision log), grants, devices (without the push token), notification setting, the apps that remember them (app links) and their confirmed connections. It does not include the Warden key list.
What deleting an account does
A person deletes their Granite account with “Delete account” in the app, or
DELETE /v1/me. This marks their requests, decisions, revocation records,
grants, devices,
notification setting and Warden key list deleted:
- Granite’s API stops returning them;
- the copies of app-filed requests they claimed, their app links and their connections are erased too, so an app’s next request for them files unbound instead of reaching the deleted account;
- their grants stop verifying: checking one returns
404; - each Warden key Granite enrolled for them is revoked in ChirpAuth’s key directory first, so approvals signed with it are refused. If a key can’t be revoked, nothing is deleted and the request fails, so it can be retried.
Deleting the ChirpAuth account does the same. ChirpAuth tells Granite, with a signed message, that the account was deleted, and Granite runs this same deletion for it.
A person can also revoke one Warden key without deleting the account: “Revoke” on the Manage Warden keys screen. A revoked key can’t be enrolled again.
Not yet:
- Permanent removal of the person’s data from Granite’s storage.