Privacy Policy

Your email address, when you registered, and whether the address is verified. The address is held in our database and protected by encryption in transit, access control on the database itself, and encryption of the backups it appears in. We have built envelope encryption for this field — AES-256-GCM under a per-row key wrapped by a master key held only in the server's environment — but it is not yet switched on for existing accounts. We will update this page when it is.

If you set a password we store a bcrypt hash of it, never the password, plus hashes of your previous passwords so a reset cannot reuse one. If you switch on two-factor authentication we store your TOTP secret in encrypted form and hashes of your recovery codes. We also hold your notification preferences, your plan tier, and short-lived hashed tokens for email verification, password resets, magic-link sign-in and email-change confirmations.

If you sign in with Google or Apple we store which provider you used, the account identifier that provider gives us, and the email address it returns. We never receive your password for those accounts.

When you activate CueSyncon a machine we store a SHA-256 hash of the device identifier (never the raw identifier), the device name you or your operating system supplies, the platform, when it was activated and when it was last seen. We also store the desktop client's own assessment of how strongly that identifier is bound to the hardware, and the furthest-forward clock reading the device has reported, which is how we detect a clock being wound back to extend an offline grace period.

Your licence key is stored in two forms: a keyed hash used for lookup and verification, and an encrypted copy (same envelope scheme as your email address) that exists so support can re-send you your own key. We also store the key prefix, the edition and billing cycle, the key type, activation counts, and whether and why a key was revoked.

Web sessions use an httpOnly cookie; the session record holds the identifiers needed to validate and revoke it. Desktop sessions additionally record the app version, operating system, edition, a hashed IP address, the country that IP resolves to, heartbeat counts and total active seconds — this is what powers the "active sessions" list and the "sign out everywhere" button. Revoked sessions and revoked tokens are kept on a blocklist until they could no longer be presented.

Your Paddle customer and subscription identifiers, the edition, billing cycle, status, period dates, any scheduled change or cancellation, and dunning state if a payment fails. We keep an append-only ledger of completed transactions: amount, tax component, currency, status, the date, and the Paddle transaction reference printed on your receipt. We never receive or store card details.

Your name, email address, the content of your message, your IP address, and Cloudflare Turnstile verification tokens for bot protection. Alongside a contact-form message we send the campaign details of your visit — any UTM tags or Google click ID in the link you followed, the page you first landed on, and the site that referred you. That tells us which channels bring people who get in touch. It is never used to build a profile of you or shared with advertisers, and it is deleted with the rest of your record on request.

Your email address, when you subscribed and confirmed, whether you have unsubscribed, and the attribution of the signup: UTM source, medium, campaign, content and term, plus which placement on the site you signed up from.

If you use CueSync Studio, we store the show projects you create and everything in them: project name, venue, author and schedule, cues (numbers, names, notes, intent and the actions they fire), sections and acts, snapshots, comments, audio track configuration, and per-project activity. Uploaded audio, waveform data, spec documents, images and cover art are stored as objects in Cloudflare R2 with their filename, size, content type and checksum recorded in our database. We also store project membership and pending invitations, which include the email address of the person invited, and a short-lived presence record showing who currently has a project open.

An audit log of security-relevant events — activations, sign-ins, subscription changes, admin actions — each with the action, your user ID, a hashed device identifier, the IP address, and event details. Hashed IP addresses you have signed in from before, which is how we can tell a new-device sign-in from a routine one. Anomaly signals scored by our sharing detector, tamper signals reported by the desktop app, and the per-install watermark identifier described in Section 08.

Subject to your cookie choices: pages viewed, interactions, web-vitals measurements, session recordings, advertising click identifiers (gclid, gbraid, wbraid, fbclid and their equivalents), and — on purchase — a hashed copy of your email address sent to ad platforms so they can match the sale to a click.

Not subject to your cookie choices: errors thrown by the website, with the IP address they came from, the browser context, and a masked replay of the session the error happened in. Section 07 sets both out in full and explains the difference.

