Reporting a security problem

Where to send it

security@folkroom.org. Tell us what you found and how to reproduce it. You do not need a proof-of-concept exploit and you should not build one against live data.

This page is also published at /.well-known/security.txt so an automated scanner finds it.

What we promise

• We acknowledge within 2 working days.
• We tell you what we found and when we expect to fix it, rather than going quiet.
• We will not pursue you legally for a report made in good faith under the rules below.
• We credit you when it is fixed, if you would like to be credited.

There is no bug bounty. folkroom is funded out of pocket and cannot pay, and we would rather say so than let you find out after the work.

Please do

• Test against your own account and your own data.
• Stop as soon as you have confirmed a problem exists.
• Give us a reasonable window to fix it before publishing.

Please do not

• Access, alter or delete another person’s data.
• Run denial-of-service tests, or automated scans heavy enough to be one.
• Social-engineer anyone, including us.
• Publish anything you obtained from another account.

Worth knowing before you start

Two things about folkroom’s design change what is and is not interesting here. Reading requires no account, sets no cookie and runs no analytics, so there is no reader session to steal. And every content change is append-only and attributed, so an unauthorised edit is recoverable and traceable rather than silent — which makes escalation to a higher tier far more interesting than the edit itself.

Accounts, moderation actions and the admin console are in scope. Third-party services we depend on are not ours to authorise testing against — report those to them, and tell us too.

If you have found exposed personal data

Say so in the first line and we will treat it as urgent. Do not download more than the minimum needed to demonstrate it, and delete what you took once we confirm. The privacy notice lists what folkroom holds, which is less than most sites.