Skip to content

OBS-001A — Remove personal data and session replay from current monitoring and logs #111

Closed

Description

@daliu

Officer impact: None — member and officer screens/tasks are unchanged; this tracker removes or proves containment of diagnostic payloads.

Officer documentation: None — no officer procedure, navigation, permission, collected field, deployment duty, or external account changed. Engineering evidence is in SECURITY.md and OPERATIONS_RUNBOOK.md.

Deployment evidence: Closure records source/tests/merge separately from website publication, exact runmprc.com, Firebase deployment, outside-provider configuration, and live behavior. Source completion does not prove any production surface.

Problem

Current source sent a signed-in user's email to Sentry user context, enabled Sentry replay for every captured error, and logged the raw signup email in functions/signup.js. Authentication, member, event, registration, payment, and account screens can contain personal data or capability-bearing URL state. Firebase Analytics was also enabled without a repository-proven event allowlist, consent decision, payload audit, or retention decision.

This created avoidable exposure to logs and monitoring vendors even when the underlying feature worked correctly.

Atomic outcome

Make the existing frontend monitoring, analytics wrapper, Auth signup logging, and covered browser diagnostics fail closed for personal data, with synthetic tests that inspect the emitted payloads. This issue removes current exposure; it does not build the broader payment metrics/SLO program or approve future telemetry.

Scope

  • Remove raw email and other direct member identifiers from Sentry user context.
  • Disable Sentry session replay, tracing, client reports, default PII, breadcrumbs, attachments, transactions, and unapproved integrations.
  • Positively project only bounded Sentry error metadata; drop query strings, fragments, form values, provider responses, tokens, addresses, DOB, emergency contacts, emails, phones, request bodies, and unknown fields.
  • Replace raw signup email/error logging with one fixed failure outcome and prove success silence plus failure redaction across standard console levels.
  • Remove Firebase Analytics runtime initialization/emission and keep the compatibility wrapper transport-free.
  • Route the covered browser console failures through a closed five-outcome helper.
  • Add focused synthetic tests that fail if representative sensitive values reach Sentry, Analytics, signup logs, or covered browser diagnostics.
  • Document the residual production/provider decisions that require the approved matrix from DATA-001B — Inventory personal data and approve a minimization/retention matrix #110.

Acceptance criteria

  • No raw email, phone, address, DOB, emergency contact, OAuth/Auth token, provider response, password/reset material, capability-bearing query/fragment, arbitrary form value, or request body is sent by the covered code.
  • Sentry replay is off, or sensitive-route exclusion and masking are verified by payload inspection with no form text or URL state visible.
  • Signup success/failure logs contain only allowlisted event/result identifiers and sanitized codes.
  • Analytics accepts only documented low-cardinality event names/parameters and rejects or drops unknown/sensitive fields.
  • Synthetic canary values are absent from captured Sentry events/replays, Analytics calls, console/function logs, test artifacts, and CI output.
  • Local and CI tests make no production network calls and use synthetic identities only.
  • External Sentry/Firebase retention, consent, access, and deletion configuration remains explicitly unproven until owner evidence is supplied under DATA-001B — Inventory personal data and approve a minimization/retention matrix #110.

Completed atomic children

Dependencies and coordination

Explicitly out of scope

  • Adding new analytics, advertising, fingerprinting, or replay vendors.
  • Designing dashboards, payment metrics, alerts, or incident response.
  • Changing membership authority, OAuth scopes, Firestore authorization, data retention jobs, or the public privacy policy.
  • Enabling monitoring in local/test or contacting live services from tests.

Claim protocol

Creation is not a claim. Do not edit files until dependencies are complete, the issue is assigned, and a timestamped CLAIMED by <canonical agent> at <UTC>; branch <branch> comment is posted and re-read. Earliest valid claim wins.