Our servers log IP addresses, browser user-agent strings and request timestamps for security monitoring, rate limiting and abuse prevention. Our hosting providers keep their own request logs.

Submissions are forwarded to ClientFlow, the customer-relationship platform we use to track and answer support requests, so that your message reaches a person and does not depend on a single email delivery. Campaign details of your visit travel with it, as described in Section 03; they are stored in your browser for the session (30 days for the campaign tag).

The support chat in the corner of this site is operated for us by ClientFlow. Messages you type are sent from your browser directly to ClientFlow's servers, along with your IP address, and are stored there as a conversation record. If you choose to leave an email address for a follow-up, that address is stored with the conversation.

Replies are generated by an automated assistant, not a person — the chat window says so before you type. To produce a reply, ClientFlow sends your message to a third-party large-language-model provider. ClientFlow removes recognisable personal details (such as phone numbers, email addresses, and card-like number sequences) from the message before it leaves their servers, but you should still avoid putting sensitive information into the chat. You can ask to speak to a human at any time.

Your conversation is also stored in your own browser for 24 hours so it survives a page reload. You can erase it at any time with the “Clear conversation” button in the chat header, which deletes both the local copy and the session it belongs to. See our Cookie Policy for the exact storage entries, and our AI Use Statement for where else automated systems are involved.

If you accept analytics cookies we load PostHog, which records the pages you visit, what you click, and web-vitals performance measurements. PostHog is served through our own domain, so an ad blocker will usually not stop it; declining in the cookie banner will, because nothing is loaded at all until you accept.

PostHog does not build a stored person profile for anonymous visitors. It does build one once you are signed in: on account pages we identify you to PostHog using your email address as your identifier, together with your edition, tier, billing cycle, subscription status and whether your email is verified. Signing out clears that identification.

Some analytics events are sent by our server rather than by your browser — that a registration completed, an email was verified, a download started. Those are gated on the same analytics choice: the server reads the consent record your browser stores alongside its own, and sends nothing when the answer is no, missing or unreadable. It reads your Sec-GPC and DNT headers first, and an asserted signal denies whatever that record says — see Section 17.

PostHog session recording is switched on for visitors who accept analytics cookies. It captures a reconstruction of your visit — mouse movement, clicks, scrolling and page changes — so we can see where the interface confuses people. It is a real recording of your session, and we would rather say so plainly than bury it in a cookie table.

Three masking rules apply to every recording. All form inputs are masked, so anything you type into a field is replaced before it leaves your browser. Any element marked [data-sensitive] has its text masked. Any element marked [data-block-recording]is blocked from the recording entirely. Payment entry never appears at all, because it happens inside Paddle's own checkout rather than on our page.

To refuse this recording: decline analytics cookies in the banner, or withdraw analytics consent later in cookie preferences. Browsers sending a Do Not Track signal are never recorded — see Section 17.

There is a second, narrower recorder, and it is not part of the analytics consent. Our error-monitoring tool, Sentry, records a replay of a session when something goes wrong in it: every session in which an error is thrown, a small sample of ordinary sessions (about one in a thousand), and sessions where a page performs badly enough to breach a Core Web Vitals threshold. Form inputs are masked there too, and Sentry receives your IP address with the error. We rely on legitimate interests for this — diagnosing faults in a product people run live shows on — rather than on consent, because a crash we cannot see is one we cannot fix. If you would rather we did not, tell us under Section 15 and we will exclude you.

If you accept advertising cookies we load tags from Google Ads, Meta, LinkedIn, Microsoft (Bing UET) and X. They let us measure which ads led to a purchase and show CueSync ads to people who have visited the site before.

When a purchase completes, our server also sends the sale to Google, Meta, LinkedIn and X through their conversion APIs. Those messages contain a SHA-256 hash of your email address, the amount and currency, the edition and billing cycle, the transaction reference and your country. The hash is what lets a platform match the sale to a click without us handing over your address in the clear; it is still personal data, and it is still a disclosure to those platforms. Section 16 explains what that means if you are in California.

