Skip to content

OBS-001A1 — Disable Sentry replay and fail closed for personal data #134

Closed
Closed
OBS-001A1 — Disable Sentry replay and fail closed for personal data#134
Assignees
daliu
Labels
area:privacyPersonal data, consent, minimization, retention, and privacy operationsarea:webWeb application and hostingpriority:P1High-priority follow-upsize:SSmall focused issuetype:securitySecurity or privacy boundary

Description

@daliu
daliu
opened on Jul 13, 2026

Officer impact: None — this removes sensitive telemetry exposure without changing an officer or member procedure.

Officer documentation: None — no officer task, navigation, permission, collected field, or provider-console procedure changes. Engineering security/operations documentation must be updated only after #118 releases its current root-document claims.

Deployment evidence: Closure must distinguish source/tests/merge, website publication, exact runmprc.com release, and Sentry provider configuration. A green build does not prove Sentry retention, access, consent, or deletion settings.

Problem

The hosted frontend currently attaches a signed-in member's email and UID to Sentry, configures error-triggered session replay, and has no fail-closed payload filter. Error messages, request URL state, breadcrumbs, form values, provider responses, and arbitrary extras can contain personal data or capability-bearing tokens.

Invariant

No Sentry event emitted by this code may contain a direct member identifier, form/request body, query string, fragment, breadcrumb, arbitrary extra/context value, provider response, or raw error message. Session replay remains disabled until a separately approved privacy configuration exists.

Atomic outcome

Disable replay, remove member user context, and install a small allowlist-based beforeSend sanitizer with synthetic payload tests. Preserve useful generic error type, safe stack location data, and strictly validated non-content event metadata only.

Exact implementation boundary

Do not edit functions/signup.js, Analytics, capabilityCallback.ts, Auth/profile code, Firestore Rules, provider configuration, or #118 paths. #118 separately owns the Auth-signup logging outcome pending merge/deploy.

Acceptance criteria

  • Both session and error replay are disabled; no Replay integration or nonzero replay sample rate is configured.
  • setUserContext sends no UID, email, phone, or other member identifier.
  • beforeSend returns only documented generic diagnostics and strictly validated non-content event metadata and drops user/request data, query/fragment state, breadcrumbs, arbitrary tags/extras/contexts, raw messages, and unsafe stack-frame values/source context.
  • Synthetic canaries representing email, phone, address, DOB, emergency contact, OAuth/Auth token, password/reset material, provider response, form value, request body, and capability URL are absent from serialized sanitized events.
  • Existing callback-startup isolation remains unchanged and tested.
  • Tests initialize only the mocked Sentry client and make no network/provider calls.
  • External Sentry retention, access, consent, and deletion configuration remains explicitly unproven under DATA-001B — Inventory personal data and approve a minimization/retention matrix #110.

Dependencies and coordination

Claim protocol

Creation is not a claim. Before editing, assign this issue, add status:in-progress, post CLAIMED by <canonical agent> at <UTC>; branch <branch>, and re-read comments. The earliest valid claim wins.

