Reelly — Security Overview

Version 1.0 · Last updated: 2026‑09‑21

Reelly is built and operated by one person, Benjamin Ollomo, and is currently an invitation-only beta. This page describes the security measures that are actually in place today and, just as importantly, the ones that are not. It is a plain-language summary, not a SOC 2 report or an ISO/IEC 27001 certificate — see Section 9.

1. Compliance posture — stated plainly

Reelly holds no security certifications and no third-party audits. It is not SOC 2 examined, not ISO/IEC 27001 certified, and not subject to HIPAA, PCI DSS, or any comparable regime — it handles no health records, no payment-card data, and no government identifiers. There is no compliance programme, no external auditor, and no penetration-test report. Anything asserted below is a description of how the software is built, verifiable in the code, not a claim validated by anyone else.

If you are evaluating Reelly for anything beyond personal use, treat it as what it is: beta software from an independent developer.

2. Scope

This document covers the Reelly service — the iOS app, the authentication service, and the backend API and its extraction and search workers — together with the managed database and object storage they depend on.

3. Shared responsibility

• The infrastructure providers — the managed database host, the object storage provider, the application host, and the email delivery provider — are responsible for physical data-centre security, hardware, and their own service control planes, and maintain their own independent attestations for that layer.
• Reelly is responsible for everything above that: application code, authentication and authorization, data handling, storage configuration, and responding to problems.

4. Architecture (security view)

Reelly is three services that the iOS app talks to:

• Auth service. Handles email/password sign-in against an approved-email allowlist, requires email verification, and issues signed JWTs. Passwords are stored only as salted hashes.
• API. Validates the JWT on every request against the auth service’s published keys, then serves only records belonging to that owner. Items, collections, and duplicate detection are all scoped per owner; there is no endpoint that returns another account’s data.
• Extraction and search workers. Run durable jobs that fetch public URLs, call OpenAI for transcription, visual-text extraction, summaries, and embeddings, and write the results back to the owner’s items.

5. Data protection

5.1 What is stored

5.2 Encryption

• In transit. Traffic to the API, the auth service, the database, and object storage uses TLS.
• At rest. Encryption at rest is whatever the managed database and object-storage providers apply by default. There are no customer-managed keys and no per-class key separation.

5.3 Preview images

The storage bucket is private. Previews are never public objects; the app receives a short-lived signed URL for each image, which expires on its own. Without a signed URL there is no path to the file.

5.4 Secrets

Credentials live in server-side environment configuration and are never shipped in the mobile app or committed to the repository. The mobile app holds only the public API and auth URLs.

6. Identity and access

• Sign-in. Email and password with mandatory email verification, or Google sign-in where configured. Access is additionally gated by an approved-email allowlist, so an address that has not been invited cannot register.
• Per-request authorization. Every API call must present a valid bearer token. Requests without one are rejected; requests with one see only their own owner’s records.
• Administrative access. As sole operator I hold credentials to the database and storage. There is no second person to approve access and no break-glass workflow — an honest statement of the limits of a one-person project, and the reason access is kept to fault diagnosis, abuse investigation, and legal obligations.

7. What the extraction pipeline will and will not do

• Public URLs only. No file uploads are accepted.
• No platform login cookies, credentials, or sessions are used, ever.
• Comments and replies are not read or stored.
• Platform access varies and changes without notice, so items can legitimately end up partial or failed. Those states are recorded and retryable rather than silently papered over.
• Nothing saved is used to train any AI model.

8. Logging and monitoring

The application logs request metadata, job outcomes, and errors for debugging. Hosting providers keep their own access logs under their own retention settings. There is no dedicated security-monitoring stack, no SIEM, no immutable audit trail, and no 24/7 on-call rotation.

9. What is not in place

Stated explicitly so you are not guessing:

• No SOC 2 examination, ISO/IEC 27001 certification, or any other audit.
• No third-party penetration test.
• No bug-bounty programme.
• No customer-managed encryption keys and no per-class key separation.
• No formal incident-response plan with contractual notification deadlines.
• No uptime guarantee, service-level agreement, or disaster-recovery commitment.
• No end-to-end encryption — the backend must read item text to index and search it.
• No multi-factor authentication for user accounts yet.

10. Incident handling

If a security incident affects your data, I will investigate, fix the cause, and email affected users with what happened and what to do, as promptly as I reasonably can. There is no contractual deadline behind that commitment — it is a statement of intent from the person who runs the service.

11. Reporting a vulnerability

Reports are welcome and will be taken seriously. Email benji.ollomo@gmail.com with steps to reproduce and the impact you observed. Please test only against your own account, avoid accessing or modifying anyone else’s data, avoid denial-of-service and social engineering, and give me a reasonable chance to fix the issue before disclosing it publicly. Good-faith research along those lines will not be pursued as a violation of the Terms. There is no monetary bounty.

12. Contact

Benjamin Ollomo
Email: benji.ollomo@gmail.com