How Mastrly is secured

your storage

Your audio stays in your own storage

On Google Drive, Mastrly requests only the drive.file and drive.appdata scopes. These allow it to see the files it created or that you opened with it, and a hidden folder that only Mastrly can read. On Dropbox, Mastrly is an App folder app, so it can reach nothing outside /Apps/mastrly/. Neither grant lets Mastrly see the rest of your account.

Your client and project records are kept in that hidden area: Drive's appDataFolder, or a /.mastrly-private/ folder inside the Dropbox App folder. Apart from your audio, the only files kept in the visible workspace are share manifests, which a client's player must be able to read.

Sign-in tokens are stored in your browser and are sent only to Google or Dropbox. To withdraw Mastrly's access entirely, remove it from your Google account's third-party access page or from Dropbox's connected apps page; the privacy policy gives the addresses.

sign-in

Signing in

Sign-in uses the OAuth authorisation code flow with PKCE. Your browser creates a one-time secret before leaving for Google or Dropbox and keeps it to itself; the code that comes back is useless without that secret, and a random value is checked on return so that a sign-in cannot be started on your behalf by another site.

The return passes through auth.mastrly.cloud, a static page that forwards the code only to a web address that holds a Mastrly licence. It never sees a token. It is served with a strict content security policy and cannot be placed inside another page.

the app

The app itself

• Mastrly is delivered as a single file. Its content security policy allows a script to run only when it matches a fingerprint recorded at build time, so injected script is refused by the browser.
• The workspace refuses to display inside another website's frame. Only the client player may be embedded, so that studios can place it on their own sites.
• The app contains no advertising or tracking code.
• Every release of the hosted app is checked after deployment by comparing the live file with the one that was built.

sharing

Share links

A share link is built from the storage identifier of a small manifest file: a Google Drive file id, a Dropbox link with its key, or a random 128-bit token on a self-hosted server. These identifiers cannot be guessed. Anyone who holds the link can open the share; anyone who does not, cannot.

When a share is created, the files in it are made readable by link through Google or Dropbox, and nothing else in your storage is. The manifest records the files' names relative to the project, never their full paths.

• Regenerating a share keeps its link and updates what it contains. Files taken out of a share lose their public access.
• Revoking a share removes public access to the manifest and its files, and the link stops working.
• Replacing a link revokes the old one and issues a new one.

The download setting decides whether the player offers a download button. It is not a copy-protection measure: a player has to receive the audio in order to play it, so a recipient with the link and some technical knowledge can save the files. Revoking a share stops further access; it cannot recall files a client has already received.

access codes

Access codes

A share can require a six-digit access code. The manifest is then published encrypted with AES-256-GCM, under a key derived from the code with one million rounds of PBKDF2-SHA256 and a fresh random salt each time it is published. Track names, file addresses and the client's name are inside the encrypted manifest.

An access code stops a forwarded link from being opened by someone who was not also given the code. It is not a substitute for keeping the link private: because the code is short, a determined person who holds the link can work it out. To withdraw access from someone who has the link, revoke or replace it.

client player

The client player

• Names, messages and studio details from a manifest are shown as text. The sender's message passes through a filter that keeps only basic formatting and ordinary links.
• A share link can load a manifest only from Google Drive, Dropbox or, for a self-hosted studio, the studio's own server.
• Studio branding is loaded only from the studio's own storage, and every colour in a custom theme is checked before it is applied.
• The player needs no account and stores nothing on the client's device beyond its playback cache, the links the client has opened and, for a locked share, the code the client entered.

connect

Feedback and messages (Connect)

Messages between a studio and its clients are encrypted in the browser or app before they are sent. The Connect service at connect.mastrly.cloud stores and relays only encrypted messages and cannot read them. Each share link has its own conversation key, which only the studio and the clients it admits hold.

• A client joins with a personal code from the studio. Repeated wrong codes are slowed down and then refused.
• Removing a person replaces the conversation key, so later messages cannot be read with the old one.
• Linking the studio's phone requires scanning a code shown on screen and the engineer's confirmation of the phone by name. The pairing is protected so that the service cannot substitute a device of its own.
• Push notifications carry no message content. The phone fetches the encrypted message and decrypts it itself.
• Messages are deleted from the service after 90 days. Switching Connect off erases the studio's conversations, members and linked phones from the service.

Encryption in the browser relies on the app code that is delivered to it. When you use the hosted app, that code is served by us; a studio that hosts Mastrly itself serves its own copy.

mobile apps

The iPhone and Android apps

• Keys for a linked studio phone are kept in the iOS Keychain, limited to that device, or sealed under the Android Keystore.
• The Android app's data is excluded from cloud backup.
• On Android, playback controls and track titles are offered only to the system, Bluetooth, Android Auto and apps the phone already trusts with media control.
• Locked shares are opened with the same encryption and the same limits as in the browser.

licences and payment

Licences and payment

A licence key is signed by Mastrly and checked by the app without contacting any server. A key bought for a domain works only on that domain, with and without www., and on the hosted app at mastrly.cloud. Before a key is issued for a domain, the buyer proves control of it by receiving a code at an address on that domain.

Payment is taken by Stripe on Stripe's own checkout page. Mastrly never receives card details. A key is created only after Stripe confirms that payment has been received.

self-hosting

Self-hosting

A studio can run the Mastrly gateway on its own server, so that the app, the share links and the audio are all served from the studio's own domain.

• Enrolment. A browser is admitted only with a one-time code generated on the server by its owner. The code lasts an hour, is cancelled after five wrong attempts, and requires a valid self-hosting licence.
• Signed requests. Each enrolled browser holds a private key that cannot be exported from it, and signs every request. Requests older than a minute and repeated requests are refused, and removing a device takes effect at once.
• Files. The gateway reads audio where it already is and never writes to it. Every file path is checked to stay within the folders the owner configured. Files are served so that they cannot run script on the studio's site.
• The service. The gateway runs under its own system account with read access to the audio, write access only to its own data directory, and the operating system's protections for system files and home directories switched on. By default it accepts connections only from the server itself, behind a Cloudflare Tunnel.
• Installation. The installer checks every file it downloads against a published SHA-256 checksum before using it, and backs up the existing installation before an upgrade.

limits

What Mastrly cannot protect against

• Someone who has a share link, or is sent one, can open that share. Keep links as private as the audio they lead to.
• Anyone with access to your Google or Dropbox account, or to a browser in which you are signed in, has access to your Mastrly workspace.
• Files a client has already played or downloaded remain on their device after a share is revoked.
• The protection Mastrly gives your storage cannot exceed the protection of the account itself. Use two-step verification with Google and Dropbox.

reporting

Reporting a security problem

If you believe you have found a security problem in Mastrly, write to hello@mastrly.cloud with the details. Please do not publish it until it has been addressed. Every report is read and answered.