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, copy them to a server or alter them, and unplugging the drive leaves the record in place, marked as offline.

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, https://www.googleapis.com/auth/gmail.readonly, which Google classifies as restricted. Grind asks for it on its own, from Settings, and only to read delivery-failure notices so it can tell you a message bounced. Refusing it costs you bounce reporting and nothing else: sending works without it.

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 not open. Nothing on this site can charge a card, and no checkout URL of any provider exists in this build. That is checked by a test which reads every byte of the built site.

When they open, a checkout will be created server-side for one signed-in account, and access will be granted by the payment provider’s webhook and by nothing else. The success page will read no parameter from its URL: anyone can type a query string, so a page that trusts one is showing a visitor their own input and calling it a receipt.

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.

What is not claimed here

Grind has no SOC 2 report, no ISO certification and no third-party security audit. It has not been penetration tested. There is no bug bounty.

Those are real things with real evidence behind them, and this page will say so on the day the evidence exists. Until then, claiming any of them would be the one thing a security page must never do.

Reporting something

If you find a vulnerability, write to security@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.