Reporting a security problem

Email security@jellysuite.com. Please don't report a security problem in public first. Tell us:

• what you found and where (a page, an endpoint, a screen),
• how to reproduce it, with a proof of concept if you have one,
• what an attacker gains, and what they need to have first (an account, a share, control of the server).

We'll confirm we received your report within three working days, and tell you what we think of it and what happens next within ten. We'll keep you posted until it's fixed, and credit you in the release notes if you want that. There's no paid bounty yet.

The design promise is that our servers never see plaintext content, titles, passwords or keys. The most valuable reports break that promise or the sharing rules around it:

• anything that lets the server, or someone on the network, read or change content without being detected,
• a key accepted, sealed to or trusted for someone it shouldn't be,
• access that survives being revoked,
• account takeover, or getting past sign-in, recovery or a link password,
• script injection in the web or desktop apps, or a way round the content security policy,
• mail that poses as someone else, or leaks what should have stayed encrypted.

Lower priority, but still welcome: denial of service, missing rate limits, and problems that need a device that is already compromised.

We write down the limits we know about instead of hiding them. Before you report, read the transparency page for what our servers can see, and how the encryption is built. A new way to reach a known limit is still worth telling us.

• Test against your own accounts, or your own copy of jellysuite.
• Don't read, change or delete other people's data, and don't degrade the hosted service.
• Give us a reasonable time to fix a problem before you publish it. We'll agree a date with you.

If you follow these rules in good faith, we won't take legal action against you for your research.