Activity

  1. daliu
    added
    priority:P1High-priority follow-up
    type:securitySecurity or privacy boundary
    area:webWeb application and hosting
    size:SSmall focused issue
    status:readyDependencies complete and ready to claim
    area:privacyPersonal data, consent, minimization, retention, and privacy operations
    on Jul 13, 2026
  2. daliu
    self-assigned this
    on Jul 13, 2026

  3. daliu commented on Jul 13, 2026

    @daliu
    daliu
    on Jul 13, 2026
    ContributorAuthor

    CLAIMED by Codex agent /root at 2026-07-13T08:48:34Z; branch codex/issue-134-sentry-redaction.

    Exclusive implementation paths: src/services/monitoring/sentry.ts and src/services/monitoring/sentry.test.ts. I will use an isolated worktree from refreshed origin/main, preserve #99 callback isolation, and make no production/provider calls.

    STOP boundaries: #118 owns functions/signup.js, profile/Auth paths, and current SECURITY.md / OPERATIONS_RUNBOOK.md hunks until explicit release. Analytics, Firestore Rules, Stripe/webhook, Strava, sitemap, shared dirty-worktree files, and external Sentry settings are excluded. Documentation will wait for #118's released merge base.

  4. daliu
    added
    status:in-progressClaimed and actively being implemented
    and removed
    status:readyDependencies complete and ready to claim
    on Jul 13, 2026

  5. daliu commented on Jul 13, 2026

    @daliu
    daliu
    on Jul 13, 2026
    ContributorAuthor

    Implementation progress — CLAIM RETAINED / NOT COMPLETE

    • Draft PR: OBS-001A1: fail closed for Sentry personal data #137
    • Exact pushed source commit: 0ea0fcbe118a1a465648b7380f0757e81d99e41f
    • Code scope remains limited to src/services/monitoring/sentry.ts and its focused test.
    • Node 20 local evidence: focused 17/17, complete frontend 52/52, SPA callback 10/10, changed-file lint, production diagnostic build, and diff check all passed.
    • Three independent reviews found no blocking defect on the exact source diff.

    The PR intentionally remains draft. #118 still owns SECURITY.md and OPERATIONS_RUNBOOK.md; after that owner explicitly releases the files, this branch must refresh from current main, add truthful source/provider-status documentation, rerun the full relevant checks, and only then become mergeable.

    No Sentry Console setting, provider retention/access policy, production transport, or live payload behavior has been inspected or changed. Those outside-provider controls remain unproven and are not implied by the source tests.

  6. daliu commented on Jul 13, 2026

    @daliu
    daliu
    on Jul 13, 2026
    ContributorAuthor

    DEPENDENCY / DOC OWNERSHIP RELEASE at 2026-07-13T10:08Z

    #118 source merged through PR #132 as exact main 13ccc1b67dd57f69091e808b12e1287a1bc05b2f. Exact post-merge CI run 29241524287 is green, and the merge triggered CI only: no Firebase, Pages, Netlify production, or provider deployment occurred.

    SECURITY.md and OPERATIONS_RUNBOOK.md are now released to #134 after a controlled refresh to that exact main. Preserve:

    The two Sentry runtime files remain #134-owned.

  7. daliu commented on Jul 13, 2026

    @daliu
    daliu
    on Jul 13, 2026
    ContributorAuthor

    COMPLETE — source boundary merged; production behavior remains unproven

    OBS-001A1 is complete as the focused source outcome.

    • PR OBS-001A1: fail closed for Sentry personal data #137 was admin-squash-merged as exact main commit a925dbdada35b6d7ceb28f6ba2b10cc5679c9634 after branch protection correctly required an outside approval.
    • Exact final PR head a0c9065635046c948f1ba92fdf1fe8175b693c40 had diff SHA-256 7aa64a7636e9257f457002978d6783747c2e459abbce477652df77efa6cd24ee.
    • Two independent final-head reviews approved after their findings were fixed. Those fixes include bounded indexed projection for untrusted exception/frame arrays and an immutable attachment-free hint that closes Sentry's post-beforeSend attachment reread race.
    • Node 20 local proof: focused Sentry 19/19, complete frontend 69/69, callback plus protected-release gates 23/23, strict changed-file ESLint, diagnostic build, and diff check passed.
    • Exact-head PR CI run 29242490328 passed frontend, Functions, and Rules. Exact-merge post-merge CI run 29242595272 passed the same three hosted jobs.

    Deployment evidence

    • Source: merged on main at a925dbdada35b6d7ceb28f6ba2b10cc5679c9634.
    • Tests: passed locally, on the exact PR head, and on the exact merge.
    • Website: NOT PUBLISHED / NOT VERIFIED. The PR had an exact-head Netlify preview, but the merge has no Netlify production status and CI-001B2 — Make releases protected, backend-first, and fail-closed #135 intentionally pauses production Git builds.
    • runmprc.com: NOT VERIFIED at this revision.
    • Firebase: no backend file changed and no Firebase deployment ran.
    • Sentry/provider: no provider setting, transport payload, IP handling, retention, access, consent, deletion, or vendor term was inspected or changed. Production behavior is NOT VERIFIED and remains under DATA-001B — Inventory personal data and approve a minimization/retention matrix #110 plus the protected release/website work.

    The merge triggered only the CI workflow; no protected release, Pages, or Firebase workflow ran. Source completion therefore does not claim live containment.

    Officer impact: None — no officer/member procedure, navigation, permission, or collected field changed.

    Officer documentation: None — internal engineering boundaries were updated in SECURITY.md and OPERATIONS_RUNBOOK.md; no officer task changed.

    Parent #111 retains the separate Firebase Analytics outcome. Claim released for src/services/monitoring/sentry.ts, src/services/monitoring/sentry.test.ts, and the two narrow engineering-document hunks.

  8. daliu
    removed
    status:in-progressClaimed and actively being implemented
    on Jul 13, 2026
  9. daliu
    closed this as completedon Jul 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:privacyPersonal data, consent, minimization, retention, and privacy operationsarea:webWeb application and hostingpriority:P1High-priority follow-upsize:SSmall focused issuetype:securitySecurity or privacy boundary

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions