Consent & recording law

What Stalkrr does and does not enforce.

Implementation note (2026-06, v3): The active implementation is the native-Swift app in ../app/ (app/Sources/StalkrrPipeline/{Consent,Redact}.swift). The shipped consent model is Terms-of-Service-based: on first run the operator accepts Terms confirming they have the right to record the people and screens they capture (recorded parties are deemed to have accepted per those Terms). The app therefore does not ship the per-participant prompt / all-party gate / regional engine described below — that stays as reference spec for a stricter future mode. What is shipped: on-device PII redaction of transcript text before any cloud egress (frames are not redacted), and full erase/forget (per-meeting or all data, in-app and via the MCP delete_* tools).

Consent is a first-class, non-optional requirement in Stalkrr — not a feature to add later. Recording meetings and voice calls triggers real legal obligations, and open-sourcing the client earns your user's trust but not the other participants' consent. Done well, respectful consent is also a differentiator: Stalkrr is the one that asks.

Stalkrr is "the transparent surveillance you actually own." Transparency only works if the people in the room know they're in the footage.

The legal surface (why this is table stakes)

• Two-party (all-party) consent laws. Many US states (e.g. California, Florida, Illinois, Pennsylvania, Washington, and others) require every party to a conversation to consent before it is recorded. One-party-consent states require at least one. Stalkrr captures conversations, so it must be able to operate in the strictest (all-party) regime.
• GDPR (EU/EEA/UK). Recording identifiable people processes personal data. This needs a lawful basis, a clear purpose, data-minimization, and honoring data-subject rights (access, erasure, objection). Local-first processing and redaction directly support minimization.
• Sector / regional overlays. Healthcare, finance, education, and specific national laws may add stricter rules. Stalkrr must select the strictest applicable policy for the session.

First-class requirements

These are enforced (or, where stubbed, explicitly asserted) by the consent gate in packages/client/src/consent and the redact stage in packages/client/src/redact.

1. Consent prompt

Capture must not begin until consent has been gathered for the session. The default policy is conservative: capture is permitted only when every resolved participant has explicitly granted consent. The gate returns granted only in that case; otherwise capture is blocked.

2. "This is being captured" disclosure

All participants must receive a clear, timely disclosure that capture is happening — e.g. a join-time notice, an in-meeting banner, or an audio cue — before capture starts. (discloseCapture() is the hook; currently stubbed.)

3. Per-participant opt-out — NOT IMPLEMENTED

Individual participants cannot currently be excluded. There is no UI or API to opt a participant out: transcript speakers are only "me"/"them", the consent gate never blocks anything, and the redact stage drops nobody's speech. Recording is all-party, under the operator's Terms acceptance. A real implementation — speaker diarization plus a per-recording "exclude this speaker" action that removes their lines, scrubs their audio spans, and re-runs extraction — is a planned follow-up; this document will change when it ships.

4. Regional handling

Each session carries a coarse region. The consent gate must map the region (and participants' regions) to the strictest applicable rule set:

• All-party-consent jurisdiction → require all-party granted (the default).
• One-party jurisdiction → may permit with the operating user's consent, subject to product policy.
• GDPR region → ensure lawful basis, disclosure, and data-subject rights; minimize via on-device redaction.

When in doubt, fail closed (treat as the strictest regime).

How the design supports compliance

• Local-first processing minimizes what is collected and where it goes (GDPR data-minimization; keeps raw audio on-device).
• Redaction before extraction masks PII in transcript text before anything is sent to a BYO AI provider; it does not remove any speaker's speech and does not touch screen frames.
• Open source lets anyone verify the above is actually what the code does.
• Provenance. Every Task/Insight records its sourceCaptureId, so stored memory is traceable and can be erased on request.

Status (v3)

Shipped: ToS acceptance gate (first run), on-device PII redaction of transcript text before egress (frames are not redacted), and erase/forget (per-meeting + all-data, in-app and via MCP delete_*). The all-party consent gate, per-participant disclosure UI, and regional policy engine above are reference spec for a stricter opt-in mode — not the shipped model. Per-participant opt-out is not implemented: no participant can be excluded from a recording today; speaker diarization plus a per-recording "exclude this speaker" action is a planned follow-up. None of this is legal advice — operators are responsible for compliance in their jurisdiction.