Security Policy
Rhize is built around strong privacy and encryption guarantees. We publish our encryption architecture in detail and welcome scrutiny from the security research community.
This page describes how to report a security issue and what you can expect from us in return.
Reporting a vulnerability
If you believe you have found a security vulnerability in Rhize, please report it privately by emailing TBD@comingsoon.com.
Please do not disclose the issue publicly before giving us a reasonable chance to respond. We will acknowledge your report within 72 hours and will coordinate with you on a disclosure timeline.
For machine-readable contact and policy information, see security.txt, published per RFC 9116.
What to include in your report
- A description of the issue and its potential impact
- Steps to reproduce, or a proof-of-concept
- The version of the app or the date you tested
- Any relevant environment details (platform, device)
- Your preferred contact address and whether you want public credit
The more detail you provide, the faster we can triage.
What we'll do
- Acknowledge receipt within 72 hours.
- Triage the report and confirm whether we consider it a vulnerability.
- Keep you updated on progress at reasonable intervals, typically every 7–14 days.
- Coordinate a disclosure timeline with you. Our default is to ship a fix and then publicly disclose within 90 days of the initial report. We are flexible on complex issues.
- Credit you publicly on our acknowledgments page if you want to be named, or keep your report anonymous if you prefer.
Scope
In scope
- The published encryption architecture whitepaper — design-level flaws in the protocol, key hierarchy, inbox envelope, key exchange pattern, or privacy invariant.
- The Rhize mobile app published to the App Store and Google Play — cryptographic, authentication, authorization, or data-handling bugs in the shipping build.
- Rhize server endpoints — the API gateway, the inbox, the post index, friend request handling. Includes authentication bypass, authorization flaws, injection, and data-leak issues.
- Data stored in user-accessible AT Protocol records (
com.denazen.*collections).
Out of scope
- Physical attacks on devices under the user's control (an unlocked stolen device is outside our threat model).
- Social engineering of Rhize staff or users.
- Denial-of-service testing against production infrastructure. Report DoS concerns analytically, not via actual load attacks.
- Vulnerabilities in third-party services we integrate with (Bluesky PDS, AT Protocol relays, app store infrastructure). Report those to the respective vendor.
- Vulnerabilities that require an attacker to already possess your encryption password or vault key.
- Reports generated purely by automated scanners with no demonstrated impact.
- Missing security headers or cookie flags on non-sensitive marketing pages.
If you are uncertain whether a specific test is within scope, please ask first by emailing TBD@comingsoon.com before testing.
Safe harbor
We consider security research conducted in good faith under this policy to be:
- Authorized under our Terms of Service
- Exempt from any claim we might otherwise pursue under the Computer Fraud and Abuse Act or equivalent laws
- Exempt from any claim under relevant anti-circumvention laws
We will not pursue legal action against researchers who:
- Make a good-faith effort to comply with this policy
- Avoid privacy violations, data destruction, and service disruption
- Use only accounts they own or have explicit permission to access
- Give us a reasonable time to address the issue before public disclosure
- Do not exploit the issue beyond what is necessary to demonstrate it
Bug bounty
Rhize does not currently offer paid bug bounties. We provide public acknowledgment for valid reports and may offer other forms of recognition as the product matures.
Acknowledgments
Researchers who have responsibly reported issues to Rhize are listed on our acknowledgments page.
Changelog
Material changes to Rhize's public security documents — including the encryption architecture whitepaper — are logged on the security changelog. If you've reviewed Rhize's security posture before, that's the quickest way to see what's changed.