Will you sue researchers who report vulnerabilities?

No. We commit not to sue security researchers who act in good faith, follow the rules in this policy, stop at proof of vulnerability, and do not exfiltrate or retain other users' data.

What is in scope for the Journal Genie bug bounty?

journal-genie.com and all subdomains operated by Yotta-Byte Labs, the Journal Genie web app served from journal-genie.com, and the GENIE smart contract once deployed.

Is Journal Genie SOC 2 certified?

No — and we won't pretend otherwise. Our security is verifiable in the open code today: row-level security, encrypted storage, a hash-chained audit log, and continuous dependency updates. We'd rather show you the architecture than sell you a badge.

Bug bounty is alive

Find a hole. Tell us, not Twitter.

Q: How do I report a security vulnerability in Journal Genie?

Email security@journal-genie.com with reproduction steps, the affected URL or component, and any proof-of-concept payload. We acknowledge every report within five business days.

Q: How does Journal Genie protect my data?

Row-level security on managed Postgres (the database physically cannot return another user's data via the user-facing query path), encrypted at rest and in transit, a hash-chained audit log for sensitive event streams, daily backups, and cross-account isolation enforced and continuously verified at the database layer.

Yotta-Byte Labs operates Journal Genie. This page tells researchers what's in scope, how to report, how fast we respond, and the safe-harbor terms under which good-faith research is welcome. Three plain-language bullets first; the full disclosure policy follows.

Plain-language stance

What you can hold us to, in three sentences.

Find a hole? Email security@journal-genie.com. We acknowledge within five business days. We don't sue researchers acting in good faith.
Our hardening is real and verifiable: row-level security policies, encrypted at rest and in transit, a hash-chained audit log for sensitive event streams, daily backups, cross-account isolation enforced at the database layer, continuous dependency updates, and signed CI artifacts.
Our security is verifiable in the open code, not a purchased badge. We don't claim certifications we haven't earned — we show you the architecture instead.

Our security posture

What we have shipped today

Account data — row-level security on managed Postgres. The database physically cannot return another user's data via the user-facing query path. Service-role credentials are isolated to a small, audited set of server routes.
Payment processing — Stripe end-to-end. We never store card detail. PCI scope sits entirely with Stripe.
AI inference — OpenAI API (default) and the paid Google Gemini API when you select a Gemini model, both on no-training provider tiers with explicit spend caps. Per-request data minimization (only the prompt + retrieved context is sent; account identifier is hashed for logging).
Deployment hardening — OWASP Top 10 defaults: input validation at API boundaries, Secure + HttpOnly + SameSite session cookies, Content-Security-Policy with strict source allowlist, signed-artifact CI, Dependabot continuous dependency updates.

In scope

Targets covered by this policy

journal-genie.com and all subdomains operated by Yotta-Byte Labs (the "*.journal-genie.com" zone).
The Journal Genie web app served from journal-genie.com.
The GENIE smart contract once deployed and announced via an on-chain manifest (Base Sepolia testnet).

Out of scope

What does not belong here

Third-party services we depend on (Vercel, Supabase, Stripe, OpenAI, Resend, Cloudflare) — please report directly to those vendors.
Findings that require physical access to a Yotta-Byte Labs device, social-engineering of personnel, or coercion.
Denial-of-service, brute-force, or automated scanning of the live site at volume.
Self-XSS, missing security headers without a demonstrated impact, and reports that boil down to "user installs malware on their own machine".

How to report

Send your finding to the security inbox

Email security@journal-genie.com. The inbox is operationally verified and routes directly to the founder. PGP-encrypted email is available on request.

Use the canonical address: security@journal-genie.com. We acknowledge within five business days.
Include a clear reproduction, the affected URL or component, and any proof-of-concept payload — keep payloads minimal.
Stop at proof of vulnerability. Do not exfiltrate user data, modify accounts you do not own, or pivot deeper than necessary to demonstrate impact.
If you discover personal data of another user, stop, do not retain it, and tell us immediately.

Email security View security.txt Open GitHub Issues (non-sensitive bugs)Read Privacy

Response SLA

Severity targets

Severity is classified using a CVSS-style impact-times-likelihood frame. The targets below are engineering aims, not contractual guarantees; we communicate openly when a fix needs more time.

Severity	Target	Examples
Critical	Triage within 24 hours, mitigation in flight within 72 hours	Remote code execution, authentication bypass, full account takeover, data exfiltration affecting more than one user
High	Triage within 3 business days, mitigation in flight within 14 days	Stored XSS in an authenticated surface, IDOR exposing another user's notebook or journal, privilege escalation
Medium	Triage within 7 business days, mitigation in flight within 30 days	Reflected XSS, missing authorization on a non-sensitive endpoint, CSRF on a non-state-changing surface
Low	Triage within 14 business days; fix scheduled with the next routine release	Information leakage with limited impact, rate-limit gaps that do not affect availability, configuration drift

Safe harbor

Good-faith research is welcome

Yotta-Byte Labs will not pursue legal action against researchers who engage in good-faith security testing within the scope of this policy, do not access or alter user data beyond what is necessary to demonstrate impact, and disclose privately to the security inbox before any public announcement. We commit to acknowledging your contribution if you would like to be credited.

Acknowledgments

Hall of fame

We credit researchers who responsibly disclose security issues — with their permission, named right here. Report a real finding in good faith, and your name belongs on this list.

Cross-references

Related policy surfaces

/.well-known/security.txt Privacy Terms Trust Contact

What you can hold us to, in three sentences.

Find a hole? Email security@journal-genie.com. We acknowledge within five business days. We don't sue researchers acting in good faith.

Our hardening is real and verifiable: row-level security policies, encrypted at rest and in transit, a hash-chained audit log for sensitive event streams, daily backups, cross-account isolation enforced at the database layer, continuous dependency updates, and signed CI artifacts.

Our security is verifiable in the open code, not a purchased badge. We don't claim certifications we haven't earned — we show you the architecture instead.

What we have shipped today

Account data — row-level security on managed Postgres. The database physically cannot return another user's data via the user-facing query path. Service-role credentials are isolated to a small, audited set of server routes.

Payment processing — Stripe end-to-end. We never store card detail. PCI scope sits entirely with Stripe.

AI inference — OpenAI API (default) and the paid Google Gemini API when you select a Gemini model, both on no-training provider tiers with explicit spend caps. Per-request data minimization (only the prompt + retrieved context is sent; account identifier is hashed for logging).

Deployment hardening — OWASP Top 10 defaults: input validation at API boundaries, Secure + HttpOnly + SameSite session cookies, Content-Security-Policy with strict source allowlist, signed-artifact CI, Dependabot continuous dependency updates.

What does not belong here

Third-party services we depend on (Vercel, Supabase, Stripe, OpenAI, Resend, Cloudflare) — please report directly to those vendors.

Findings that require physical access to a Yotta-Byte Labs device, social-engineering of personnel, or coercion.

Denial-of-service, brute-force, or automated scanning of the live site at volume.

Self-XSS, missing security headers without a demonstrated impact, and reports that boil down to "user installs malware on their own machine".

Send your finding to the security inbox

Email security@journal-genie.com. The inbox is operationally verified and routes directly to the founder. PGP-encrypted email is available on request.

Use the canonical address: security@journal-genie.com. We acknowledge within five business days.

Include a clear reproduction, the affected URL or component, and any proof-of-concept payload — keep payloads minimal.

Stop at proof of vulnerability. Do not exfiltrate user data, modify accounts you do not own, or pivot deeper than necessary to demonstrate impact.

If you discover personal data of another user, stop, do not retain it, and tell us immediately.

Severity targets

Severity is classified using a CVSS-style impact-times-likelihood frame. The targets below are engineering aims, not contractual guarantees; we communicate openly when a fix needs more time.

Severity	Target	Examples
Critical	Triage within 24 hours, mitigation in flight within 72 hours	Remote code execution, authentication bypass, full account takeover, data exfiltration affecting more than one user
High	Triage within 3 business days, mitigation in flight within 14 days	Stored XSS in an authenticated surface, IDOR exposing another user's notebook or journal, privilege escalation
Medium	Triage within 7 business days, mitigation in flight within 30 days	Reflected XSS, missing authorization on a non-sensitive endpoint, CSRF on a non-state-changing surface
Low	Triage within 14 business days; fix scheduled with the next routine release	Information leakage with limited impact, rate-limit gaps that do not affect availability, configuration drift

Good-faith research is welcome