Encryption in Transit
All data between your device and our servers travels over TLS 1.2+. We enforce HTTPS everywhere with HSTS headers.
Encryption at Rest
All data stored in Supabase Postgres and Supabase Storage is encrypted at rest using AES-256 on AWS infrastructure.
Data Isolation
Row Level Security enforces that every database query is automatically scoped to the authenticated user. No sharing between accounts is possible at the database layer.
Secure Infrastructure
We run on Supabase (AWS eu-west-1), which holds SOC 2 Type II certification. No data is stored on servers we manage manually.
No Key Exposure
API keys for Deepgram and Anthropic are never embedded in the app binary. They are accessed via server-side Supabase Edge Functions and never reach the client bundle.
No AI Training on Your Data
Your recordings, transcripts, and notes are never used to train AI models. Anthropic's API terms prohibit use of API inputs for model training.
Authentication
Authentication is handled entirely by Supabase Auth, which implements industry-standard JWT-based session management. We do not build or maintain our own authentication system.
- Passwords are never stored in plaintext. Supabase uses bcrypt hashing.
- Session tokens are short-lived JWTs with automatic refresh.
- Email verification is required before account activation.
- We support secure email-link (magic link) login as an alternative to passwords.
- All authentication events are logged for security audit purposes.
Row Level Security (RLS)
Every table in our database has PostgreSQL Row Level Security enabled. This is a database-level enforcement mechanism, not an application-level check.
What this means in practice: even if there were a bug in our application code that attempted to query another user's data, the database itself would return zero rows. The policy for every user-owned table is:
This applies to all tables: sessions, transcripts, notes, bookmarks, photos, and summaries. The Supabase anon key exposed in the app has no elevated privileges beyond what RLS permits for the authenticated user.
Data Isolation Between Users
Each user's data is logically isolated. There are no shared storage buckets with public read access. File paths in Supabase Storage include a user-specific UUID prefix, and access is controlled by storage RLS policies that match the authenticated user's ID.
We do not have team collaboration features that allow cross-user data access. If such features are added in the future, they will be implemented with explicit per-resource permission grants, not blanket team access.
Third-Party Service Security
Supabase
SOC 2 Type II certified. Data hosted on AWS eu-west-1 (Ireland). Supabase manages database backups, encryption, and infrastructure patching.
Deepgram (Transcription)
Audio is transmitted over TLS / WSS and processed under Deepgram's data processing terms. Audio is processed in-memory by the transcription model and not retained beyond the API call.
Anthropic (AI Summaries & OCR)
Only transcription text and slide photos are sent to Anthropic's Claude API. Anthropic's API usage policy prohibits use of API inputs to train foundation models, and processing is governed by Anthropic's data processing terms.
Stripe (Payments)
Payment card data is never transmitted to or stored by us. Stripe handles all payment processing with PCI DSS Level 1 compliance. We receive only payment metadata (plan, status, invoice IDs).
We Never Train AI on Your Data
Your recordings, transcriptions, notes, and summaries are used solely to provide the Service to you. We do not use your content to train, fine-tune, or evaluate any machine learning model.
When we send transcription text to Anthropic's Claude API, Anthropic's API terms of service explicitly prohibit Anthropic from using API inputs to train their models. This is a contractual protection on top of our own policy commitment.
Responsible Disclosure
If you discover a security vulnerability in Conference Ink, please report it privately to:
hello@conferenceink.comPlease include a description of the vulnerability, steps to reproduce, and its potential impact. We will acknowledge your report within 48 hours and aim to release a fix within 30 days for critical issues. We ask that you do not publicly disclose the vulnerability until we have had an opportunity to address it.