Alert webhooks POST a raw unredacted transcript snippet to a third-party Discord channel #85

New Issue

2026-08-28T02:52:22-04:00

logan commented

2026-08-28 02:52:22 -04:00

Found during the Gate B3 scoping pass (#43), unattended run 2026-08-28. Searched open and closed first: #43 covers the redaction design and #48 covers entity-name accuracy; neither describes this surface and neither ships before 2026-09-30. This is the live leg, and it is leaving the building today.

What happens

drb-c2-core/app/internal/alerter.py writes a raw 200-character transcript_snippet into the alert_events document and POSTs the same text to the customer's own Discord webhook. No redaction of any kind is applied.

Board minutes #42 ratified that person names are suppressed on every surface until E&O is bound. A webhook POST to a third-party service is the least recoverable surface we have: once it is in a Discord channel we do not control it, cannot unsend it, and cannot audit who read it.

Why this is separate from #43

#43 is a 2026-09-30 deliverable that needs a per-talkgroup flag, a new data model, and a redactor built from scratch (the extraction prompt carries no person-name field — see the scoping comment on #43). That is 6-10 engineering-days.

This one does not need any of it. The snippet is a convenience field. It can be truncated to nothing, or dropped from the webhook payload entirely, without waiting for the redactor to exist. Alerting keeps working; the alert says an incident matched and links to it.

Why it is not urgent-in-practice today, and why that will change

Today the only consumers are the owner and the comped friends-and-family tier, so the blast radius is people who already have full access. It becomes a real exposure the moment the first outside operator is given alerting — which is the sellable path, so it is on the critical line to revenue rather than off to one side.

It also interacts with the open owner ruling on #43: whether comped access to unredacted names is paused today or knowingly left in breach until 2026-09-30. If the answer is "paused", this is in scope of that pause and is the first thing that has to change.

What done looks like

The webhook payload carries no raw transcript text, or carries it only when the org has explicitly opted in under contract.
alert_events either stores no raw snippet or stores it in a field the Firestore rules do not expose to browser reads.
A test that asserts the outbound payload contains no transcript text by default.

Refs #43, #48, #42, #45.

Found during the Gate B3 scoping pass (#43), unattended run 2026-08-28. Searched open and closed first: #43 covers the redaction *design* and #48 covers entity-name *accuracy*; neither describes this surface and neither ships before 2026-09-30. This is the live leg, and it is leaving the building today. ## What happens `drb-c2-core/app/internal/alerter.py` writes a raw 200-character `transcript_snippet` into the `alert_events` document and POSTs the same text to the **customer's own Discord webhook**. No redaction of any kind is applied. Board minutes #42 ratified that person names are suppressed on **every** surface until E&O is bound. A webhook POST to a third-party service is the least recoverable surface we have: once it is in a Discord channel we do not control it, cannot unsend it, and cannot audit who read it. ## Why this is separate from #43 #43 is a 2026-09-30 deliverable that needs a per-talkgroup flag, a new data model, and a redactor built from scratch (the extraction prompt carries no person-name field — see the scoping comment on #43). That is 6-10 engineering-days. This one does not need any of it. The snippet is a convenience field. It can be **truncated to nothing, or dropped from the webhook payload entirely**, without waiting for the redactor to exist. Alerting keeps working; the alert says an incident matched and links to it. ## Why it is not urgent-in-practice today, and why that will change Today the only consumers are the owner and the comped friends-and-family tier, so the blast radius is people who already have full access. It becomes a real exposure the moment the first outside operator is given alerting — which is the sellable path, so it is on the critical line to revenue rather than off to one side. It also interacts with the open owner ruling on #43: whether comped access to unredacted names is paused today or knowingly left in breach until 2026-09-30. If the answer is "paused", this is in scope of that pause and is the first thing that has to change. ## What done looks like - The webhook payload carries no raw transcript text, or carries it only when the org has explicitly opted in under contract. - `alert_events` either stores no raw snippet or stores it in a field the Firestore rules do not expose to browser reads. - A test that asserts the outbound payload contains no transcript text by default. Refs #43, #48, #42, #45.

logan referenced this issue from a commit

2026-08-28 03:09:44 -04:00

Scope Gate B3 so the owner can stop being blocked on it (server-26#43)

logan commented

2026-08-29 02:45:01 -04:00

Fixed and pushed — commit 0635de8, unattended run 2026-08-29.

Raw transcript text now requires two independent gates, both closed by default:

an operator switch set from the environment, and
an explicit per-org opt-in on the organization document.

The operator switch is not redundant with the org flag. The frontend reads and writes Firestore directly from the browser, so consent alone would have let an org owner opt themselves into receiving person names lifted from live public-safety traffic. Capability is the operator's to grant; consent is the org's to give. Both, or nothing.

The gate fails closed on a Firestore read error and on a call with no org — a pre-tenancy node that has not been through the backfill. A less informative alert is cheap; an unrecallable disclosure to a third party is not.

Alerting itself is unchanged. The webhook still fires and still carries the rule name, the talkgroup and the matched keywords — only the transcript text is withheld. Both surfaces named in this issue are covered: the outbound POST and the alert_events document, which the browser reads directly.

Seven tests assert that a person name present in a sample transcript appears in neither the outbound payload nor the Firestore write, across every combination of the two gates, plus the two fail-closed paths. Full suite: 273 passed.

This did not wait on #43. As this issue argued, the snippet was a convenience field and needed no redactor in order to be withheld — so the live leg is closed today rather than on 2026-09-30.

Still open and unaffected: #43 (the Gate B3 redactor proper) and #48 (entity-name accuracy). The owner ruling referenced here — whether comped access to unredacted names is paused today or knowingly left in breach until 2026-09-30 — is still outstanding on #43. This change removes the third-party leg of that question but not the question.

**Fixed and pushed — commit `0635de8`, unattended run 2026-08-29.** Raw transcript text now requires two independent gates, both closed by default: 1. an operator switch set from the environment, and 2. an explicit per-org opt-in on the organization document. The operator switch is not redundant with the org flag. The frontend reads and writes Firestore directly from the browser, so consent alone would have let an org owner opt *themselves* into receiving person names lifted from live public-safety traffic. Capability is the operator's to grant; consent is the org's to give. Both, or nothing. The gate fails **closed** on a Firestore read error and on a call with no org — a pre-tenancy node that has not been through the backfill. A less informative alert is cheap; an unrecallable disclosure to a third party is not. Alerting itself is unchanged. The webhook still fires and still carries the rule name, the talkgroup and the matched keywords — only the transcript text is withheld. Both surfaces named in this issue are covered: the outbound POST **and** the `alert_events` document, which the browser reads directly. Seven tests assert that a person name present in a sample transcript appears in neither the outbound payload nor the Firestore write, across every combination of the two gates, plus the two fail-closed paths. Full suite: **273 passed**. This did not wait on #43. As this issue argued, the snippet was a convenience field and needed no redactor in order to be withheld — so the live leg is closed today rather than on 2026-09-30. **Still open and unaffected:** #43 (the Gate B3 redactor proper) and #48 (entity-name accuracy). The owner ruling referenced here — whether comped access to unredacted names is paused today or knowingly left in breach until 2026-09-30 — is still outstanding on #43. This change removes the third-party leg of that question but not the question.

logan referenced this issue

2026-08-29 02:45:01 -04:00

Gate A: awaiting owner sign-off to close - public price (a1bdccf) and the A2 disclaimer (b722223) are both shipped and live #46

logan closed this issue

2026-08-29 02:45:09 -04:00

logan added the area/discord area/legal

type

security

labels 2026-10-05 02:04:40 -04:00

logan referenced this issue

2026-10-05 02:08:37 -04:00

Map: geofenced watch zones / protected sites — alert rules with geometry, evaluated on incidents #241