Privacy Policy

What we collect, why, and the rights you have over it.

Summary

Mivia Sign collects very little. We measure how the service is used so we can improve it, all kept in our own database. We don't run third-party analytics like Google Analytics, PostHog, or Mixpanel. We don't sell data and we don't share it for third-party marketing. We use Cloudflare to host the service, Stripe to bill subscriptions, and Resend to send transactional email. If we ever add a newsletter or optional tracking, we'll ask for consent first. Everything below is detail.

Who we are

The data controller is Venezia LLC, a Wyoming limited liability company trading as Mivia. You can reach our privacy contact at [email protected].

You are responsible for the accuracy of the information you give us, including your account details and any recipient labels you attach to signed tracks. Please keep it up to date.

Data we collect

When you create an account

  • Your email address. Used for sign-in and account-related email.
  • A display name, shown in your account and on anything you choose to share.
  • A username, if you claim one.
  • A salted hash of your password, produced by a modern memory-hard key-derivation function. We never see or store the password itself.
  • The date you joined.
  • Your country at sign-up time, derived by Cloudflare from your IP address. We use it only for aggregate statistics ("how many of our users are in the UK?") and to determine which data-protection rules apply to your account.
  • The page on our site you were viewing when you started sign-up, and the external site that linked you here if there was one. We use these to understand which channels bring people to Mivia. We never store the full URL beyond our own site.
  • The marketing-attribution tags (utm_source, utm_medium, utm_campaign) from the link you arrived on, if any. These are added by the sender of the link, not by you, and tell us which campaign or partner referred you. Same purpose as the referrer above.
  • A timestamp of when you most recently used the service. Updated at most once per hour while you are signed in, and used only to compute how many users are active in a given week.

When you set up extra sign-in methods

If you register a passkey or turn on two-factor authentication, we store what we need to verify you on later sign-ins.

Passkeys. For each passkey you register we store:

  • The credential ID and public key returned by your device. The matching private key never reaches us, and we have no way to use, recover, or copy it.
  • A label captured from your browser's user-agent at the time of enrolment (for example Mac · Safari), so you can tell your enrolled keys apart in account settings.
  • Whether the key is built into the device or a separate hardware key, whether it's synced across your devices (for example, via iCloud Keychain), the connection methods it supports (USB, NFC, or built-in), and the timestamp the key was created.
  • A counter that goes up on each sign-in, used to spot cloned credentials.

You can remove a passkey at any time from /settings. Removal is immediate: the public key is deleted from our database and that credential can no longer sign you in. You'll need to enrol a new passkey if you want to use that device again.

Two-factor authentication. If you turn 2FA on, we store:

  • The shared secret your authenticator app uses to generate the six-digit codes. It is used only to check a code you submit at sign-in.
  • The nine single-use backup codes generated when you enabled 2FA, so we can match a code you enter against them and mark each one used. They are shown to you only once when generated, so save them somewhere safe before you close that page.
  • A flag that 2FA is enabled on your account.

You can disable 2FA from /settings by confirming your password. Disabling deletes the shared secret and the backup codes from our database. Regenerating your backup codes invalidates all the previous codes.

When you change a preference

Settings you choose from /settings are stored on your account so they apply on every sign-in. These include whether other people can add you as a collaborator on their tracks, your scan-message text if you've enabled one, and which optional Mivia emails you receive (collaborator activity, plugin updates, news and updates, and on Mivia Pro, scan alerts, the weekly digest, and anomaly alerts). Account-essential emails (verification, password resets, change confirmations, two-factor and passkey alerts, account-deletion confirmation, and welcomes when you sign up or upgrade to Mivia Pro) always send and aren't tied to a preference.

When we email you about a security change

Security-relevant changes to your account (password or email changed, two-factor authentication enabled or disabled, passkey added or removed, an account- deletion request) trigger a notification email so you can spot anything you didn't do. To help you tell whether the action was yours, each of these emails includes:

  • The time of the action.
  • The browser and operating system the request came from (for example, Chrome on macOS).
  • An approximate country and city, derived from the IP by Cloudflare's edge geolocation. We do not store latitude, longitude, postal code, or timezone.

We do not keep a separate audit log of these details in our database. They are captured at the moment of the action and included in the email so you have a permanent record in your inbox. The same details are visible to Cloudflare, which serves the request, and to Resend, which delivers the email, as part of the message content.

When you sign a track

  • The Mivia ID that identifies the signed audio. It's a 16-character code (the first 16 hex characters of the file's SHA-256), and it's the public lookup key: anyone with the ID can open the matching public certificate at /database or by visiting /c/<id> directly. We store an 8-byte prefix shown publicly as that 16-character ID, plus the full SHA-256 hash internally for verification.
  • The public half of your signing key.
  • A timestamp and an OpenTimestamps proof anchored to the Bitcoin blockchain.
  • Metadata you attach: track title, creator name, duration, and recipient labels if you sign for a named recipient. See Recipient labels and third parties for how we treat those.
  • The plugin version and operating-system family used to produce the signature (for example darwin-arm64 or win32-x64).

The audio you submit at /sign is uploaded only long enough to sign it. We pass it to the signer, then delete the temporary copy as soon as the signed file is delivered back to you. The Mivia Sign plugin works the same way. We do not keep the original audio file in either case.

When someone scans a track that matches one of yours

Anyone, including people without a Mivia account, can scan audio at /scan. If a scan matches one of your signed tracks, we record:

  • A SHA-256 hash of the scanner's IP combined with the matched track's Mivia ID. The raw IP is not stored. We treat this hash as pseudonymised personal data: on its own it is not enough to identify a scanner, but we apply the same protections to it as to other personal data.
  • An approximate country, city, and region, derived from the IP by Cloudflare's edge geolocation. We do not store latitude, longitude, postal code, or timezone.
  • The browser's user-agent string, truncated to 200 characters.
  • Which manifest matched, and the recipient label if the file was a per-recipient watermarked copy.

These records are visible only to the owner of the matched track, in the track's Activity feed. Geolocation is shown to the owner, never to collaborators on the same track. We do not build a profile across scans, do not correlate scans across different manifests, and do not share scan metadata with anyone other than the matched track's owner.

The audio you submit at /scan is uploaded only long enough to identify it. We pass it to the decoder, then delete the temporary copy regardless of whether a watermark was found. We do not keep scan audio.

When you use the scan endpoint

Separately from the scan-event records above, which only land when a scan matches and surface to the matched track's owner, we keep a short log of every visit to /scan so we can measure how the decoder is performing. For each attempt we record:

  • A timestamp.
  • The size of the file you uploaded.
  • How long the decode took.
  • The outcome (matched, no signature found, audio could not be parsed, or backend error).
  • If a match was found, which manifest matched and which detection layer fired.
  • An approximate country, derived from the IP by Cloudflare's edge geolocation.
  • Your account ID if you were signed in. Anonymous scans are recorded without one.

We use these to measure scan throughput, error rates, and decoder performance across the audio formats people send us. They are internal to Mivia and are not visible to manifest owners.

When you pair the DAW plugin

  • A device name (up to 100 characters), so you can recognise your machines in the plugin list.
  • The platform string the plugin reports (up to 40 characters).
  • The plugin's client version.
  • The pairing time and the time you most recently used it.

The plugin does not send continuous telemetry. It records the events you trigger explicitly: pairing, and signing a track.

When you subscribe to Pro

Stripe handles payment. They collect card details directly; we never see your card number. In our own database we keep three Stripe identifiers: a customer ID, a subscription ID, and the price ID of your current plan. We do not store the last four digits of your card, the card brand, or your billing country. That information stays with Stripe and is governed by their privacy policy.

When you cancel Pro

If you cancel from Stripe's billing portal and pick a reason from the list Stripe shows you, that reason and any free-text feedback you write are sent to us with the cancellation event. We store them so we can see in aggregate why people leave and improve the product. The reason is not linked to anything you publish on Mivia and is not shared with anyone else. Skipping the survey is fine, the cancellation still goes through.

Service-usage timestamps

To understand who uses Mivia and how, we record a small number of timestamps against your account:

  • The first time you signed a track.
  • The first time you paired the DAW plugin.
  • The first time someone other than you scanned one of your signed tracks.
  • The first time you added a collaborator to a track.
  • The first time you reached the Free-tier sign limit, if you ever did.
  • The first time you upgraded to Pro.
  • The most recent time we saw activity on your account. Refreshed at most once an hour while you are signed in.

