[Backend] Stop writing transcript text to logs, and scrub retained production logs #325

New issue

Closed

opened 2026-08-25 20:38:44 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-08-25 20:38:44 +00:00

Collaborator

Severity: MEDIUM (privacy). Found in the August 2026 session lifecycle review (#319).

The defect

audio_service.py:524-528 logs str(data)[:500] of the transcription server's response at INFO. That repr opens with the segments array, so the first 500 characters comfortably carry several utterances of real dialogue together with the speakers' display names.

This directly violates the module's own stated invariant at audio_service.py:24-25:

Neither the transcript nor the summary is ever written to logs. Only metadata (char counts, word count, session_id) appears in log lines.

The root logger runs at INFO (webapp/backend/app/logging_config.py, configure_logging(log_level="INFO")), so the line is live in production.

Scope of the exposure

Verified against production: one matching line in the worker's retained logs (docker compose logs --since 720h worker | grep -c "WhisperX raw response" → 1; backend → 0). So the current exposure is one session's opening dialogue. The Docker log driver is json-file with no rotation limits configured, so retention is effectively unbounded.

Small today. Not small once the product is hosting other people's private conversations — at which point this is customer content sitting in operator logs.

Proposed fix

Replace the payload preview with metadata only: response keys, segment count, total character count, and the set of speaker labels count (not the labels themselves, since display names are personal data). Then audit the module for any other line that could carry content, and add a test asserting no logging call in audio_service receives segment text.

Scrub the retained production logs for the affected container.

Acceptance criteria

audio_service.py:524-528 logs no response body content
A grep of audio_service.py finds no logging call taking transcript, summary, or segment text
A test asserts the invariant so it cannot regress
Retained production worker logs are scrubbed
Log retention/rotation limits are set on the Docker log driver

**Severity: MEDIUM (privacy).** Found in the August 2026 session lifecycle review (#319). ## The defect `audio_service.py:524-528` logs `str(data)[:500]` of the transcription server's response at INFO. That repr opens with the segments array, so the first 500 characters comfortably carry several utterances of real dialogue **together with the speakers' display names**. This directly violates the module's own stated invariant at `audio_service.py:24-25`: > Neither the transcript nor the summary is ever written to logs. Only metadata (char counts, word count, session_id) appears in log lines. The root logger runs at INFO (`webapp/backend/app/logging_config.py`, `configure_logging(log_level="INFO")`), so the line is live in production. ## Scope of the exposure Verified against production: **one matching line** in the worker's retained logs (`docker compose logs --since 720h worker | grep -c "WhisperX raw response"` → 1; backend → 0). So the current exposure is one session's opening dialogue. The Docker log driver is `json-file` with no rotation limits configured, so retention is effectively unbounded. Small today. Not small once the product is hosting other people's private conversations — at which point this is customer content sitting in operator logs. ## Proposed fix Replace the payload preview with metadata only: response keys, segment count, total character count, and the set of speaker labels **count** (not the labels themselves, since display names are personal data). Then audit the module for any other line that could carry content, and add a test asserting no logging call in `audio_service` receives segment text. Scrub the retained production logs for the affected container. ## Acceptance criteria - [ ] `audio_service.py:524-528` logs no response body content - [ ] A grep of `audio_service.py` finds no logging call taking transcript, summary, or segment text - [ ] A test asserts the invariant so it cannot regress - [ ] Retained production worker logs are scrubbed - [ ] Log retention/rotation limits are set on the Docker log driver

claude-bot added this to the v3.11.5 - Recording Clock Hotfix milestone

2026-08-25 20:38:44 +00:00

claude-bot added the

bug

security

backend

labels

2026-08-25 20:38:44 +00:00

rbrooks referenced this issue from a commit

2026-08-25 22:24:18 +00:00

fix(backend): enable VAD, guard the duration invariant, stop logging dialogue (#323, #324, #325)

claude-bot referenced this issue

2026-08-25 22:29:56 +00:00

v3.11.5 — per-speaker recordings never shared a session clock (#320) #418

claude-bot referenced this issue from a commit

2026-08-25 23:11:52 +00:00

Merge PR #418: v3.11.5 — per-speaker recordings never shared a session clock (#320)

claude-bot commented

2026-08-29 07:57:23 +00:00

Author

Collaborator

Shipped — closing as part of a v3.11.5 bookkeeping sweep. This one has no issue-number citation in the code, so verified on its merits rather than by reference.

"Stop writing transcript text to logs" — done. Grepping every logging call in webapp/backend/app and bot/questboard_bot for one that emits a transcript value returns nothing. What remains is counts and lengths (segment counts, word counts, kept-seconds), which is the right side of the line.

"Scrub retained production logs" — moot, and worth saying why rather than just ticking it. Production's backend logs currently reach back only to 2026-08-29T07:06:54, because the container was created at 07:06:30 during the v4.0.1 deploy. Docker logs are per-container and are discarded on recreate, and the stack has been rebuilt several times since 25 August. Nothing from the period this issue was filed about survives to be scrubbed.

That is luck rather than design, though. If retained logs ever need scrubbing again — after a driver change, or on a host shipping logs off-box — the same reasoning will not hold, and the deletion would have to be deliberate.

Shipped — closing as part of a v3.11.5 bookkeeping sweep. This one has no issue-number citation in the code, so verified on its merits rather than by reference. **"Stop writing transcript text to logs" — done.** Grepping every logging call in `webapp/backend/app` and `bot/questboard_bot` for one that emits a transcript value returns nothing. What remains is counts and lengths (segment counts, word counts, kept-seconds), which is the right side of the line. **"Scrub retained production logs" — moot, and worth saying why rather than just ticking it.** Production's backend logs currently reach back only to `2026-08-29T07:06:54`, because the container was created at `07:06:30` during the v4.0.1 deploy. Docker logs are per-container and are discarded on recreate, and the stack has been rebuilt several times since 25 August. Nothing from the period this issue was filed about survives to be scrubbed. That is luck rather than design, though. If retained logs ever need scrubbing again — after a driver change, or on a host shipping logs off-box — the same reasoning will not hold, and the deletion would have to be deliberate.

claude-bot closed this issue

2026-08-29 07:57:53 +00:00