That server-side fire is gated on the same choice you made in the banner. Your advertising decision is captured when the checkout opens and travels with the purchase, because the webhook that triggers the fire arrives server-to-server, potentially days later, with no browser to ask. If no decision was recorded, or the record cannot be read, nothing is sent — the gate treats anything it cannot positively confirm as a refusal.

You can opt out of advertising cookies at any time via our cookie preferences, Google's Ads Settings, Meta's Ad Preferences, or LinkedIn's retargeting opt-out.

The desktop app contacts our servers to validate your licence (roughly every 30 days for token renewal, and when you activate or deactivate a device) and to check for updates. It also reports anti-piracy tamper signals — see Section 09, which explains what those are and why they are not covered by the switches below.

Audio analysis is local. Beat and tempo detection runs on your machine and the audio itself is never uploaded. Unless you use Studio, your show files stay on your disk.

Crash reporting and product analytics are two independent choices. Both are off until you make them. CueSync asks once, when you first run the app, and you can change either at any time in Settings > Advanced. Turning one on does not turn the other on.

If you switch crash reporting on, CueSync sends errors and crashes to Sentry, together with the trail of events leading up to them. That trail is more detailed than "a crash report" suggests, so here is what is in it:

• Fired cues, including the cue number, the cue name and how it was triggered
• Device connect and disconnect events, and MIDI, OSC and other protocol traffic events
• Settings changes, project open and save events, timeline and venue-profile actions
• Tempo changes, and — unless you turn off "include track metadata in crash reports" — the title and artist of loaded tracks
• Licence activation, validation and revocation events, and detected clock rollbacks
• Your operating system, Java version, app version, connected protocol count and whether the licence is a paid one

Your account email is not sent in the clear from the desktop app: the user attached to a desktop crash report is identified by your device identifier and by a salted SHA-256 hash of your email address. The website is different — if you are signed in on this site, our web-side error reporting is given your email address itself. Both are described in the processor table in Section 12.

Crash reports also carry the per-install watermark described in Section 09, as a tag. File paths, exception messages and stack frames are scrubbed of your home directory before anything is sent. When you are offline — which, in a venue, is often — pending reports are cached in a folder under your home directory until the app can send them.

If you switch product analytics on, the app reports two funnel milestones: that an update finished installing (with the version it came from, the version it went to, whether it succeeded, any error code and how long it took), and that you fired your first cue. Both carry a hashed device identifier, your subscription reference and the watermark prefix. Neither carries cue names, show content or audio.

Switching either of them off stops the sending immediately. Product analytics is read from your settings at the moment an event would be sent, so there is nothing left in flight; crash reporting no longer waits for a restart either — withdrawing it drops the user context, discards the trail collected so far, and closes every path that would send, including the one that forwards logged errors on their own. The asymmetry runs the other way. Switching crash reporting back on may not take effect until the next launch, because the reporter is built once at startup and a session that began without your consent has nothing to re-arm. Neither switch retroactively deletes what was already sent — for that, ask us under Section 15 and we will delete it.

Each installation of the desktop app mints a persistent identifier — a watermark — that stays with that install. A short prefix of it is attached to crash reports as a tag, to update and tamper telemetry as a field, and it names the app's local log and crash-cache folders. Its purpose is to tie a leaked or tampered build back to the install it came from. It is not a hardware identifier and it does not survive a clean removal of the app's data directory. Every place it is stored is enumerated in code specifically so that it can be included in a data request and deleted on request.

If the app detects that its own binary, its integrity baseline or its licence storage has been modified, it reports a tamper signal: the signal type, when it was first and last seen, a hashed device identifier, your subscription reference and the watermark prefix. It does not report file contents, show data or anything about your machine beyond that.

This path is deliberately not gated by the crash-reporting or analytics switches, because a copy-protection signal that a tamperer can switch off is not a copy-protection signal. It is processed on legitimate interests, it is stored separately from analytics, and you can object to it under Section 15.