Activity

  1. added
    priority:P1High-priority follow-up
    type:securitySecurity or privacy boundary
    area:firebaseFirebase services and data
    area:webWeb application and hosting
    size:SSmall focused issue
    status:proposedDesigned but dependencies or decisions remain
    area:privacyPersonal data, consent, minimization, retention, and privacy operations
    on Jul 12, 2026
  2. daliu commented on Jul 13, 2026

    @daliu
    ContributorAuthor

    OWNERSHIP COORDINATION from #99 at 2026-07-13T07:23:07Z (not a claim): #99 must preserve query/fragment state for Pages callbacks. It retains only a fail-closed startup guard that skips Sentry initialization when the initial URL is /account/strava/callback, /register/success, or /shop/purchase/success with query/fragment state.\n\nReason: the bridge restores capability state before initSentry runs, so merging the bridge alone could newly expose that URL to monitoring/replay. #111 continues to own the complete hosted telemetry outcome: general URL/event/log redaction, already-initialized SPA transitions, replay/consent/retention policy, payload inspection, and provider evidence. The narrow #99 guard may be replaced by #111 after equivalent or stronger scrubbing is proven.

  3. daliu commented on Jul 13, 2026

    @daliu
    ContributorAuthor

    IMPLEMENTATION SPLIT / OVERLAP RESOLUTION (2026-07-13) — planning update, not a claim on the parent.

    #111 spans three independently testable runtimes and cannot be safely reviewed as one focused pull request:

    #118 also temporarily owns root SECURITY.md / OPERATIONS_RUNBOOK.md hunks. #134 may implement and test only its two Sentry paths until #118 merges and explicitly releases those docs. #101 Stripe webhook hunks and #88 Strava provider behavior remain excluded.

  4. daliu commented on Jul 13, 2026

    @daliu
    ContributorAuthor

    Atomic-child status update

    Parent #111 stays open/proposed. #139 removes current unapproved collection without inventing a consent/retention policy; #110 still gates any future Analytics enablement and any closed event/parameter schema.

  5. daliu commented on Jul 13, 2026

    @daliu
    ContributorAuthor

    OBS-001A2 source outcome is complete without overlapping #118 or #101.

    #111 remains open for any separately bounded, dependency-cleared privacy work. #110 remains the policy owner for any future telemetry purpose, consent, schema, retention, access, or deletion decision. The #139 source/test/doc claim is released.

  6. added
    status:in-progressClaimed and actively being implemented
    and removed
    status:proposedDesigned but dependencies or decisions remain
    on Jul 13, 2026
  7. self-assigned this
    on Jul 13, 2026
  8. 7 remaining items

  9. removed
    status:proposedDesigned but dependencies or decisions remain
    on Jul 13, 2026
  10. self-assigned this
    on Jul 13, 2026
  11. daliu commented on Jul 13, 2026

    @daliu
    ContributorAuthor

    CLAIMED by Codex agent /root at 2026-07-13T11:13:16Z; branch codex/issue-111-closure-audit.

    This is a second read-only source/acceptance/closure audit on exact main f2caaae3b3f25adfd4fc552008871408f18e5931, after residual child #142 joined completed children #118, #134, and #139. No runtime or documentation file is claimed or may be edited. I will verify each parent acceptance criterion against merged source/tests and child evidence, distinguish source from every deployment/provider surface, and either close the tracker with exact proof or release it with a narrowly stated residual blocker. Any newer conflicting claim is a stop-and-coordinate condition.

  12. daliu commented on Jul 13, 2026

    @daliu
    ContributorAuthor

    PARENT SOURCE AUDIT COMPLETE — 2026-07-13

    Completed atomic source boundaries:

    The source acceptance audit now finds no covered raw email/phone/address/token/provider/form/request payload flowing to Sentry, Firebase Analytics, signup logs, or the four audited browser console paths. Tests use synthetic canaries and no production provider calls.

    Deployment/provider boundary: no exact website revision was published or verified on runmprc.com; Sentry/Firebase provider configuration, transport, historical data/cookies, retention, consent, access, deletion, and live behavior remain unproven and owner-controlled under #110. Closing this source tracker does not approve or re-enable analytics/replay.

  13. reopened this on Jul 13, 2026
  14. daliu commented on Jul 13, 2026

    @daliu
    ContributorAuthor

    CORRECTION — reopening after the second independent closure audit found one remaining proof gap.

    Exact source f2caaae3b3f25adfd4fc552008871408f18e5931 is fail-closed by inspection: functions/signup.js ignores the caught object, emits one fixed phrase on failure, emits nothing on success, and returns a generic error. However, parent acceptance criterion 5 requires synthetic canary evidence for the covered signup/function log sink. Existing signup tests exercise only successful create/preserve behavior; no test makes profile creation reject and inspects the resulting console arguments.

    The earlier closure comment therefore overstates test coverage. #111 is reopened with its existing /root audit claim retained. I will split one test-only child that owns only the minimum Functions test path, after checking live claims. Runtime signup code, #118 behavior, Sentry, Analytics, frontend diagnostics, Stripe, Strava, Rules, providers, production data, and root documents remain immutable. No human policy decision is required.

    All source-vs-deployment caveats remain unchanged: website publication, exact runmprc.com, Firebase deployment, provider settings/history/cookies, and live behavior are unproven.

  15. daliu commented on Jul 13, 2026

    @daliu
    ContributorAuthor

    Residual signup-log proof is split into #146 and validly claimed by /root on codex/issue-146-signup-log-test from exact base f2caaae3b3f25adfd4fc552008871408f18e5931.

    The child owns only functions/ensureMemberProfile.test.js. It will add hostile-canary failure-log and no-success-log assertions without touching functions/signup.js or any other runtime/documentation path. #145's frontend/Auth-mail paths do not overlap. Parent #111 remains open/in progress until #146 merges and the final audit is rerun.

  16. reopened this on Jul 13, 2026
  17. daliu commented on Jul 13, 2026

    @daliu
    ContributorAuthor

    AUTOMATION CORRECTION — PR #147's merge sentence matched GitHub's issue-closing parser and auto-closed #111 at 2026-07-13T11:24:54Z before the final parent checklist/evidence update.

    Reopening the tracker briefly with the existing /root read-only claim retained. Exact main is now 8d250073d8911d42031fa694c8c0e784911461b0; #146 and exact-merge CI 29246166838 are complete. No runtime or documentation file is claimed. Two independent auditors will confirm the full #118/#134/#139/#142/#146 acceptance chain before the intentional close.

    All deployment/provider caveats remain unchanged and unproven.

  18. daliu commented on Jul 13, 2026

    @daliu
    ContributorAuthor

    INTENTIONAL FINAL CLOSURE — all seven acceptance criteria pass on exact main 8d250073d8911d42031fa694c8c0e784911461b0.

    Completed source chain:

    Two independent final read-only audits approved the complete range. Sentry keeps only a strict bounded error projection with replay/tracing/sessions/client reports/default PII/breadcrumbs/attachments/transactions disabled. Analytics has no runtime transport and reads no inputs. Covered browser diagnostics accept only five fixed outcomes. Signup success is silent across debug, error, info, log, and warn; hostile failure emits exactly one fixed one-argument error and returns only the generic internal response. Synthetic canaries cover email, phone, address, DOB, emergency contact, UID/name, Auth/OAuth/reset/capability tokens, provider responses, form/request data, URL query/fragment state, and stacks. Exact CI logs contain none of the searched canaries.

    Deployment truth:

    #110 remains the policy owner. Closing #111 does not approve or re-enable telemetry; any future implementation requires a new claimed/reviewed issue. #88 Strava and unrelated legacy Functions remain excluded.

    Officer impact: None — member and officer tasks/screens are unchanged.

    Officer documentation: None — no officer procedure changed; engineering evidence remains in SECURITY.md and OPERATIONS_RUNBOOK.md.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:firebaseFirebase services and dataarea: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

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions