Security

You may be putting unreleased music here. You deserve a straight account of how it is protected and where the gaps are, rather than a page of reassuring adjectives. This is that account, and we will keep it accurate as things change.

How your files are protected

• Access is enforced by the database, not the interface. Every table has row-level security, so permission is checked on the data itself. Hiding a button is not how access is controlled here — a request for a file you are not entitled to fails at the database, whatever the request looks like.
• Project files are private. The storage holding workspace files is not public. Files are reachable only through short-lived links issued to phase members, currently valid for fifteen minutes and re-issued while you have the workspace open.
• Only project owners can publish to the review pool. Sharing a file from a private workspace into the public review pool is the owner’s decision alone. A collaborator cannot put your unreleased work in front of other members.
• Access to private media is logged. Every link issued for a workspace file is recorded — who, which file, when. Project owners can see this for their own projects. If something appears where it should not, there is a record of who had it.
• Encrypted in transit and at rest, with a strict content-security policy, and rate limits on sensitive endpoints.
• Fingerprints are computed in your browser. Proof hashing happens on your device; the timestamping network receives only a hash, never your audio.
• Invite only. During the beta, every account traces back to an invite issued by an existing member.
• You can block anyone, and they are not told. A blocked person cannot answer your calls or review your work, and you stop appearing to each other on the board and in people. Blocking does not remove either of you from projects you already share — credits already earned stay intact, and leaving a project is a separate decision.
• Anything can be reported. Reports are private; the person reported is not told who flagged them.
• Two-factor authentication, enforced at the database. You can turn on a second factor in Account settings. Once you have, a session that has only supplied your password cannot read project files, file records or messages — not through the site, and not through the API either. A stolen password on its own stops being enough.

What we do not yet have

These are real gaps, not theoretical ones. We would rather you know them than discover them.

• Two-factor is optional, and off by default. It exists now, but an account without it is still protected by its password alone — if that password is stolen or reused from a site that has been breached, someone can sign in as you. We are not forcing it during the beta because there are no backup codes yet and losing your authenticator would mean losing your account. Turn it on if you keep anything unreleased here, and use a long password unique to Takeyard either way.
• No backup codes for two-factor. If you lose your authenticator, getting back in means emailing us from your account address and waiting for a manual check. Save the setup key when you enrol.
• No per-download watermarking. We can record who accessed a file, but a leaked file cannot be traced back to a specific person from the audio itself.
• Collaborators you approve can download what you share. That is the point of a shared workspace, but it means access control ends where trust begins. Anyone who can play a file can keep a copy. Approve people accordingly, and share only what a project genuinely needs.
• No independent security audit. Takeyard has not been penetration-tested by a third party.
• Moderation is one person, not a team or a queue. Reports are read and acted on by hand, usually within a day or two, but there is no 24-hour rota and no automated detection. If something is urgent, say so in the report and email as well.

What this means for genuinely sensitive material

If a leak would seriously damage you — an unreleased single, a track under label embargo — our honest advice during the beta is to be conservative. Share what collaboration actually requires, prefer reference bounces to full stems where that is enough, and remember that anyone you approve can keep a copy of anything they can play.

No online service can promise your files will never be exposed, and any service that does is not being straight with you. What we can promise is that access is enforced at the database, that private media access is logged, and that this page will say so plainly when something changes.

If something goes wrong

If you believe your account has been accessed, or you find a vulnerability, email bastianbjw@gmail.comwith “Security” in the subject. We will respond as quickly as we can, and we will not pursue anyone who reports a genuine issue in good faith and does not exploit it or share it before we can fix it.

Where a personal data breach occurs, we will notify the Danish Data Protection Agency (Datatilsynet) within 72 hours as required by GDPR Article 33, and will tell affected users directly where Article 34 requires it. See the Privacy Policy for how your data is handled, and the Terms for the limits of our liability — noting that nothing there excludes liability for gross negligence or wilful misconduct, which cannot be waived under Danish and EU law.