What Mastrly does with your data.

at a glance

In one paragraph

When you sign in with Dropbox or Google, Mastrly receives a per-folder OAuth token from the chosen provider — on Google this is the drive.file + drive.appdata pair; on Dropbox it’s the App-folder scope set described below. Either way Mastrly is granted access only to a single workspace folder (/mastrly on Google, or /Apps/mastrly/ on Dropbox) plus a small per-app configuration store. Tokens stay in your browser’s localStorage. Mastrly does not run servers that store your masters, your tokens, or your activity. The app itself uses no analytics, advertising, or third-party trackers. The marketing pages on this domain count page views without cookies, and, only if you accept them, also use Google Analytics cookies; both are described under who else is involved. The third parties involved are Dropbox or Google (where your data lives) and whichever static web host serves the Mastrly bundle — your own host if you self-host, or ours (Cloudflare Pages, under our account) if you use our hosting at mastrly.cloud. See hosted version.

data accessed

What Dropbox or Google data Mastrly accesses

The exact OAuth scopes Mastrly requests depend on which storage provider you sign in with. Both providers’ scope sets are deliberately scoped to a single workspace + a hidden per-app sandbox; neither triggers a sensitive-scope security review.

Google Drive scopes

• https://www.googleapis.com/auth/drive.file — per-file access to a single workspace folder.
• https://www.googleapis.com/auth/drive.appdata — access to a hidden per-app sandbox that only Mastrly can see.

Dropbox scopes

Mastrly is registered as a Dropbox App folder app, which automatically sandboxes every read/write to a single folder named /Apps/mastrly/ inside your Dropbox. On top of that scoping, Mastrly requests:

• files.metadata.read — list folders.
• files.metadata.write — create / rename / move folders & files.
• files.content.read — download audio masters for playback & preview.
• files.content.write — upload audio masters into the workspace.
• sharing.read — read existing public share links.
• sharing.write — create and revoke public share links for listener manifests.
• account_info.read — basic profile (display name + email) for the “signed in as” label.

Together these grant Mastrly access only to:

• A single workspace folder — /mastrly at the top of your Google Drive, or /Apps/mastrly/ inside your Dropbox. Mastrly creates this folder during first-time setup; if you already have one from a previous install, Mastrly attaches to it instead. Mastrly can read, list, and modify the files and sub-folders inside that workspace.
• A hidden per-app sandbox where Mastrly stores a pointer to your workspace folder and a small JSON file describing your clients and projects. On Google Drive this is the appDataFolder (invisible in your Drive UI). On Dropbox there is no equivalent sandbox, so Mastrly puts the same JSON inside a conventionally-hidden subfolder named /.mastrly-private/ inside the App folder; it is visible to you but is scoped to Mastrly.

Mastrly cannot see, list, read, or modify any other file in your Dropbox or Google Drive. It cannot access your email, contacts, calendar, profile photo, or any other service the provider offers.

During sign-in, Dropbox or Google also returns your basic profile identifier and refresh-token metadata. These stay in your browser’s localStorage and are never transmitted to any Mastrly-controlled server.

how it’s used

How that data is used

Mastrly uses the Dropbox or Google Drive access for exactly the following:

• Reading masters you have placed in the workspace folder, so they can be played in the in-browser audition player.
• Listing folders and files in the workspace so the app can show your clients and projects.
• Writing metadata into the per-app sandbox (Google’s appDataFolder, or Dropbox’s /.mastrly-private/ subfolder) — small JSON files describing your clients and projects, plus a pointer to your workspace folder so Mastrly can find it again on another device.
• Writing share manifests into a _shares/ folder inside your workspace — small JSON files that public listener links resolve against. (These have to live in the workspace, not the hidden sandbox, because listener browsers fetch them by public URL.)
• Polling the provider’s change feed (Drive’s changes.list or Dropbox’s list_folder/continue cursor) so renames or deletes you make directly in your storage show up in Mastrly within ~30 seconds.
• Playing audio directly from your storage to your client’s browser when they open a share link.

Mastrly does not use your data for advertising, analytics, machine-learning training, or to build a profile of you. It does not sell, rent, or otherwise transfer your data to any third party. It does not aggregate data across users — there is no “across users” because there is no central database.

storage & retention

Where data is stored, and for how long

