Security Policy

Your account holds your identity, the keys that prove it, and everything you’ve posted. This policy explains how to tell us about a security problem, what we do to protect your account, and what you can do to protect it yourself.

1. Reporting a vulnerability

If you think you’ve found a security problem in pyroclastic.cloud, email security@pyroclastic.cloud. Please include:

• what you found, and where (the address, endpoint, or feature);
• the steps to reproduce it;
• what you think an attacker could do with it; and
• how you’d like to be credited, if at all.

If you need an encrypted way to send details, say so in your first message and we’ll arrange one. Please don’t report vulnerabilities in public issues, posts, or other public places before they’re fixed.

What happens next:

• We acknowledge your report within 3 business days.
• We send you our initial assessment within 10 business days.
• We keep you updated while we work on a fix, and tell you when it’s done.
• We aim to fix critical issues as quickly as possible, high-severity issues within 30 days, and everything else within 90 days.
• If the problem affected anyone’s account or data, we tell them directly (see section 5).
• With your permission, we thank you by name once the fix is out.

pyroclastic.cloud is a small, independent service, and we don’t pay bug bounties. We’re grateful for every report all the same.

2. What’s in scope

Please report problems with:

• pyroclastic.cloud and all of its subdomains, including our entryway, mayon.pyroclastic.cloud, and account servers such as vesuvius.pyroclastic.cloud;
• the account portal, sign-in, and the screens where you connect apps to your account;
• handle resolution for accounts under dids.lol, dads.lol, thegem.city, and atproto.camp;
• how we handle the identities and keys we hold for accounts; and
• the open-source atproto-pds software our servers run, part of atproto-crates. Please report these privately here rather than in a public issue.

Please report these elsewhere:

• problems with Highport to Highport, as described in its policies;
• problems with Bluesky’s apps and services to Bluesky;
• problems in the AT Protocol specification itself to the protocol’s maintainers;
• problems with our infrastructure and email providers (Railway and Mailgun) to those providers; and
• problems with third-party apps to the people who run them.

If you’re not sure where something belongs, send it to us and we’ll help route it.

Not vulnerabilities on their own:

• Reading public data. Repositories, handles, DID documents, and account status are public by design. Being able to list, download, or follow them is how the network works.
• Missing security headers, version numbers in responses, or email configuration findings, without a demonstrated way to cause harm.
• Self-XSS, or clickjacking on pages with no sensitive actions.
• Rate limits on public, read-only endpoints.
• Unconfirmed results from automated scanners.

3. Rules for good-faith research

We welcome security research done in good faith. Accounts here are invite-only, so if you need test accounts, ask at security@pyroclastic.cloud and we’ll set you up.

Please do:

• test only against accounts you own, or accounts we’ve given you for testing;
• stop as soon as you’ve confirmed a problem, and report it to us;
• access only the minimum data you need to show the problem; and
• keep the details confidential until we’ve fixed it, or until 90 days after your report, whichever comes first, unless we agree on something else together.

Please don’t:

• access, change, or delete anyone else’s data or account;
• degrade the service, including with denial-of-service or load testing;
• use social engineering, phishing, or physical attacks against anyone;
• send spam or post unwanted content to the network; or
• attack our service providers’ systems.

If you follow these rules, we consider your research authorized. We won’t take or support legal action against you for it, and if someone else takes legal action against you over research that followed these rules, we’ll make clear that we authorized it.

4. How we protect accounts

Encrypted connections. Every connection to our websites and servers uses HTTPS.

Passwords. We store passwords and app passwords only as salted, one-way hashes made with an algorithm designed for passwords. We never see or store your password in readable form.

Sign-in protection. You can turn on email sign-in codes, so that a password alone isn’t enough to sign in. Apps can connect through scoped authorization, so they never see your password and get only the permissions you approve, and you can revoke them at any time. We rate-limit sign-in attempts.

Identity keys. For each account, we hold a signing key that signs your repository, and a recovery key that can update your identity. We store these keys encrypted and use them only for the actions you ask for, like publishing a post, changing your handle, or moving to another provider.

Administrative access. Only the operator has administrative access to our servers. That access is protected by multi-factor authentication and used only to run the service, respond to your requests, or investigate abuse and security problems.

Backups and recovery. We take an encrypted backup of all account, identity, and cryptographic data every day, and we periodically download an encrypted copy of identity, key, and repository data and keep it offline, in a safe, for up to 30 days, so a copy survives even if our servers and hosting accounts are lost. We keep a written disaster recovery plan and a runbook for carrying it out, and we practice restoring from backups so recovery doesn’t depend on improvising.

Updates. We keep our servers and software up to date, and we apply security fixes promptly.

Logs. We keep server logs for up to 30 days, to spot and investigate abuse and attacks, and then delete them automatically.

5. If something goes wrong

When we learn of a security incident, we:

• investigate it and contain it as quickly as we can;
• post what’s happening on the status page;
• email anyone whose account or data was affected, with what happened and what they should do;
• notify the relevant authority within 72 hours when a breach of personal data is likely to create a risk to people, as described in the Privacy Policy; and
• once it’s resolved, publish a summary of what happened and what we changed.

6. What you can do

Use a strong, unique password, and turn on email sign-in codes. These two steps stop most account takeovers.

Connect apps the safe way. Sign in to apps through the authorization screen, or with an app password, never with your main password. Review the apps you’ve connected from time to time and revoke the ones you no longer use.

Add a recovery key of your own. Your identity can list more than one recovery key, in order of priority. A key you hold, listed ahead of ours, can undo changes made with our key within 72 hours of them happening, and lets you move your identity to another provider even if pyroclastic.cloud is unreachable. Keep it somewhere safe and offline. If you’d like help setting one up, ask us.

Keep your own copy. Download your repository from time to time with your app’s data export option.

Be careful with shared access. Give it only to people you trust, give them only what they need, and remove it when they no longer need it.

Watch out for phishing. We will never ask for your password or sign-in codes by email or direct message. Only enter your password on our sign-in server, mayon.pyroclastic.cloud, or in an app you trust.

7. Machine-readable contact

Our security contact is also published at /.well-known/security.txt, following RFC 9116, so tools and researchers can find it automatically.