feat/web-replay
needs attention881397c · incrementalPR #367reviewed 2026-07-31 20:31 UTC2H · 2M · 2L · 1I- Purpose
- Enable PostHog session replay on apps/web (Atlas map + marketing site) to capture user interaction recordings alongside existing apps/platform replay.
- Goal
- Turn on session replay for the public marketing site, gated behind an env var for prod-only activation.
- Sub-goals
- SG-1: Pass sessionReplay prop to PostHogProvider in apps/web layout
- SG-2: Update analytics README to reflect both apps opting in and shared-project implications
- SG-3: Add NEXT_PUBLIC_POSTHOG_SESSION_REPLAY to apps/web README env var list
- What
- Two commits: (1) added sessionReplay to PostHogProvider in apps/web layout.tsx and updated session-replay.ts comment; (2) aligned all README documentation to reflect both apps opting in and documented the shared PostHog project constraint.
- Why
- The Atlas map on the marketing site needed replay telemetry for user navigation patterns; the platform app already had it enabled.
- Areas
- apps/web+11−1packages/analytics+16−7
- Blast
- 5 files, +27/-9 lines across apps/web and packages/analytics. No schema, API, or infrastructure changes.
Findings · 7
security5
Session replay shared between public and authenticated app — no masking guarantee documented
packages/analytics/README.md
Both apps/web (public) and apps/platform (authenticated SaaS) send replay data to the same PostHog project 334265 with shared SessionRecordingRemoteConfig. The README correctly notes settings cannot be overridden per-app, but does not state whether field/input masking or network-request blocking is configured. If masking is not enforced server-side in PostHog, authenticated-app sessions could leak commercially sensitive data (energy consumption, CFE billing, contract values). The correct fix — a separate PostHog project — is noted but remains advisory only.
Public marketing site replay may capture PII without documented consent mechanism
apps/web/src/app/layout.tsx
apps/web is a public site (Atlas map + marketing). Session replay with no documented masking policy records all user interactions including contact forms, email fields, and query parameters that may contain PII. Under LFPDPPP (Mexico) / GDPR, recording user interactions on a public site requires informed consent before replay starts. The diff and surrounding context contain no reference to a consent gate (cookie banner, opt-in check) blocking PostHog replay until consent is granted.
NEXT_PUBLIC_ env var value visible in client bundle — confirms replay is active
apps/web/README.md
NEXT_PUBLIC_POSTHOG_SESSION_REPLAY is statically embedded in the browser JS bundle. Any observer can confirm replay is active on prod and enumerate the PostHog project ID. No secret is exposed, but worth noting alongside the masking/consent concerns.
PostHog project ID 334265 repeated in docs — prod analytics project enumerable
packages/analytics/README.md
The production PostHog project ID is now stated twice in committed documentation. Combined with the phc_ ingest key shipped client-side, a third party could attempt synthetic event injection. Existing exposure amplified by this diff.
No documented data retention or replay deletion policy
packages/analytics/README.md
The README documents the shared-project constraint and env-var gate but nothing about replay retention period, access control in PostHog, or deletion procedures for LFPDPPP Art. 25 / GDPR Art. 17 data subject requests.
conventions1
Multi-line JSX block comment — house style prefers one short line max
apps/web/src/app/layout.tsx
The replacement comment spans four lines. CLAUDE.md says 'no multi-line comment blocks — one short line max.' The env-var gate reason is valid to keep; the 'see packages/analytics/README.md' pointer could be trimmed. Non-blocking.
improvement1
Documentation-only diff — no logic changes to evaluate
All three changed files are READMEs or JSX comments. The documentation is coherent and consistent across the files.