• Your masters and project files live in your own Dropbox or Google Drive — in the /mastrly workspace folder on Google, or /Apps/mastrly/ on Dropbox — that Mastrly created during setup. They are subject to your storage provider’s storage and retention policy, not Mastrly’s. You can move, copy, rename, or delete any of them in the provider’s own UI at any time.
• OAuth tokens (access + refresh) are stored in your browser’s localStorage on the origin where Mastrly runs (e.g. masters.yourstudio.com or mastrly.cloud). They are never transmitted to any Mastrly-operated server. Clearing your browser data removes them.
• Local app state (your last-viewed project, theme choice, prefetch cache for fast playback) is stored in localStorage and IndexedDB on the origin where Mastrly runs. It is local-only and can be cleared from your browser at any time.
• Share links point at items in your Dropbox or Google Drive that you have explicitly shared through the provider. To revoke, delete the corresponding share record inside Mastrly — the link stops working immediately.

Mastrly runs no application server and no database, so there is no account, profile, or activity history to delete — nothing about what you do inside the app is recorded anywhere we control. If you use the version we host, the one exception is ordinary web-server request records for serving you the page, described in full under hosted version.

sign-in flow

The auth.mastrly.cloud redirect

When you sign in with Dropbox or Google, the OAuth flow redirects through a static page at https://auth.mastrly.cloud/. This is a stateless callback — it has no server-side logic, no database, and runs entirely in your browser. Its only job is to forward the OAuth response back to whichever licensed Mastrly origin started the flow.

The callback verifies the originating origin against a public allow-list of licensed deployments. It does not see, store, or transmit your tokens; the OAuth code travels through the URL fragment and is consumed by your originating Mastrly instance, not by auth.mastrly.cloud.

hosted version

If you use our hosting at mastrly.cloud

The copy we host and a copy you host yourself are the same application, byte for byte, and a licence works identically on either. The only difference that matters here is who serves the page to your browser — worth spelling out precisely rather than glossing.

Our hosting is Cloudflare Pages, under our own Cloudflare account. That makes us your web host, so the ordinary consequences of being someone’s web host apply:

• Cloudflare processes every request for the page and its assets, and in doing so handles your IP address, user agent, the URL requested, the timestamp, and the response status — the same record any web server anywhere produces.
• Cloudflare’s dashboard shows us aggregate analytics for the site: request counts, rough geography, and which paths were requested. We do not run Logpush or any raw-log export, so we hold no per-request log of our own, and we have never built any tooling to look up an individual visitor.
• Share links are part of the URL, so they are part of that request metadata. A listener link is mastrly.cloud/s/<token>, and the token sits in the path. It is therefore visible to Cloudflare in the normal course of serving the request, and a token could in principle appear in path-level analytics. The code path itself does nothing with it: a small Pages Function matches /s/ and /S/ and rewrites the request to the app shell so the in-browser router can read the token. It does not parse, store, transmit, or log the token, and the manifest that the token resolves against is fetched by the listener’s browser directly from your Dropbox or Google Drive — never through us.
• Cloudflare enables Network Error Logging on proxied domains, including ours. Your browser is told it may report failed requests — DNS failures, dropped connections, TLS errors — to a.nel.cloudflare.com. The policy we serve sets success_fraction: 0.0, so successful requests are never reported. These reports go to Cloudflare, not to us; we see nothing from them. We are listing it because it is a browser sending data to a third party as a result of visiting our site, and you deserve to know that it happens. The same applies to any self-hosted Mastrly behind Cloudflare.

What this does not include is the part that actually matters: your audio never passes through us, and neither does anything about it. Files stream directly from your Dropbox or Google Drive to the browser playing them. Your OAuth tokens, your file and folder names, your client and project metadata, and your listening activity inside the app are never sent to us and never touch our infrastructure. We cannot see what you master, who you send it to, or what they do with it. There is no account, no database, and nothing for us to look up.

Two honest consequences of using our hosting rather than your own deployment, stated plainly:

• We can change the application you are using, because we deploy it. Self-hosters hold their own copy and we cannot touch it — in exchange, they update it themselves.
• If you want us to have no request metadata about you at all — not even a page load — self-host. That is the whole difference, and it is a legitimate reason to choose it.

third parties

Who else is involved

• Google — OAuth provider and storage host when you sign in with a Google account. Subject to Google’s privacy policy.
• Dropbox — OAuth provider and storage host when you sign in with a Dropbox account. Subject to Dropbox’s privacy policy.
• Your own static web host, if you self-host (Cloudflare Pages, Netlify, your own server, etc.) — serves the Mastrly bundle and may keep request logs. Subject to that host’s privacy policy, and outside our sight entirely.
• Cloudflare, if you use our hosting — mastrly.cloud runs on Cloudflare Pages under our account, so Cloudflare processes request metadata for every page load and is our processor for it. Subject to Cloudflare’s privacy policy. Set out in full under hosted version.
• Google Analytics, on the marketing pages only and only if you accept analytics cookies — provided by Google, which acts as our processor under the Google Analytics data processing terms. Subject to Google’s privacy policy and described below.

