Security Statement — Me Journal

Last updated: 2026-07-07

This page describes the technical and organisational security measures we take to protect your personal data on Me Journal. It is the public companion to our Privacy Policy and Cookie Policy.

If you spot something on this page that's wrong, missing, or you'd like to know more about — email security@me-journal.com.

1. Who we are, security-wise

Me Journal is operated by Astronero Ltd, a private limited company registered in England & Wales. Our founder is an information security professional with an MSc in cybersecurity, ISO 27001 lead auditor certification, and 10+ years' experience implementing ISMS frameworks.

Security is not an afterthought here. It's the founder's day-job discipline applied to their own product.

2. The data we protect

In order of sensitivity:

1. Journal entries, mood logs, gratitude entries — special-category personal data under Article 9 GDPR; sensitive personal information under CPRA
2. Cycle & symptom tracking data (Body Compass) — health data; special-category under Article 9 GDPR and consumer health data under US state health-privacy laws. Private by default: sharing and AI processing are switched off. It is stored encrypted at rest but, unlike journal content, it is not end-to-end encrypted — the application can read it to render your calendar and cycle insights (see § 3.1)
3. Programme entries — not legally special-category but personally private
4. Account data — email, name (optional)
5. Authentication data — handled by Clerk; we never see plain-text passwords
6. Payment data — handled by Stripe; we never see full card numbers
7. Operational data — server logs, push subscription endpoints

All categories are encrypted in transit and at rest (see § 3).

3. Technical measures

3.1 Encryption

• End-to-end encryption of journal content: your journal entries, entry titles, programme reflections, mood notes and gratitude items are encrypted in your browser, before they are sent to us, using AES-256-GCM. The encryption key is derived from your vault password (PBKDF2-HMAC-SHA256, 600,000 iterations) and never leaves your device. Nobody at Me Journal — including the founder and anyone with database access — can read this content. The trade-off is deliberate: if you lose your vault password, we cannot recover the content either.
• In transit: TLS 1.2+ on every connection. We do not accept un-encrypted HTTP. A Strict-Transport-Security (HSTS) header with a one-year lifetime is sent on every page; we have deliberately not yet opted into browser preload while our subdomain set stabilises.
• At rest: Convex (our database) encrypts all stored data using AES-256. Cloudflare R2 (object storage used for video media and archived logs) also encrypts at rest; meditation audio currently lives in Convex's encrypted file storage. Journal content is therefore encrypted twice at rest — once by your vault key, once by the infrastructure.
• Backups: Convex's daily snapshots are encrypted using the same keys; the backup system itself is operated by Convex under their SOC 2 controls. Vault-encrypted content remains vault-encrypted inside every backup.
• Quantum readiness: the vault layer that protects journal content uses only symmetric cryptography (AES-256-GCM), which is considered quantum-resistant: even against a quantum computer running Grover's algorithm, a 256-bit key retains roughly 128 bits of effective security — still computationally infeasible to break. There is no quantum-vulnerable key exchange anywhere in the vault design. This matters for the "harvest now, decrypt later" scenario (recording encrypted traffic today to decrypt it once quantum computers mature): because journal content is encrypted on your device before transmission, a future decryption of recorded traffic would still yield only AES-256 ciphertext. The asymmetric layer that is quantum-vulnerable (TLS key exchange) is operated by our infrastructure providers, who are deploying NIST-standardised post-quantum key exchange (ML-KEM hybrids, FIPS 203); we inherit that protection as it rolls out. We deliberately do not claim to be "quantum-proof" — no honest vendor can.

3.2 Authentication

• Provided by Clerk. They are SOC 2 Type II certified.
• Passwords are never stored by Me Journal — Clerk handles the hashing (bcrypt with appropriate cost factor).
• Multi-factor authentication (MFA) is available for all users via Clerk; we strongly encourage enabling it.
• Session tokens are managed by Clerk: a long-lived client token is held in a Secure, HttpOnly cookie on Clerk's own domain and exchanged for short-lived session tokens that expire within about a minute and rotate automatically — so a leaked session token goes stale almost immediately.

3.3 Authorization

• Every Convex query and mutation that reads or writes user data explicitly verifies the caller's identity via ctx.auth.getUserIdentity() before returning anything. There is no row-level-security shortcut — explicit checks are the only path. A small number of endpoints that carry no personal content (for example the public status page and the waitlist form) are deliberately public.
• Admin functions are gated by a dedicated authorisation layer (convex/adminAuth.ts). Admin authority resolves only from the founder's Clerk role flag, a server-held list of admin email addresses, or a server-side scoped allowlist — and every email-based path is honoured only for verified email addresses, so nobody can gain admin by claiming an email on an unverified account. Scoped admins receive only the sections they have explicitly been granted. All admin grants are a manual operation by the founder.
• Server-side route loaders (like the dashboard layout) enforce signed-in status and tier checks before rendering authenticated pages.

3.4 Network and infrastructure

• Hosted on Vercel (SOC 2 Type II) for the application layer
• Database on Convex (SOC 2 Type II)
• Authentication via Clerk (SOC 2 Type II)
• Payments via Stripe (PCI DSS Level 1)
• Object storage on Cloudflare R2 (SOC 2; ISO 27001)
• All providers have signed Data Processing Addenda compliant with GDPR Article 28
• We do not run our own servers, our own databases, or our own payment infrastructure — reducing attack surface and ensuring our underlying providers' security investments work for us

3.5 Application security

