Support Sourcepoint GPP consent for EC generation

[ChristianPavilonis]

Summary

• Add client-side Sourcepoint JS integration that auto-discovers _sp_user_consent_* from localStorage and mirrors GPP consent into __gpp / __gpp_sid cookies
• Extend server-side GPP decoding to extract sale_opt_out from US GPP sections (IDs 7–23)
• Add GPP US consent branch to allows_ec_creation() between existing TCF and us_privacy checks

Closes #640

Test plan

• Rust tests pass (cargo test --workspace — 992 tests including 8 new)
• JS tests pass (npx vitest run — 288 tests including 6 new)
• Clippy clean
• Verify EC generation succeeds for a Sourcepoint-only site in a regulated US state with GPP consent present
• Verify GPC still blocks EC when GPP US section is permissive
• Verify existing TCF and us_privacy EC gating behavior unchanged

🤖 Generated with Claude Code

[aram356]

Summary

Follow-up review focused on areas not covered in the prior pass. Sourcepoint flow (mirror + GPP US decoding + EC gating) is functional and well-tested, but two doc/file-stale issues from the scoping commit (8a6df3af) need correction before merge, and the always-shipped Sourcepoint module has cross-CMP failure modes worth designing around.

PR effective scope note: vs main the diff is 80 commits / 111 files, because the intended base (feature/edge-cookies-final) has merged. The Sourcepoint-specific changes are a small subset (~14 files); reviewers landing on this PR via GitHub should read the description with that in mind.

Blocking

🔧 wrench

• Stale Prebid User ID docs reference removed TSJS_PREBID_USER_IDS env var (docs/guide/integrations/prebid.md:226-261)
• _user_ids.generated.ts claims to be auto-generated but is now hand-edited (crates/js/lib/src/integrations/prebid/_user_ids.generated.ts:1)

Non-blocking

🤔 thinking

• Sourcepoint hardcoded as always-shipped will clobber __gpp set by other CMPs (registry.rs:792 + sourcepoint/index.ts:60-72)
• First page load race: mirror runs before Sourcepoint CMP populates localStorage (sourcepoint/index.ts:91-93)
• TCF presence silently overrides explicit GPP US sale_opt_out=Yes in US states (consent/mod.rs:506-515)
• Session-scoped cookie + run-once mirror leaves stale __gpp after mid-session retraction (sourcepoint/index.ts:39)

♻️ refactor

• Stale comment displaced by us_sale_opt_out insertion (consent/gpp.rs:74-75)
• Make clearing logic CMP-safe by tracking write source (sourcepoint/index.ts:42-46)

⛏ nitpick

• Unused/inconsistent default export (sourcepoint/index.ts:95)

CI Status

• fmt: PASS
• clippy: PASS
• rust tests: PASS (1001 lib + 21 misc)
• js tests: PASS (294)

[aram356]

🔧 wrench — Stale Prebid User ID docs reference a removed env var.

The "Scope Sourcepoint consent PR" commit (8a6df3af) removed generatePrebidUserIds() from build-all.mjs along with the Prebid User ID design/plan docs. But this guide still claims:

• L233: "controlled by TSJS_PREBID_USER_IDS at build time and emitted into _user_ids.generated.ts"
• L247–250: examples of slim builds via the env var
• L253: "build-all.mjs validates that each exists … and generates _user_ids.generated.ts"
• L256: claims a liveIntentIdSystem denylist exists

None of this is true after the scoping commit. The env var is silently ignored. Operators will set it expecting a slim build and ship the full bundle instead.

Fix: delete the "User ID Modules" section (or at least the env var subsections + denylist warning), keeping only what's accurate post-scoping. If the build-time configurability is meant to come back, hold these docs until the generator returns.

[aram356]

🔧 wrench — File header claims it is auto-generated, but it is not.

// Auto-generated by build-all.mjs — manual edits will be overwritten at build time.

The 8a6df3af scoping commit removed generatePrebidUserIds() from build-all.mjs. This file is now hand-edited but still warns future contributors that their edits will be overwritten — which will either discourage edits or cause confusion when the rebuild does not in fact overwrite them.

Fix: either (a) restore the generator in build-all.mjs (preferred, since the doc still pitches TSJS_PREBID_USER_IDS as a feature), or (b) rename to _user_ids.ts and replace the header with a static-file comment that documents the curated default and the rationale for liveIntentIdSystem exclusion.

[aram356]

🤔 thinking — Sourcepoint hardcoded as always-shipped will clobber __gpp/__gpp_sid set by other CMPs.

const JS_ALWAYS: &[&str] = &["creative", "sourcepoint"];