We use these to compute retention curves, conversion rates, and similar aggregate measurements that help us decide what to work on next. The figures we report from them never identify you individually.

Operational logs

Cloudflare records standard request logs for the service (timestamp, status, IP, user-agent, path). These logs include your raw IP address and are retained by Cloudflare under their standard policies. We use them only for debugging and abuse response. They are not used to build user profiles.

How we use it

  • To run the service: sign and verify tracks, manage your account, enforce quotas, deliver per-recipient watermarks.
  • To secure the service: rate-limit scans, detect abuse, investigate suspected fraud.
  • To communicate with you: password resets, billing receipts, and a small number of service notices (security incidents, planned downtime, terms changes).
  • To measure and improve the service: compute aggregate statistics on signups, retention, scan success rates, and feature usage so we can decide what to build next. Aggregate figures do not identify individual users.
  • To meet legal obligations: tax records and responses to lawful requests. See Lawful disclosure.

We don't run marketing campaigns, send newsletters, or sell user lists. If that changes, we'll tell you and ask for consent first.

We may produce aggregate or de-identified statistics about how the service is used (for example, the number of scans served in a month). Aggregate figures do not identify any individual and are not subject to deletion requests.

Who we work with

We use a small set of providers to run Mivia Sign. Each is bound by a data-processing agreement.

  • Cloudflare (United States, global edge) hosts the website, runs the serverless functions that handle requests, stores the D1 database, and provides DDoS protection. Cloudflare's edge also derives the country, city, and region we save against scan events. Cloudflare is certified under the EU-U.S. Data Privacy Framework, the UK Extension, and the Swiss-U.S. DPF. See Cloudflare's privacy policy and their customer DPA.
  • Stripe (United States and Ireland) processes payments and manages subscriptions. We share your email, name, and chosen plan; Stripe collects card details directly from you. Stripe is certified under the EU-U.S. Data Privacy Framework, the UK Extension, and the Swiss-U.S. DPF. See Stripe's privacy policy.
  • Resend (United States) sends our transactional and notification email: welcome messages when you create an account or upgrade to Mivia Pro, email-verification messages to confirm your email address, password resets, account-activity notifications (password changed, email changed, two-factor or passkey settings changed, account-deletion confirmations), collaborator-activity emails when someone adds you to a track, plugin-update notices, and on Mivia Pro, scan alerts, the weekly activity digest, and anomaly alerts. We also send occasional product news and feature updates which you can turn off from /settings. Payment receipts come directly from Stripe, not from us. We share the recipient email and the message content with Resend. Resend is certified under the EU-U.S. Data Privacy Framework and the UK Extension; transfers covered by neither rely on Standard Contractual Clauses. Resend does not use the email for its own purposes. See Resend's privacy policy.

We do not use Google Analytics, Plausible, PostHog, Mixpanel, or any other analytics tool. We do not embed Google Fonts, YouTube, or social pixels. We host our own fonts.

We do not sell personal data. We do not share personal data for third-party marketing.

Cookies and browser storage

Mivia Sign sets only the cookies it needs to keep you signed in, plus the cookies Stripe sets when you check out. Under the EU ePrivacy Directive (Article 5(3)) and the UK Privacy and Electronic Communications Regulations (PECR, Regulation 6), as clarified by the ICO's 2025 guidance on storage and access technologies, strictly-necessary cookies are exempt from the consent-banner requirement. We don't run a banner because there is nothing optional for it to ask about. We don't combine session cookies with any other tracking, and we don't re-use them for analytics or advertising.

Cookies

  • better-auth.session_token: a signed session cookie. HttpOnly, Secure, SameSite=Lax, Path=/. Expires 30 days after sign-in, refreshed daily while you're active. Set by the Better Auth library.
  • Stripe sets its own cookies on its domains during checkout. Those are covered by Stripe's privacy policy.

Browser local storage

We cache a few non-sensitive hints in your browser's localStorage so the app paints correctly on return visits before the session request finishes. None of them contain credentials, payment data, or any of the audio you've signed.

  • mivia-tier: your current tier (free or premium).
  • mivia-billing-period: monthly or annual.
  • mivia-name, mivia-email and mivia-username: your display name, email, and chosen username, so the nav and account form prefill without waiting on the server.
  • mivia-has-plugin and mivia-plugin-downloaded: whether you've paired the DAW plugin or downloaded an installer, so we can show the right calls-to-action.
  • mivia-seed: the string used to draw your generated avatar.
  • mivia.attribution.v1: marketing-attribution tags (utm_source, utm_medium, utm_campaign) and external referrer captured on your first visit. Held only until you sign up, then sent to the server and removed from your browser.