• Dependency scanning: npm audit reviewed regularly; security advisories actioned within agreed timeframes (critical: 24 hours; high: 7 days; medium: 30 days)
• Input validation: Convex's schema layer enforces the shape of every mutation argument; arbitrary input cannot reach the database
• Output encoding: React's default escaping prevents XSS; we use dangerouslySetInnerHTML only on internal scripts (theme, service worker registration), never on user input. The one place we render user-generated HTML (viewing a journal entry) is sanitised with DOMPurify before rendering (closing our SECURITY_AUDIT.md M1 finding)
• CSRF: state-changing operations run through Convex, which authenticates each call with an explicitly attached short-lived token rather than an ambient browser cookie — so a forged cross-site request arrives without credentials
• Secrets management: API keys live only in Convex / Vercel encrypted environment variables. They are never committed to source control. All assistant tooling on this project is rule-bound to never read or echo .env* files (per our internal secrets_rotation_backlog.md governance rule)
• Security headers + Content Security Policy: every page is served with X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, anti-framing headers (X-Frame-Options: DENY plus CSP frame-ancestors 'none') and a one-year HSTS header. A strict nonce-based Content-Security-Policy — the control that stops a script-injection bug from reaching vault material — is currently deployed in report-only mode while we confirm it blocks nothing legitimate, and flips to enforcing once that monitoring is clean. Until then it observes rather than blocks; we state that plainly rather than over-claim.

3.6 AI-specific safeguards

• Crisis detection runs before every AI call made through our gated AI pipeline — pattern matching for self-harm / suicide / abuse indicators refuses the LLM call so crisis-resource copy can be shown instead (convex/crisisDetection.ts, enforced in convex/aiGate.ts). Two lightweight endpoints (mood recommendations and in-app chat) currently sit outside this pipeline; bringing them behind the same gate is tracked as follow-up work.
• Usage caps and rate limits prevent any single user from consuming unbounded AI resources: per-tier spend caps on gated AI features (convex/aiGate.ts), plus per-IP and global hourly rate limits on the public AI endpoints (convex/http.ts).
• No training on your content — our AI providers' API terms do not permit training on Me Journal user content, and content sent for a response is held by the provider only briefly for safety monitoring, then deleted. We have not yet signed a formal zero-data-retention agreement, so we deliberately do not claim literal "zero retention".
• Tier-locked features registry (convex/tierFeatures.ts) — every AI feature must be registered, gated by tier, and reviewed before it ships.

4. Organisational measures

4.1 Access controls

• Me Journal staff routinely have no access to user-content databases. The only times access is needed (for incident debugging, user-initiated support requests) are logged and time-limited.
• Production database access requires MFA via Convex.
• Code deployment requires GitHub access — protected by MFA.
• Vercel + Convex + Cloudflare admin consoles all require MFA.

4.2 Vendor management

• Every sub-processor undergoes a basic security review before being added (SOC 2 / ISO 27001 certification preferred; security documentation reviewed; DPA confirmed).
• The current sub-processor list is published at https://me-journal.com/legal/sub-processors and updated within 30 days of any change.

4.3 Personnel

• Currently a single founder. As the team grows, all staff with potential access to user data will:
  • Sign confidentiality agreements
  • Complete security awareness training before access is granted
  • Have access reviewed every 90 days; revoked when no longer needed

4.4 ISMS framing

While Me Journal is not currently certified to ISO 27001 (the cost vs. benefit at our scale is hard to justify pre-launch), we operate against the ISO 27001 framework informally:

• A Statement of Applicability is maintained internally
• Risk assessments are documented and reviewed quarterly
• Incident response procedures are written, tested, and reviewed
• Access control policies are written and enforced
• Backup and disaster recovery procedures are documented

We expect to seek formal ISO 27001 certification once we reach a scale where the audit cost is proportionate.

5. Incident response

If a personal data breach occurs that affects our users:

1. Containment: within 24 hours of identification, the breach is contained (access revoked, vulnerability patched, affected systems isolated as needed)
2. Notification to supervisory authority: within 72 hours of becoming aware (UK GDPR + EU GDPR Article 33), a notification is filed with the Information Commissioner's Office (ICO) and any other relevant regulator
3. Notification to affected users: if the breach is likely to result in a high risk to your rights and freedoms (Article 34 / equivalent in CPRA), we email you directly with:
   • A description of what happened
   • The likely consequences
   • The steps we've taken
   • Steps you should take (e.g. change password, enable MFA)
4. Post-incident review: within 30 days, a written review is completed, root causes documented, and corrective actions tracked to closure
5. Public statement: for material breaches, a public post-mortem is published on our public status page (me-journal.com/status) within 60 days

We do not bury security incidents. We tell users.

6. Your security obligations

To keep your account secure:

• Use a strong, unique password — your account is only as secure as this credential
• Enable MFA via Clerk (open Account from the app menu, then the Security tab)
• Don't share your password or sign-in link with anyone
• Sign out from shared devices when you finish
• Tell us immediately if you suspect unauthorised access: security@me-journal.com

7. Vulnerability disclosure

If you discover a security vulnerability in Me Journal, please report it to security@me-journal.com. We commit to:

• Acknowledging receipt within 5 business days
• Providing a status update within 14 days
• Patching critical vulnerabilities within 7 days (or ASAP)
• Crediting you publicly (with your permission) once the fix ships

We do not currently operate a paid bug bounty programme, but we do celebrate good-faith researchers and we will not pursue legal action against researchers acting in line with this policy.

In scope:

• The Me Journal web application at https://me-journal.com
• Our public Convex API endpoints
• Our subdomains and admin paths

Out of scope:

• Social engineering
• Physical attacks
• Denial-of-service testing
• Issues in upstream providers (Convex, Clerk, Stripe, Vercel, Cloudflare) — please report those directly to the provider

8. Contact

• Security questions, vulnerability reports: security@me-journal.com
• Privacy questions: privacy@me-journal.com
• General contact: support@me-journal.com