Built local-first. Documented honestly.
Most security pages oversell. This one lays out the real data flows, the controls actually in place, and the things we haven't locked down yet — for the website, your account, your payment, and the desktop app.
Your machine does the work. Almost nothing leaves.
The whole pipeline runs on your computer. The only outbound calls are the ones you choose — and here’s exactly what they are.
On your machine
The desktop app is local-first — these are the controls that keep your work yours.
Your data lives on your device
Scripts, scenes, brand bibles, render outputs and the SQLite database are stored locally — %APPDATA% on Windows, ~/Library/Application Support on macOS. We don't run servers that hold any of it. We can't leak what we never have.
The renderer can't phone home
In production the desktop renderer's network access is locked by Content-Security-Policy to 127.0.0.1. The part of the app that handles your footage and prompts is confined to your own machine by design — not just by policy.
Secrets stay in the OS keychain
Your AI provider API keys and YouTube OAuth tokens are stored in your operating system's encrypted keychain (Windows Credential Manager / macOS Keychain), not in plaintext config we can read. They leave only in the headers of calls you initiate, to the provider you chose.
No desktop telemetry
The desktop app ships zero usage tracking — no analytics, no crash reporting, no source-file metadata, no prompt or completion logging. We don't proxy your AI calls and never see your prompts.
Your account, payment & our infrastructure
When you create an account or buy a license, a small amount of data does reach our systems. Here’s how it’s protected.
Payment security
Payments run through Stripe (PCI-DSS Level 1). Card details go straight to Stripe and never touch our servers. Purchase webhooks are signature-verified — only a cryptographically-verified Stripe event can grant your license, so a forged request can't unlock the app.
Account & database hardening
The optional web account runs on Supabase with row-level security on every table, so one account can never read another's rows. Service-role keys are server-side only and never shipped to the browser. New passwords are screened against known breaches (HIBP, via k-anonymity — your password is never sent).
Encrypted transport & hosting
Everything is served over HTTPS/TLS. The website runs on Vercel with a strict Content-Security-Policy and standard security headers. The authenticated app surface is noindex and gated behind sign-in.
Authenticated email
Our domain publishes SPF, DKIM and DMARC, so receipts, license and support emails are cryptographically authenticated and can't be trivially spoofed in your inbox.
The full list of sub-processors and what each handles is in the Privacy Policy.
YouTube OAuth, scoped tight
When you connect a channel, the app requests only the scopes it actually uses — and the token never leaves your device.
youtube.upload— publish the videos you make to your own channel.youtube.readonly— list your own channels and read your own video metadata.yt-analytics.readonly— show your own analytics in the app.youtube.force-ssl— required to upload captions for your own videos.openid · email— identify which account you signed in with.
Google user data is never sold, never shared, never used for ads, and never used to train models — our use adheres to the Google API Services User Data Policy, including Limited Use. Revoke anytime at myaccount.google.com/permissions.
Honest gaps + known issues
What we’d disclose in any security review — listed up-front so you don’t have to dig.
Installers are currently unsigned
Windows SmartScreen — and macOS Gatekeeper — warn on first run because the builds aren't code-signed yet (EV certs cost ~$300-700/yr). On Windows click 'More info' → 'Run anyway'; on macOS right-click → Open. Installers are published only from GitHub Releases on a repo we control, over HTTPS. Code-signing is on the roadmap.
Auto-update is HTTPS, not signature-verified
Update checks fetch version metadata from GitHub Releases (HTTPS) and the download is served by GitHub's CDN. We don't yet verify a separate signature on the binary itself — integrity relies on TLS and on trusting the GitHub release.
We use third-party processors
Analytics (PostHog), crash reporting (Sentry), payments (Stripe), auth/database (Supabase) and email (Resend) are third parties with their own security programs. They're listed in the Privacy Policy; you can opt out of website analytics or block them at the network level.
No third-party audit or SOC 2 yet
We have not (yet) completed an independent penetration test or a SOC 2 / ISO 27001 audit. This page is an honest description of the controls in place today, not a formal attestation. Enterprise compliance documentation will follow as we grow.
Reporting a vulnerability
Found something concerning? Email security@tubefrogeai.app or open a GitHub issue marked [security] at our repository.
- We aim to acknowledge within 48 hours and to keep you updated through the fix.
- Coordinated disclosure: please give us 14 days to ship a fix before going public.
- Good-faith safe harbour: we won’t pursue action against research that respects user privacy, avoids data destruction, and doesn’t degrade the service.
- No paid bounty program yet — but you’ll get clear credit in the changelog if you’d like it.
This page describes the security controls in place today for a live, paid product. It is not an independent audit or SOC 2 / ISO 27001 attestation — see the gaps above, and the Privacy Policy for how data is handled.