Because some of these items (your name and email) contain personal data, they are covered by the rights and retention sections of this policy. Signing out clears all of them except the plugin-downloaded flag, which only persists so the plugin page can remember you've already grabbed an installer. Clearing your browser data or switching to private/incognito mode removes everything. See the Cookie Policy for the full inventory.

How long we keep it

  • Account data: kept while your account is active. When you delete your account from settings, we remove your sessions and authentication record immediately and deactivate the account. To complete removal of the rest of the personal data we hold on you (profile, plugin pairings, signed-track manifests, settings, and any draft data), email [email protected]; we'll action it within 30 days of the request. This is subject to retention required by law, and to encrypted backups that overwrite on their normal rotation cycle (usually 60 days or less). Backed-up data is not used for any other purpose during that period.
  • Signed-track manifests: kept as part of the verifiability record while your account is active. To delete an individual manifest before closing your account, email [email protected]; we remove the database row within 30 days, subject to the same backup carve-out above. The Bitcoin anchor itself stays on the blockchain (see Bitcoin anchors and erasure).
  • Scan events: stored against the manifest they belong to. Delete the manifest, and the scan history goes with it.
  • Operational request logs: follow Cloudflare's standard retention for the products we use. We don't archive them ourselves.
  • Billing records: Stripe holds the transaction records (invoices, amounts, dates, billing country) for as long as US and EU tax and accounting law require, typically seven years. On our side we keep the Stripe customer and subscription identifiers tied to your account while the account is open, and remove them when you close it.

International transfers

Cloudflare, Stripe, and Resend process personal data in the United States and other jurisdictions. Cloudflare and Stripe participate in the EU-U.S. Data Privacy Framework, the UK Extension to the DPF, and the Swiss-U.S. DPF. Resend participates in the EU-U.S. DPF and the UK Extension. Where the DPF does not apply, transfers are covered by the European Commission's Standard Contractual Clauses (Decision 2021/914) and the UK International Data Transfer Addendum, incorporated through each sub-processor's data-processing agreement.

Your rights

If you're in the EEA, the UK, Switzerland, California, or another jurisdiction with comparable rules, you have the rights below. Email [email protected] and we'll respond within one month (45 days for California residents). Where a request is complex or we receive multiple requests from you, we may extend the deadline by up to two further months (a further 45 days for California), and we'll write to you within the initial period to explain why.

  • Access a copy of the personal data we hold about you.
  • Correct anything that's wrong.
  • Delete your account and the data we hold on you. The on-chain anchor is handled as described in Bitcoin anchors and erasure.
  • Restrict processing while a question or dispute is resolved.
  • Export your account data in a machine-readable file.
  • Object to processing we run on a legitimate-interests basis. Tell us why, and we'll reconsider.
  • Withdraw consent where we rely on it. Withdrawal doesn't affect the lawfulness of anything we did before.
  • Complain to your local data-protection authority. In the EU and UK that's the national DPA. We'd rather you came to us first, but we won't get in the way.

Before we act on a request, we take reasonable steps to verify your identity. For account holders that normally means responding from the email on your account. In cases of genuine doubt we may ask for additional information proportionate to the sensitivity of what's being requested. We won't disclose personal data to anyone we can't verify. You can also use an authorised agent, but you don't have to.

Where a request is manifestly unfounded or excessive, in particular because it is repetitive, we may charge a reasonable administrative fee or decline to act. We'll explain our reasoning, and you can complain to your data-protection authority.

Recipient labels and third parties

