Security & data handling
This page answers the question we're asked most: where does production content go, and what (if anything) talks to the internet. It's written in plain terms, goes into real detail rather than reassurance, and includes a section on tradeoffs we made deliberately rather than leaving them for someone else to discover.
01Processing is local
Speech-to-text, speaker diarization, and the text clean-up pass all run as local processes on the machine (or local server) running BananaScribe. None of them send audio, video, or transcript text to a cloud API as part of normal operation. The clean-up model specifically runs through a local model server (Ollama) bound to the machine's own loopback address — it isn't reachable from the network at all, let alone the internet. There is no analytics or telemetry call anywhere in the processing pipeline.
02The one network dependency
The speech-recognition and speaker-diarization models BananaScribe uses are open-source models published on Hugging Face, a widely used public repository for machine-learning models — the same place almost any modern speech-AI tool gets its models from. The first time a given model is used (or whenever a different model is selected), the app downloads that model's files once.
That download is model files only — generic, publicly published weights, identical for every installation. It never includes or transmits any production audio, video, or transcript content, and it carries no information about the job being processed. Once downloaded, a model is cached locally on disk and reused; no further contact with that service is needed to keep transcribing with it. A machine with every needed model already cached can transcribe with no internet connection at all.
03Network boundary, visually
pywebview window
Native UI shell
FastAPI server
Loopback, or LAN in shared mode
faster-whisper
Speech-to-text, local GPU/CPU
pyannote.audio
Diarization, local GPU/CPU
Ollama
Text clean-up, loopback only
Local storage
Media + transcripts on disk
Hugging Face model hub
One-time model file download only — no production content ever sent
Our update server
Installer-initiated, HTTPS, checksum-verified — see Updates
04Access control
BananaScribe runs in one of two modes:
| Single-user (desktop) | Runs entirely on one machine; the app talks only to itself on that machine over its loopback address. There's no login screen because there's nothing to share. |
|---|---|
| Shared (local network) | One instance runs on a production's own local server; team members sign in with individual username/password accounts over that local network. Signing in from a new device ends that account's existing session elsewhere; sessions expire automatically after a period of inactivity; an administrator can add, remove, reset, or promote/demote accounts from inside the app. |
In shared mode, this is a private, internal tool for one production's own team on their own network — it's built and intended for a trusted LAN, not for exposure to the public internet. See Known tradeoffs for what that does and doesn't assume about the network it runs on.
05Session handling, in detail
- Every page/API request in shared mode is gated behind a valid session except the login request itself — there's no accidental "public" endpoint.
- Sessions use a server-generated token in an
HttpOnlycookie, so page scripts can't read it, with a sliding idle timeout: activity keeps a session alive, but real idle time (default 30 minutes) ends it automatically. - Logging in from a second device immediately invalidates that account's session on the first device — one active machine per account at a time.
- Session state is kept server-side (not trusted from the client) and persists across a service restart, so a restart doesn't silently leave stale sessions valid forever, nor does it need every user to notice and re-login for unrelated reasons.
- Administrators can forcibly reset a user's password, which also invalidates that user's existing sessions immediately.
06Storage & retention
Imported media and the transcripts produced from it are kept in a working folder on the machine or local server running the app, so finished jobs remain available for re-export after a restart — this is deliberate: a shared instance may be mid-batch overnight, and a restart shouldn't lose that queue. A job (and its underlying files on disk) is removed when a user deletes it from the app; nothing is copied anywhere else as part of normal use, and nothing is retained beyond what the app's own job list shows the user.
Account credentials and session data are stored separately from job data specifically so that they survive independently of it — accounts shouldn't disappear just because job history was cleared, and vice versa.
07Updates & integrity
New versions are built and published by us, then fetched by the installer over HTTPS from our own update server. After download, the installer verifies the package's checksum before anything is installed, and compares a build-version marker so a client is told plainly when they're running an outdated copy rather than silently reproducing a bug that's already been fixed upstream. Updating is something a user or operator initiates by running the installer again — the running application does not reach out and update itself in the background.
08Dependencies & supply chain
The processing stack is built on well-established, widely used open-source components rather than bespoke or obscure ones:
Python dependency versions are pinned rather than left floating, with the specific pins documented in source (including the reasons behind them — e.g. a known hang in a newer cuDNN build on Windows+CUDA was avoided by pinning to the last known-good version rather than shipping the regression). The installer bundles a self-contained Python runtime rather than relying on whatever Python may or may not already be on a client's machine.
09Logging
The desktop app writes a local diagnostic log (timestamps, job status transitions, errors) to help troubleshoot a specific machine when something goes wrong. It stays on that machine — it is not automatically collected or transmitted anywhere; sharing it with us for support is always a deliberate, manual step taken by the user.
10Known tradeoffs — disclosed, not hidden
Rather than present this as a flawless system, here are the specific tradeoffs we made and why, so a review doesn't have to go looking for them:
Password storage uses SHA-512 hashing without a per-user salt
This is weaker than a modern password-hashing KDF (bcrypt/scrypt/ argon2). It's an accepted tradeoff for what this is: a closed, internal tool with a handful of production accounts on a private LAN, not a public-facing service handling the general population's credentials. We're flagging it rather than silently shipping it as if it were state of the art — strengthening it to a proper KDF is a small, well-understood change if a review wants it prioritized.
The shared-mode web interface runs over plain HTTP, not HTTPS
It's designed to run on a trusted production LAN, not the open internet, which is the assumption behind this choice — but we're naming it explicitly rather than letting "it's internal" quietly stand in for "we checked." Login credentials and session cookies therefore aren't protected by transport encryption on that network segment. Putting it behind TLS (even a self-signed certificate trusted only within the production) is a reasonable hardening step if a given deployment's network isn't fully trusted.
The default first-run account is a known admin/admin login
This exists purely so the app is usable immediately after install with no manual setup step, the same way most self-hosted LAN tools ship with a documented first-run default. It is meant to be changed immediately from the user-administration screen, and an operator can also supply their own initial admin credentials at install time instead of ever letting the default exist.
11Security Q&A
- Does any customer audio or video ever leave the machine it's imported on?
- No, not as part of normal operation. The only outbound network call in the processing path is the one-time, content-free model download described above.
- Is an internet connection required to use BananaScribe?
- Not for transcription itself, once the relevant models are cached locally. An internet connection is needed the first time a given model is used, and when checking for/installing a software update.
- Can BananaScribe be exposed to the public internet?
- It isn't designed for that and we don't recommend it — shared mode assumes a trusted local network. See the tradeoffs above for the specific reasons (no TLS by default, a documented first-run default login).
- Who can see a production's transcripts in shared mode?
- Only accounts created on that instance by an administrator, over that instance's own local network, within an active (non-idle) session.
- What happens to project data if the service restarts?
- Job data and accounts both persist across a restart — nothing is silently wiped — but any chunk mid-processing at the moment of restart simply resumes from its last checkpoint.
- Is there a question here we haven't anticipated?
- If a review needs a specific control, certification, or technical detail confirmed that isn't above, we'd rather answer it directly than have this page guess at it.