Every Trusted Server deployment ships and auto-runs the Sourcepoint module on every page load — regardless of which CMP the publisher uses. When no _sp_user_consent_* localStorage entry is found, the module unconditionally clears __gpp and __gpp_sid cookies (see crates/js/lib/src/integrations/sourcepoint/index.ts:60-72). Publishers using OneTrust, Didomi, or any CMP that writes __gpp directly to cookies (allowed by the GPP spec) will have those cookies erased on every page load.

The design doc says "same pattern as creative," but creative is universally applicable while sourcepoint is publisher-CMP-specific.

Suggested fixes:

• (a) Make sourcepoint opt-in via [integrations.sourcepoint] enabled = true with a small Rust IntegrationRegistration whose only job is to gate JS inclusion.
• (b) Only clear cookies the module previously wrote — track via a marker (e.g. _ts_gpp_src=sp) written alongside __gpp and check it before clearing.

[aram356]

🤔 thinking — First page load race: mirror runs at script load before Sourcepoint CMP populates localStorage.

The integration runs once at script load and is included in the immediate (synchronous) bundle. If the bundle loads in <head> before Sourcepoint's CMP script populates _sp_user_consent_*, the mirror reads empty localStorage, writes Max-Age=0 clearing cookies for __gpp/__gpp_sid, and gives up.

Combined with allows_ec_creation fail-closed for UsState with no signals (consent/mod.rs:520-523), users in regulated US states get EC blocked on first page load even though Sourcepoint is properly installed.

The design spec ("integration runs once — no polling or event listeners") acknowledges this but underestimates the impact for first-time visitors.

Suggested fixes:

• Register sourcepoint with with_deferred_js() so it loads after the CMP.
• Listen for Sourcepoint's __sp__ consent-ready event.
• Retry once on DOMContentLoaded / short timer when initial scan finds nothing.

[aram356]

🤔 thinking — TCF presence silently overrides explicit GPP US sale_opt_out=Yes in US states.

if let Some(tcf) = effective_tcf(ctx) {
    return tcf.has_storage_consent();
}
// Check GPP US section for sale opt-out.

In Jurisdiction::UsState, effective_tcf(ctx) short-circuits with tcf.has_storage_consent() and never falls through to the GPP US opt-out check. The test ec_us_state_tcf_takes_priority_over_gpp_us (L1228) asserts this is intentional.

It is defensible if you treat TCF Purpose 1 as the authoritative storage opt-in for the EC cookie itself — but the user has explicitly told the CMP "don't sell my info" via the GPP US section, and EC is itself a tracking identifier. Some CMPs (Didomi, Sourcepoint) will write both sections in the US for spec compliance. The current precedence may surprise privacy-counsel reviewers.

Suggested fixes:

• Document this precedence decision explicitly in docs/superpowers/specs/2026-04-15-sourcepoint-gpp-consent-design.md (currently silent on the conflict).
• Add a config knob: consent.us_tcf_priority = strict|permissive so publishers in stricter regimes can opt into US-section-wins behavior.

[aram356]

🤔 thinking — Session-scoped cookie + run-once mirror leaves stale __gpp after mid-session retraction.

document.cookie = `${name}=${value}; path=/; Secure; SameSite=Lax`;

writeCookie deliberately omits Max-Age (per spec). Combined with "runs once on script load," if the user retracts consent mid-session via the Sourcepoint CMP UI, the localStorage entry updates but __gpp does not refresh until the next full page navigation. Subsequent same-tab requests read stale consent.

Suggested fix: hook Sourcepoint's onConsentUpdate callback or rerun the mirror on visibilitychange so the cookie tracks localStorage within a session.

[aram356]

♻️ refactor — Stale comment displaced by us_sale_opt_out insertion.

// The GPP header version is always 1 for current spec.
let us_sale_opt_out = decode_us_sale_opt_out(&parsed);

The comment was originally above version: 1 inside the struct literal, but the new us_sale_opt_out line was inserted between them. It now reads as if it documents us_sale_opt_out.

Fix: move the comment back next to version: 1, in the struct literal, or delete it — version: 1 is self-documenting.

[aram356]

♻️ refactor — Make the clearing logic CMP-safe by tracking write source.

If finding #3 (always-shipped sourcepoint) cannot be addressed in this PR, at least make the clearing safe in mixed-CMP scenarios:

1. On writeCookie, also write a marker cookie: _ts_gpp_src=sp; path=/; Secure; SameSite=Lax.
2. In clearCookie, check document.cookie for _ts_gpp_src=sp and skip clearing if absent.

This way, a publisher using a different CMP that happens to ship this module will not have their CMP's __gpp cookies clobbered.

[aram356]

⛏ nitpick — Unused/inconsistent default export.

export default mirrorSourcepointConsent;

Nothing imports the default — the module self-initializes via if (typeof window !== 'undefined') at L91-93, and tests use the named export. No other Trusted Server integration exports a default. Drop it for consistency.