On activation and validation we score a small set of sharing signals: repeated device takeovers, activation churn beyond the 2 registrations a solo plan allows, widely dispersed IP addresses, live output claimed from two machines at once from distant locations, and clocks wound backwards. Each signal is stored with a score and the evidence behind it.

These signals are observed, not acted on automatically. They never block an activation. They are surfaced in an internal review queue and nothing in production converts a score into a suspension or a revocation on its own — a person reviews any enforcement decision before it takes effect. Where a signal is strong enough to be worth asking about, the most that happens automatically is a single "was this you?" email with a link you can use to confirm it was.

Some protections are ordinary rules and do apply immediately and automatically: a limit of 5 activation attempts per hour per IP address, a lockout after 20 failed attempts against the same key prefix within 24 hours, per-endpoint rate limits, and the device-registration cap and live-output lease themselves. These are mechanical, they apply the same way to everyone, and if one has caught you unfairly, write to us and we will lift it.

Every security-relevant event is written to an audit log that records the action, your user ID, a hashed device identifier, the IP address and the event details. The log is append-only and chained so that a modified or deleted entry is detectable.

In order of severity: a confirmation email; a licence key re-issued so the old one stops working; deactivation of a device; suspension or revocation of a licence for sustained, corroborated sharing. You can contest any of these by writing to privacy@cuesync.live or contact@cuesync.live, and we will explain what we saw and review it.

Several of these do not need a request at all:

• Devices: see every activated device and deactivate any of them, from the Devices section of your account dashboard.
• Sessions: see every active session and sign out everywhere else, under Security in the same dashboard. Changing your password revokes them too.
• Password and two-factor authentication: set, change or enrol under Security.
• Cookies, analytics and advertising: change or withdraw consent at any time in cookie preferences.
• Marketing email: every message carries a one-click unsubscribe link, which needs no sign-in. If you no longer have one to hand, email us and we will remove you. Transactional email about your licence and your account is not affected by unsubscribing.
• Desktop crash reporting and product analytics: two independent switches in Settings > Advanced, as described in Section 08.

Ask at privacy@cuesync.live from the address on your account. For access and portability we produce a single machine-readable file containing your account record, linked sign-in providers, subscriptions, payment history, Studio and add-on entitlements, licence keys (prefix and state — we do not put a working key in an export), devices, the last 90 days of your audit log, your desktop sessions, update-install and first-cue events, and any tamper signals recorded against your installs. For erasure we run the account deletion described in Section 14.

An erasure does not stop at our own database. Four processors hold something keyed to your email address, and they are not all reachable the same way, so here is which is which. Resend, which sends our email, is automatic: your contact is removed from the sending list as part of the deletion. PostHog publishes a person-deletion API that also removes the events attached to that person, and our code calls it wherever the credentials for it are configured; where they are not, the erasure is recorded as outstanding rather than assumed done, and it is made by hand. Sentry and ClientFlow publish no per-person deletion endpoint at all, so for those two it is a request a person files with the provider. We would rather tell you that than describe a call that is not being made.

Whichever route applies, the outcome for each processor is written to the audit log — deleted, nothing to delete, no automated route, or failed — so if you ask us to prove the deletion happened we can show you processor by processor rather than assert it. A processor that is unreachable at that moment does not block your deletion — a vendor outage must not leave you with an account you believe is gone — but the failure is recorded rather than swallowed, so it can be chased. If you want the manual steps confirmed in writing once they are done, say so in your request and we will come back to you.

We will ask you to confirm the request from the account address, and may ask for more if we have real doubt about who is asking. That check exists to stop someone else obtaining your data, and it is not a delaying tactic.

Account deletion requires a second factor when two-factor authentication is enforced on your account. If you have lost your authenticator and your recovery codes, that gate will refuse — by design, because it is the same gate that stops someone else deleting your account. In that case email privacy@cuesync.live from the address on the account. We will verify you another way and complete the deletion manually, within the same one month.