Problem
crates/trusted-server-core/src/ec/prebid_eids.rs exposes three pub functions that write EID-derived partner IDs into the KV identity graph with no consent gating at all:
ingest_eid_cookiesingest_prebid_eidsingest_sharedid_cookie
All three funnel through ingest_eid_cookies_with_writer, which calls collect_eid_updates(...) directly and hands the result to a PartnerIdBulkWriter.
PR #1188 added collect_consent_gated_eid_updates in ec/finalize.rs, which applies TCF Purpose 4 (personalized ads) gating on top of the Purpose 1 (device storage) gate that ec_finalize_response already enforces. The ingest_* family does not go through it, so the two write paths now disagree about whether Purpose 4 consent is required before EIDs reach the identity graph.
Impact
Not exploitable today. These three functions have zero in-repo callers — the only reference is a comment in ec/admin.rs:602. Nothing currently reaches the ungated path.
The concern is durability: a public, ungated KV write path sitting next to a newly-gated one is the kind of divergence that gets picked up by accident later, and the next caller inherits the consent bug silently.
Options
- Delete the dead
pub surface. Cheapest if nothing plans to use it. Removes the divergence outright.
- Route it through the gate. Thread a
ConsentContext (or the already-collected consent state) through the three public signatures so they resolve updates via collect_consent_gated_eid_updates — or an equivalent shared helper — before any write.
Option 1 is probably right unless there is a planned consumer.
Context
Found during review of #1188 (#1188 (comment)). Deliberately filed as a follow-up rather than held against that PR, since the divergence is pre-existing dead code and not something #1188 introduced.
Problem
crates/trusted-server-core/src/ec/prebid_eids.rsexposes threepubfunctions that write EID-derived partner IDs into the KV identity graph with no consent gating at all:ingest_eid_cookiesingest_prebid_eidsingest_sharedid_cookieAll three funnel through
ingest_eid_cookies_with_writer, which callscollect_eid_updates(...)directly and hands the result to aPartnerIdBulkWriter.PR #1188 added
collect_consent_gated_eid_updatesinec/finalize.rs, which applies TCF Purpose 4 (personalized ads) gating on top of the Purpose 1 (device storage) gate thatec_finalize_responsealready enforces. Theingest_*family does not go through it, so the two write paths now disagree about whether Purpose 4 consent is required before EIDs reach the identity graph.Impact
Not exploitable today. These three functions have zero in-repo callers — the only reference is a comment in
ec/admin.rs:602. Nothing currently reaches the ungated path.The concern is durability: a public, ungated KV write path sitting next to a newly-gated one is the kind of divergence that gets picked up by accident later, and the next caller inherits the consent bug silently.
Options
pubsurface. Cheapest if nothing plans to use it. Removes the divergence outright.ConsentContext(or the already-collected consent state) through the three public signatures so they resolve updates viacollect_consent_gated_eid_updates— or an equivalent shared helper — before any write.Option 1 is probably right unless there is a planned consumer.
Context
Found during review of #1188 (#1188 (comment)). Deliberately filed as a follow-up rather than held against that PR, since the divergence is pre-existing dead code and not something #1188 introduced.