Mivia Sign lets you attach a recipient label to a signed track (for example, the name of an A&R contact you've sent a copy to). When you do this:

  • You, not Venezia LLC, are the data controller of the recipient's personal data.
  • We act as a processor on your documented instructions: we store the label, show it back to you, and surface it in scan results so you can see where your watermarked copy turned up.
  • You are responsible for having a lawful basis under applicable data-protection law for naming someone in this way. In most cases that will be your legitimate interest in protecting unreleased work, but you should weigh it against the recipient's reasonable expectations and, where appropriate, tell them that the track they've received is watermarked.
  • Our Terms of Service set this allocation out in more detail and form a data-processing agreement between you and us for that data.

If you are a named recipient on someone else's signed track and you want to exercise rights over the label (for example, to have your name removed), write to [email protected] and we will forward your request to the producer who attached the label, because they are the controller of that data. We can act on their instructions, but not on yours alone.

Bitcoin anchors and erasure

Every signed manifest is anchored to the Bitcoin blockchain through OpenTimestamps. The anchor itself is a cryptographic hash. It does not contain your name, your email, or the audio. Nobody can change or remove it. That is the point: a permanent, public proof that a file existed at a specific time.

When you ask us to delete a manifest or close your account, we remove the records that link the anchor back to you: the database row, your public signing key, your account details. Once the links are gone, the anchor on Bitcoin is no longer linkable to you. We don't unlink it; we delete the link. This approach aligns with the position the European Data Protection Board takes on blockchain processing, set out in its Guidelines 02/2025 on processing of personal data through blockchain technologies.

California, Nevada and other US states

We are a small US company and don't currently meet the scope thresholds in California (CCPA/CPRA), Virginia, Colorado, Connecticut, Texas, or other comprehensive US state privacy laws. The rules of the road are the same for everyone, so:

  • The categories of personal information we collect are listed under Data we collect: identifiers, internet and network activity, commercial information related to your subscription, approximate (not precise) geolocation tied to scan events and security-event notification emails, and audio-related metadata.
  • We don't sell personal information, as that term is defined under California or Nevada law. We don't share it for cross-context behavioural advertising. We have no financial incentives tied to data.
  • Geolocation is approximate (country, city, region). It is not "precise" as the CCPA defines that term, which requires roughly 1,850-foot accuracy.
  • You can exercise your rights to know, delete, correct, and limit use by emailing [email protected]. You can use an authorised agent, but you don't have to.
  • For Nevada residents specifically, you can email the same address to make a verified opt-out request under Nevada SB 220, and we will respond within 60 days. As above, we don't sell.
  • We don't currently respond to Global Privacy Control or Do Not Track signals because we don't run the tracking they're designed to block. If our practice changes, we'll support GPC.

If our business changes hands

We don't plan to be acquired, merged, or restructured, but if it happens we'll tell you well before any of your personal data is transferred or becomes subject to a different privacy policy. If a successor refuses to honour the commitments in this policy, you can close your account and your data goes with you in the export and deletion routes described under Your rights.

Lawful disclosure

If US law enforcement authorities present us with the necessary warrant, criminal subpoena, or court order, we have to comply. We will only respond to requests from government authorities outside the United States if the request is routed through US legal process, usually a mutual-legal-assistance treaty. Where the law allows, we will notify the affected user before we disclose anything, so they can challenge the request.

We may also disclose data without notice where we believe in good faith that doing so is necessary to prevent imminent harm to a person, to protect the rights or property of Mivia, or to respond to an urgent security threat.

Security

Everything goes over TLS. Passwords are hashed and salted by a modern memory-hard key-derivation function via Better Auth. Passkey credentials are stored as a public key only: the matching private key never reaches our servers, so a database compromise on our end would not let an attacker sign in as you. The shared secret and backup codes we keep for two-factor authentication are stored server-side and used only to check a code you submit at sign-in. Sessions are HttpOnly cookies with Secure and SameSite=Lax attributes set. We follow principle-of-least-privilege for our own access. We don't keep audio files beyond what is needed to produce the signed output. No system is perfectly secure; if you suspect a vulnerability, please write to [email protected]. We'd rather hear from you than read about it.

Children

Mivia Sign requires you to be at least 16 to create an account, and at least 18 to subscribe to a Pro plan. We don't direct the service to anyone under 16 and we don't knowingly collect data from under-16s. If you believe a child has an account, write to [email protected] and we'll close it.

Changes

We'll update this page when our practice changes. Material changes are announced by email and an in-app notice before they take effect. The current version date is at the bottom of this page.

Contact

Privacy enquiries and security reports: [email protected]. Anything else, see our Contact page.

Last updated: 28 May 2026