Security · Disclosure
Found something? Tell the operator.
Responsible disclosure makes the product better. If you've found a security issue in eri, this page is the contract between you and the operator: how to report, what's in scope, and the safe-harbour promise.
1. How to report
Email phlotu@gmail.com with a clear description, reproduction steps, and the impact you observed. If the issue is sensitive, you can ask for a PGP key — the operator will reply with one. Please don't use the bug to access more data than necessary to demonstrate it.
2. What you can expect
An acknowledgement within 3 business days. A triage assessment within 7 business days. A fix or a written explanation of why the report is not actionable. If your report results in a fix, the operator will credit you publicly (with your permission) once the patch is released. There is no bug bounty programme yet — that's honest, not a slight.
3. Safe harbour
If you act in good faith, follow this policy, and avoid privacy violations, destruction of data, and interruption of service, the operator will not pursue legal action against you for security research on eri's published surfaces. This safe harbour does not extend to third-party infrastructure (your hosting provider, your model provider, the OS) — those are outside the operator's authority.
4. In scope
The eri desktop application, the website at tryeri.ca, the dashboard at tryeri.ca/dashboard, and the public API endpoints documented at /docs. Vulnerabilities in third-party libraries are in scope only where the operator's specific use creates exploitability.
5. Out of scope
Denial-of-service attacks. Social engineering of the operator. Physical attacks. Vulnerabilities in third-party services (Stripe, Supabase, Vercel, model providers) — report those upstream. Issues that require a compromised device, a malicious extension, or root access on the user's machine. Theoretical issues without a demonstrated impact path.
6. What not to do
Don't exfiltrate other users' data. Don't pivot deeper than the bug requires. Don't publish the issue before a fix is shipped. Don't extort. Don't run automated scanners against production without coordinating first — the operator will share a test endpoint where useful.
7. After the fix
Once a fix is shipped, the operator will publish a short security advisory (CVE if applicable) and credit you in it if you'd like to be named. If your finding affects user data, the operator will follow PIPEDA and applicable breach-notification laws to inform affected users.