Security & data handling

The lifecycle of an uploaded file is short and one-directional: it is staged only long enough to be transcribed, then removed.

• Direct, signed upload. Your browser uploads the file straight to encrypted object storage (Cloudflare R2) using a presigned URL that expires one hour after it is created. The file never travels through a public link, and large files are sent in parts to the same signed destination.
• Encrypted in transit and at rest. Transfers use TLS. Objects are stored in Cloudflare R2, which encrypts data at rest by default. (The encryption at rest is a platform property of R2, not something the application configures per object.)
• Handed off read-only. To transcribe, the file is fetched by the transcription provider through a separate signed, read-only link.
• Deleted after transcription. The moment the transcript is produced, the original recording is deleted from our storage and its links are cleared, in the same step that saves the transcript. Case intelligence then runs on the transcript text, not the audio. If a delete ever fails, a job that runs every day reclaims any recording left behind, keeping the transcript.

Every record (transcript, analysis, drafted document, and case metadata) belongs to one account, and access is checked on every request.

• Ownership checked on every read and write. The server verifies that the signed-in user owns the record before returning or changing it. A request for a record you do not own returns “not found” (404), so your account cannot even confirm that another account’s record exists. This isolation is enforced in the application layer.
• Signed, HttpOnly session cookie. Sessions are a stateless token signed with HMAC-SHA256 and verified in constant time on every request. The cookie is HttpOnly (page scripts cannot read it), Secure in production (sent only over HTTPS), SameSite=Lax, and lasts seven days.
• Fail-closed on a missing secret. If the signing secret is ever absent in production, the app refuses to issue or accept any session rather than fall back to a guessable default.
• Passwords are hashed, never stored. Passwords are stored using scrypt with a per-user random salt and compared in constant time. We never keep your plaintext password.

A single toggle in the review screen masks personal identifiers across the transcript, so you can produce a shareable copy without exposing sensitive details.

• Two layers of masking. Redaction masks (a) every span the transcription engine tags as one of twenty identifier types (names, email, phone, location, Social Security number, credit-card number, CVV and expiration, banking and account numbers, date of birth, driver’s license, passport, IP address, and more), and (b) six structured formats matched directly in the text (Social Security number, email, formatted phone, grouped card numbers, and IPv4). The second layer also catches identifiers you type into a manual correction.
• Reversible and non-destructive. Masking is applied to a copy for viewing and export. Your original transcript is never altered, so the evidentiary record stays intact.
• The redacted export is document-wide. When you export with redaction on, the same masking is applied to the testimony lines, the AI case summary (including party names), the speaker labels, and the case caption, so the analysis does not leak what the testimony hides.
• Its one limit is detection. Identifiers are masked when the engine recognizes them, so a name it misses, or one you type into an edited line that matches no known pattern, can still appear. Give a redacted export a final read before you share it.

You see the price before you pay, and the figure is computed on our servers, not by your browser.

• Length measured on the server. The billable length is measured on our server by reading the uploaded file’s own container metadata (via ranged reads of the stored object, no full download). The number your browser reports is used only as a fallback when the server cannot read the file, and then only within a file-size plausibility check.
• Server-authoritative price. At checkout your browser sends only the transcript identifier. The amount is recomputed on the server from the stored record (billable minutes at a fixed per-minute rate), so the browser cannot change what you are charged.
• Card details never reach us. Payments run on Stripe-hosted checkout. Card data is entered on Stripe’s page and is never transmitted to or stored by us. We keep only Stripe’s identifiers and the amount charged.
• Payment callbacks are authenticated. Stripe’s completion notice is cryptographically signature-verified against the exact raw request body before we act on it. The transcription provider’s completion callback is authenticated with a shared secret in a custom header; that callback carries only a job identifier, and we then re-fetch the finished transcript over our own authenticated connection to the provider, so a forged callback cannot inject transcript content.

Controls that apply to the whole application, on every request:

• Strict response headers. Every response carries HTTP Strict Transport Security (two years, preload-eligible), a strict Content-Security-Policy, framing denied (X-Frame-Options: DENY and frame-ancestors ‘none’), X-Content-Type-Options: nosniff, a Referrer-Policy, a Permissions-Policy that disables camera, microphone, and geolocation, and Cross-Origin-Opener-Policy: same-origin. The framework version is not advertised.
• Locked-down media fetching. The transcription provider can only be pointed at files on our own allow-listed storage, which prevents it from being used to fetch arbitrary URLs.
• Authenticated maintenance jobs. The scheduled cleanup and reconcile jobs require a secret bearer token and refuse to run without it.
• Rate-limited authentication. Login and signup are rate-limited to throttle brute-force and abuse.

We use a small set of vendors to run the Service, under agreements that limit their use of your data. Each receives only what it needs:

Stated in days, from what the software actually does:

• Original recording: deleted as soon as the transcript is produced (kept zero days beyond processing). A daily safety sweep removes, within about one day, any recording that a failed delete left behind.
• Unpaid, abandoned uploads: deleted after a one-day grace period by a daily job, and immediately if you cancel checkout or the payment session expires. Worst case is roughly two days, because the sweep runs once a day.
• Transcripts, analysis, and account data: kept while your account is active so you can use them, and removed on account deletion, subject to any retention we are legally required to maintain.

Note: signed upload links live at most one hour and signed download links at most seven days. Those are link lifetimes, not how long data is kept, and the recording itself is already deleted once transcription completes.

We do not use your recordings, transcripts, or analysis to train any model. We operate no training or fine-tuning pipeline; the AI features are inference requests that return your results and nothing more.

Our AI subprocessor (AssemblyAI, and the model provider behind its gateway) processes your data to produce those results. How a provider may use data for its own purposes is governed by that provider’s terms and data-processing agreement, not by our software, so we state only what our own code does and point you to the provider for theirs.

• Delete records yourself. You can delete individual transcripts and drafted documents in the app at any time. Deleting a transcript also frees its stored media.
• Delete your whole account. To remove your account and all associated records, email juris.compiler.ai@gmail.com. We delete the account and its transcripts and analysis (removal cascades to everything tied to the account).
• Access and export. You can request access to or an export of your data at the same address.

Security questions, data requests, or a vulnerability to report can be sent to juris.compiler.ai@gmail.com. We also maintain a Privacy Policy and Terms of Service.