Your work stays on your machine.

Where the audio is

On your machine, in the folders you chose, under the names you gave them. Grind builds a catalogue that points at those files. It does not move them, rename them, or copy them to a server, and unplugging the drive leaves the record in place, marked as offline. One thing does write to them: the metadata tagger, when you ask it to, puts your tags into the audio files themselves so they travel with the beat. Nothing else is touched, and nothing writes on its own.

There is exactly one moment audio leaves your computer, and you cause it: you build a pack and send it, and the files go to your own connected Dropbox. Nothing else uploads audio, ever.

What actually leaves the machine

• The pack you build and send, to your own Dropbox.
• The message you compose, through your own Gmail, addressed to people you chose.
• Lookups against public music-data providers, to match a release and read its public figures. What goes out is a title, an artist name or an identifier. Your catalogue is not sent.
• Your account email and subscription state, to the account service, because that is what an account is.

What the Gmail permission allows

One thing: submitting a message. The scope is https://www.googleapis.com/auth/gmail.send, and it cannot read a message, list your mail, search it, apply a label, archive or delete. Google classifies it as sensitive rather than restricted, which is the difference that matters here.

Two more say which mailbox is connected, so the From line is right: https://www.googleapis.com/auth/userinfo.email and openid. Neither grants access to mail.

What it does not allow, and what is deliberately not requested

Reading your inbox is a separate permission, gmail.readonly, which Google classifies as restricted. Grind does not request it, and cannot read, list, label, archive or delete a single message in your mailbox.

Grind does not request profile, because a name and a photograph are not needed to send an email. It does not request https://mail.google.com/, the full-mailbox scope an SMTP connection would need, and using the Gmail API instead is precisely how that is avoided.

Every grant is revocable at myaccount.google.com/permissions, immediately, without involving Grind.

The account

Accounts are handled by Supabase Auth. Passwords are never seen by Grind: they go from your browser to Supabase, which stores them hashed. Sign-in, confirmation and password reset all run there.

The Supabase key in these pages is the anon key, which is public by design and constrained by row-level security. It is what lets the auth pages work at all. The service-role key is not in this site, is not in the desktop application, and never leaves the server.

What runs where

This site is static files. There is no server rendering, no database connection from a page, and no session held here.

Anything that needs a secret runs in a server function you cannot reach directly: issuing a licence token, receiving a payment webhook, deleting an account. The rule is why there is nothing to find in these pages: if a key can grant something, the browser never holds it.

Payments and webhooks

Subscriptions are handled by Lemon Squeezy.

Deleting your account

Deleting the account is a server function, and it does not consult your plan or your entitlement before running. Losing a subscription is not a reason to lose the ability to delete your data, and that is written into the code rather than into a policy.

Your beats are not affected, because they were never uploaded. They are the files on your drive, exactly where they were.

Reporting something

If you find a vulnerability, write to contact@grindapp.io with enough detail to reproduce it. You will get a human answer. Please do not test against other people’s accounts or data.

The full Google API disclosure is at /google-api-disclosure. What is collected and why is in the privacy policy, and the terms of use are at /terms.