The Mastrly app embeds no analytics, advertising or telemetry SDK of any kind — no Google Analytics, Meta Pixel, Hotjar, Segment, Mixpanel or Sentry. Nothing served under /app/ reports anything to us or to anyone else, and that is not going to change.

The marketing pages — this one, the overview, pricing, user guide and download pages — do load Cloudflare Web Analytics, so we can tell which pages people actually read. It is cookieless and issues no identifier: nothing is stored on your device, no fingerprint is taken, and there is nothing in it that follows you to another site or joins two of your visits together. It gives us counts — page views, referrers, countries, browsers — never individuals. We deliberately did not switch it on at the Cloudflare edge, because edge injection applies to the whole domain and would have put it on the app as well.

The same marketing pages also offer Google Analytics, which loads only after you click Accept on the cookie banner. Until then nothing is requested from Google and no Google cookie is set. If you accept, Google Analytics sets cookies that let it recognise your browser across visits to these pages, and records the pages you view, how you arrived (for example from a search engine, an advertisement or another site), the approximate location derived from your IP address, and your device and browser type. Google Analytics does not store IP addresses. We use the reports to understand which pages and which sources of visitors are useful, and for no other purpose. We do not enable Google’s advertising features, its Google Signals cross-device reporting, or the sharing of this data with other Google products, and we do not use it to identify you. The legal basis is your consent, which you can withdraw at any time through the cookie settings link at the foot of each marketing page. Google retains the data for two months and may process it in the United States; such transfers rely on the UK Extension to the EU–US Data Privacy Framework, under which Google is certified.

cookies

Cookies

The Mastrly app does not set cookies. State is held in localStorage and IndexedDB in your browser. Dropbox or Google may set its own cookies on its own domains during sign-in; those are governed by Dropbox or Google’s privacy policy. On the version we host, Cloudflare may set its own security cookies (such as __cf_bm, used for bot management) on mastrly.cloud. These are Cloudflare’s, not ours, and carry no identifier we issue or read. The Cloudflare Web Analytics on our marketing pages sets no cookie at all — see who else is involved.

The marketing pages (overview, pricing, user guide, download, this policy and the terms) set cookies only if you accept them in the cookie banner:

• _ga — set by Google Analytics to distinguish browsers; expires after 400 days.
• _ga_<container-id> — set by Google Analytics to keep track of the current visit; expires after 400 days.

Your answer to the banner is remembered in your browser’s localStorage under mastrly:analytics-consent, so that you are not asked on every page. This entry is never sent anywhere. To change your answer, use the cookie settings link at the foot of any marketing page. Declining after accepting deletes the Google Analytics cookies from this site.

children

Use by children

Mastrly is a professional tool for mix and mastering studios. It is not directed at children under 13 (or 16 in jurisdictions that apply that threshold), and it does not knowingly collect data from them.

your rights

Your rights

Because Mastrly does not hold your data on a server it controls, most data-subject rights resolve in your own Dropbox or Google Drive and in your browser:

• Access / portability: your masters are already in your Dropbox or Google Drive in their original formats — nothing to export.
• Erasure: delete the files in your Dropbox or Google Drive, or delete the workspace folder (/mastrly on Google, /Apps/mastrly/ on Dropbox); Mastrly stops being able to see them. Revoking Mastrly’s access at the provider also clears the hidden per-app sandbox. Clearing browser data on the Mastrly origin removes the token and local cache.
• Revoke access: for Google Drive, visit myaccount.google.com/permissions and remove Mastrly; for Dropbox, visit dropbox.com/account/connected_apps and unlink Mastrly. The OAuth token is invalidated immediately.
• Hosted request metadata: if you used our hosting and want to know what exists about you, write to us. The honest answer is that we hold no per-request logs of our own and have no way to identify an individual within Cloudflare’s aggregate analytics — self-hosting avoids the question entirely.
• Google Analytics: if you accepted analytics cookies, you can withdraw consent with the cookie settings link at the foot of any marketing page, and clearing this site’s cookies removes the identifier. Because we do not link Google Analytics data to names or email addresses, we are usually unable to find an individual’s records in it; write to us and we will help where we can.
• Complaint: UK residents can complain to the Information Commissioner’s Office (ico.org.uk).

changes

Changes to this policy

When this policy changes materially, the effective date at the top will be updated and a note will appear on the Mastrly home page for at least thirty days.

contact

Contact

Mastrly is operated by Mark Hammond, a sole trader based in the United Kingdom. Privacy questions, data requests, and policy questions: hello@mastrly.cloud.