Data Handling

Edition 3.1.1

This page is engineering guidance, not legal advice. Legal statements on this page describe the mainstream reading of the cited instruments as of 2026-07-19 (privacy/legal evidence ledger; quarterly review cadence) and are jurisdiction-specific starting points for your DPO/counsel, not compliance determinations. Controller decisions are marked [CONTROLLER]; counsel-review points are marked [COUNSEL]. A refresh pass on 2026-08-07 added dated facts for the CNIL self-assessment regime, the US state privacy laws and California enforcement actions, and the broadened DPF monitoring item. Paragraphs new in that pass carry their own 2026-08-07 verification date. Claims without dated primary support are omitted.

Hard rules on this page carry stable requirement IDs (UIAF-08-*) and use BCP 14 key words (MUST / MUST NOT / SHOULD); explanatory and legal prose is nonnormative.

What Is Personal Data in This Context

Not everything UIAF touches is personal data, and not everything that is personal data requires the same treatment. Classification is contextual, not nominal.

Data	Personal data?	Why	Authority
Random UUID (`uiaf_uid`)	Yes	A persistent identifier assigned to re-identify returning visitors is an “online identifier” relating to an identifiable person	GDPR Art 4(1); Recital 30 (primary); CJEU C-582/14 Breyer (supporting). Classification can be holder-relative per CJEU C-413/23 P (2025-09-04) — relevant to the endpoint/processor analysis [COUNSEL]
Hashed email	Yes	Pseudonymization is not anonymization: unsalted SHA-256 over a small, enumerable input space is reversible by dictionary attack and matchable against known-hash corpora. Hashed identifiers remain personal data for every party that holds or can feasibly rebuild the underlying list	GDPR Art 4(5), Recital 26; EDPS/AEPD, Introduction to the hash function as a personal data pseudonymisation technique (Oct 2019); EDPS/AEPD, 10 misunderstandings related to anonymisation (2021), Misunderstanding 1; WP29 Opinion 05/2014 (WP216) §3.4
Click IDs (`gclid`, `fbclid`, `msclkid`, …)	Yes	Online identifiers linking to user profiles maintained by advertising platforms	GDPR Recital 30
UTM parameters	Contextual	Campaign-level values (source/medium/campaign describing the campaign) are not, standing alone, personal data — and standing alone, transient and non-combined, they engage no Art 6 basis of their own. Three caveats: (1) user-specific values in URL parameters (mail-merge IDs, subscriber IDs) are personal data and may also constitute link decoration within ePrivacy Art 5(3); (2) once captured alongside a UID, session ID, click ID, or timestamped record, the combined record is personal data and the basis duty attaches at combination, transmission, or retention; (3) pre-consent values combine with a UID only after consent, under that consent [CONTROLLER]	GDPR Art 4(1), Recitals 26/30; EDPB Guidelines 2/2023 (final v2.0, 2024-10-07)
IP address (even truncated)	Yes (treat as such)	Truncation is minimization, not anonymization. In the coordinated Google-Analytics complaint series — decisions chiefly concerned with Chapter V transfers and the adequacy of the anonymization/supplementary measures — the Italian Garante expressly stated that an IP address would not be anonymised even if it were truncated; the Austrian DSB and the CNIL reached parallel conclusions on the inadequacy of the measures in their own decisions without that express truncation holding [COUNSEL]	Austrian DSB (2021-12-22); CNIL formal notice (2022-02-10); Garante press release, docweb 9782874 (2022-06-23)

Hashing Requirements

Invariants

UIAF-08-HASH-001 — Raw email, phone, and customer identifiers MUST NOT enter any UIAF payload. Hashing MUST happen before dispatch, server-side wherever the architecture permits.

UIAF-08-HASH-002 — Empty input MUST produce null — never a hash. The SHA-256 digest of the empty string appearing anywhere as an identifier hash MUST be rejected as a validation error, not data.

UIAF-08-HASH-003 — Normalization profiles MUST be explicit and versioned, and the profile-specific hash MUST be produced before dispatch at the application/server. An endpoint cannot re-normalize an irreversible hash: if destination requirements differ, separate profile-specific hashes MUST be produced at the source. Profile contents (per-destination rules, platform evidence) are specified in Identity Resolution; this page owns only the invariants.

UIAF-08-HASH-004 — Client-side hashing (pure-SPA architectures) is a last resort and the browser preprocessing path MUST hash only email/phone identifiers that already satisfy the verified-evidence gates of Identity Resolution (UIAF-06-EVID-002: unverified newsletter, contact, or lead-form input never emits identify; UIAF-06-EVID-003: customer/account identifiers never reach browser hashing). The raw value MUST be hashed immediately on capture, MUST NOT be persisted beyond the immediate call, and any available server path SHOULD be preferred — raw PII in browser JavaScript is visible to devtools, injected scripts, and extensions.

What NOT to Hash

Click IDs and platform cookie values are sent raw, and only when the destination/purpose disclosure gate allows the send. Ad platforms match these values in their original form only, so hashing or altering them breaks the match entirely (_fbc/_fbp, gclid/gbraid/wbraid, msclkid, and platform click identifiers generally). Sending them anywhere is a disclosure act governed by the destination/purpose gates in Consent Integration. Storage permission alone never confers disclosure authority. The privacy control is consent, not obfuscation.

Data Minimization

Capture only what you need (GDPR Art 5(1)(c)):

UIAF-08-MIN-001 — URL parameter capture MUST be limited to registered, allowlisted parameters. Query strings can carry search queries, session tokens, and PII; unallowlisted parameters MUST NOT enter any payload or stored attribution.

UIAF-08-MIN-002 — The payload body MUST NOT contain an IP address. The transport layer already carries it, and duplicating it creates one more copy subject to deletion duties. Transport-layer IP handling has its own controls (see Logging below).

UIAF-08-MIN-003 — Page paths captured for context SHOULD be sanitized or excluded where they match known PII patterns (/user/<name>/…, order-confirmation paths embedding addresses).

UIAF-08-MIN-004 — Attribution MUST NOT be stored in cookies: a cookie is auto-sent on every request, leaking attribution to logs and CDNs, bloating requests, and fragmenting purge behavior. The storage registry (uiaf-storage-keys.json) contains no attribution backup cookie; persisted post-resolution attribution uses permitted localStorage/sessionStorage only, while the pending-core context remains current-document memory only per Consent Integration — no cookie or other durable pending storage exists. The pre-3.0 uiaf_attribution cookie is legacy mechanism-purge metadata recorded on the live uiaf_attribution registry row and is deleted on sight by reconcile-on-init.

Nonnormative guidance:

Cookie size: RFC 6265 defines floor minimums, not uniform ceilings. User agents must support at least 4,096 bytes per cookie, 50 cookies per domain, and 3,000 total. Keep UIAF cookies far below the per-cookie floor (the UID cookie is ~50 bytes) and treat the floors as portability limits, not guarantees.
Unused parameters: every stored parameter is processing that must be justified. Do not capture what you will never analyze [CONTROLLER].

Data Subject Rights

UIAF processes personal data; the implementation must support data-subject rights. Rights operations are control-plane workflows. They are not events, do not use the three-event payload schema, and never enter the retry queue (the event registry, uiaf-events.json, contains no rights-related event value).

Requester verification and timing

UIAF-08-DSR-001 — A UID alone MUST NOT be accepted as authentication of a data subject. Possession of a browser (or knowledge of a UID value) is not proof of identity: privileged deletion, access, and portability MUST require authenticated, server-side requester verification designed by the controller (Art 12(6) permits requesting additional information where identity is in reasonable doubt) [CONTROLLER]. Requests are actioned without undue delay and within one month of receipt; the period may be extended by up to two further months where necessary, taking into account the complexity and number of requests, with the data subject informed of any such extension within one month of receipt, together with the reasons for the delay (Art 12(3)). Verification under Art 12(6) is a separate step and never a delay device.

Purge predicates and mechanics

UIAF-08-PURGE-001 — UID and session state (uiaf_uid/uiaf_recovery, uiaf_session_state) MUST be purged on exactly these predicates: the effective analytics_storage transition allowed→denied; explicit revocation; verified erasure; entry into the dormant state; and reconcile-on-init divergence (persisted UIAF state that current effective permissions no longer allow). Loss of an advertising permission alone (ad_storage, ad_user_data, or ad_personalization) MUST NOT purge UID or session state — those transitions purge or halt only what they gate. The full field-level transition matrix lives in Consent Integration.

UIAF-08-PURGE-002 (mechanism-aware purge) — On explicit revocation, client script MUST initiate the one-shot dedicated control request first and then synchronously clear all permitted script-clearable state — localStorage, sessionStorage, in-memory script state, and any other script-clearable mechanism — without awaiting the response and before any later persistence, write, or send. The client performs zero persistent-UID-cookie writes or deletions — uiaf_uid is never written or expired through document.cookie, the Cookie Store API, or any equivalent path, in any state (Identity Management, UIAF-02-COOKIE-001). Expiring uiaf_uid is the same-origin endpoint/middleware’s job. Under the UIAF-08-PURGE-001 predicates, middleware MUST treat an inbound prior uiaf_uid as denied/absent before resolution, hydration, forwarding, or any other reuse, and MUST send a deletion cookie matching the original issuance scope — Max-Age=0, Path=/, Secure, SameSite=Lax, and the identical configured Domain when one was set (a bare Max-Age=0 from an API path with a different scope can fail to remove the site-wide cookie). Local purge completes even on revocation timeout or failure; the next request performs that deny-before-use plus scoped expiry, so a prior UID cannot be reused even when the purge-time response was lost.

Right to erasure (Art 17)

UIAF-08-DSR-002 — Client side: on verified erasure the browser MUST clear, per UIAF-08-PURGE-002, every script-clearable mechanism of every applicable storage-registry entry — including the complete legacy purge-on-sight set, for which the registry’s legacy_purge_only section (uiaf-storage-keys.json) is the sole source of truth; this page deliberately does not enumerate it and defers to the registry. Script-readable retired cookie mechanisms are cleared too, including the pre-3.0 uiaf_attribution cookie recorded as legacy mechanism-purge metadata on the live uiaf_attribution registry row; the persistent server-set uiaf_uid cookie remains server-only and is expired by middleware per UIAF-08-PURGE-002, never by script.

UIAF-08-DSR-003 — Server side: the site’s backend MUST call the endpoint’s authenticated deletion workflow with the verified subject’s UID; the endpoint cascades deletion to downstream recipients — a controller duty (Art 19 notification; Art 28 processor terms govern the endpoint relationship) [CONTROLLER].

UIAF-08-DSR-004 — Deletion is not future opt-out. Erasure removes history; nothing prevents a fresh anonymous UID on a later visit. Future opt-out is represented by the CMP record, GPC, or the controller’s preference system — erasure MUST NOT create a UIAF storage marker and MUST NOT create an indefinite server tombstone: any suppression record’s retention is controller- and jurisdiction-configured with a documented purpose and review [CONTROLLER].

UIAF-08-REVOKE-001 — The browser-initiated revocation call is a same-origin, CSRF-hardened, minimal tombstone-only control request: the previous UID appears in it solely to honor withdrawal; the request MUST fire before local purge; local purge MUST proceed regardless of timeout or failure; the call is one-shot — no retry, no queue entry; the previous UID MUST NOT be reused after purge (next-request middleware expiry per UIAF-08-PURGE-002 enforces this even when the revocation response is lost). When no prior UID exists, the route carries no invented identifier — revocation and local purge still occur. It is not an event and MUST NOT appear in the analytics schema or retry queue. Server-side suppression retention follows the controller-configured policy above.

UIAF-08-REVOKE-002 (route contract) — The revocation control route is a dedicated same-origin route — documented contract shape POST /api/uiaf/revoke — carrying a strict JSON closed body: the previous UID and nothing else (tombstone-only; any additional field fails validation). Where both the body and the inbound uiaf_uid cookie carry a UID, the body value is authoritative for the tombstone — the inbound cookie is already treated as denied/absent and expired by middleware per UIAF-08-PURGE-002. Status map: 2xx means the tombstone was accepted (recorded or already present); 4xx means malformed or unauthenticated and applies no tombstone effect, and 4xx responses MUST NOT distinguish “unknown UID” from “known UID” (non-enumerating). Local purge proceeds regardless of the response (UIAF-08-REVOKE-001, UIAF-08-PURGE-002), so the status map is informational to the server side only. Repeat delivery of the same revocation is idempotent — the same effect with no duplicate side effects — and the route MUST accept duplicates without error while the client remains one-shot (no retry, no queue entry) per UIAF-08-REVOKE-001. The site backend’s authenticated server-to-server hop to the endpoint (UIAF-08-TRUST-004) carries the same tombstone.

UIAF-08-REVOKE-003 (revoked-UID suppression) — The endpoint MUST suppress processing of data-plane events for UIDs known-revoked through the control plane: a recorded revocation tombstone (UIAF-08-REVOKE-002, UIAF-08-TRUST-004) is an endpoint-enforced suppression list, and any data-plane event carrying a tombstoned UID is dropped without effect — no identity resolution, no attribution write, no downstream disclosure. Client-side silence after revocation (tier-4 dormancy, local purge) is a client obligation — necessary but not sufficient: a buggy or malicious client can keep sending under cached state, so revoked-UID suppression is endpoint-enforced, not only client-promised. Tombstone retention follows the suppression-records row of the retention schedule (controller-configured, never indefinite by default).

Access and portability (Art 15, Art 20)

Exports are compiled at the endpoint and delivered through the same authenticated, verification-gated control workflow, in a machine-readable format. The same verification bar applies as for deletion.

Right to object (Art 21)

An objection suppresses the relevant capabilities (ad_personalization, ad_user_data) and downstream disclosure on the same field-level transition model used for revocation (Consent Integration). Above all, the Art 21(2) objection to direct-marketing processing is absolute and needs no balancing test. Objection is a control-plane workflow distinct from erasure and from analytics-consent revocation. It does not delete history and does not gate analytics, but it terminates the objected-to processing and onward disclosure. Its intake and verification design is controller/counsel-determined [CONTROLLER][COUNSEL].

Endpoint Authentication & Trust Boundaries

CORS is not authentication. Origin checks constrain browsers, not curl; any unauthenticated endpoint accepts fabricated JSON from anywhere.

UIAF-08-TRUST-001 — Browser code MUST NOT contain an ingest shared secret or HMAC key. HMAC/shared-secret authentication is server-to-server only.

UIAF-08-TRUST-002 — The recommended collection path is a same-origin relay: the site’s own origin receives browser payloads (verifying Origin/Sec-Fetch-Site, applying CSRF controls where applicable, validating the schema, and rate-limiting), then adds server-held downstream authentication toward the endpoint. The relay derives or replaces server-authoritative fields and forces every browser-originated _meta.emitter to client. The full wire rule: _meta.emitter is the sole logical-emitter field, enum exactly client|server; any _meta.delivery occurrence MUST fail schema/producer validation; relayed browser input is always forced to client; unauthenticated public input may never assert server; only authenticated server-to-server input can retain server.

UIAF-08-TRUST-003 — A direct browser-to-public-endpoint deployment MUST be treated as an explicitly unauthenticated public ingest surface. An unauthenticated, schema-valid event cannot prove sender authenticity — the contract is handling of forged and abusive traffic — sender authenticity can never be established on this surface, so no rejection-of-forgeries guarantee exists: the surface MUST apply strict schema validation, quotas, and anomaly controls, MUST mark its data untrusted-provenance, and MUST NOT produce any privileged or control-plane effect; only malformed, over-quota, or emitter-spoofed (UIAF-08-TRUST-005) traffic is rejectable. Origin/CORS checks and rate limits are supplemental abuse controls, not authentication.

UIAF-08-TRUST-004 — Control-plane operations MUST use dedicated control routes, never the collection/data-plane path; a rights- or revocation-shaped request arriving on a collection path MUST fail without effect. The two-hop contract: browser-initiated revocation is accepted only at its dedicated same-origin, CSRF-hardened, minimal revocation route, and the site backend then authenticates the downstream server-to-server control call to the endpoint. Privileged erasure, access, and portability use separate authenticated, verification-gated server routes (UIAF-08-DSR-001). Revocation and DSR are separate control APIs.

UIAF-08-TRUST-005 (emitter-forgery hard rejection) — Any payload asserting _meta.emitter: server arriving on unauthenticated ingress — direct public ingest, or a relay hop that has not authenticated its sender — MUST be hard-rejected with a 4xx status, never marked untrusted and processed. The mark-untrusted-and-proceed handling of UIAF-08-TRUST-003 applies to provenance-unknown traffic generally; an affirmative server assertion from an unauthenticated source is a known forgery class, not an unknown provenance, and the rejection MUST NOT enumerate accepted UIDs. The same-origin relay forcing every browser-originated _meta.emitter to client (UIAF-08-TRUST-002) remains the mechanism that keeps legitimate relayed traffic out of this rejection path.

UIAF-08-TRUST-006 (pre-parse size ceiling) — The first hop receiving a UIAF request body — the same-origin relay, or the endpoint on direct ingest — MUST enforce a hard Content-Length ceiling and reject oversize bodies with 413 Payload Too Large before buffering or parsing: the ceiling guards the parser, so it cannot itself depend on parsing. A ceiling at or below 40 KiB is recommended. This pre-parse guard is a separate, earlier control than the 32 KiB canonical-body cap, which is a post-JCS (RFC 8785) ceiling applied after canonicalization (see Endpoint Schema); a non-canonical body under the raw ceiling can still exceed a post-JCS cap and fails closed there.

The cookie-issuance endpoint’s own contract (UID validation, no-overwrite behavior, consent enforcement, no raw-UID logging) is specified with the auxiliary interfaces in Endpoint Schema.

Request observability boundary

UIAF’s consent gates govern UIAF-shaped data-plane events and client-side persistence only. Every landing request (full URL with click IDs and UTMs, referrer, IP, user agent) reaches the origin, and any same-origin relay, before any client code runs. Landing-request, CDN/edge, and relay logs observe the complete request regardless of consent tier.

Retention & Controller Obligations

Retention is controller-, purpose-, and jurisdiction-specific configuration. This specification sets no universal legal periods and prescribes no indefinite records (hashed UIDs remain personal data; see the classification table). Cookie lifetime is not endpoint-record TTL: the browser-side Max-Age bounds client persistence only, and endpoint retention is a separately configured policy.

UIAF-08-RET-001 — Controllers MUST configure and document purposes/lawful-basis decisions, configured maxima with their rationales, and review owner/cadence [CONTROLLER]; protocol-mandated purge/drop triggers and registry-governed bounds remain normative UIAF protocol and are not controller-variable. This specification supplies the structure and the documentation duty, never universal legal TTLs:

Data class	Location(s)	Purpose / lawful-basis decision	Configured maximum + rationale	Deletion trigger	Review cadence / owner
UID / identity state	Browser storage (registry keys); endpoint identity store	[CONTROLLER]	[CONTROLLER] — browser `Max-Age` bounds the client copy only	The UIAF-08-PURGE-001 predicates: `analytics_storage` `allowed`→`denied`, revocation, erasure, dormant entry, reconcile-on-init (client — ad-permission loss alone never purges identity); erasure cascade (server)	[CONTROLLER]
Attribution records + click IDs	Permitted browser storage; endpoint	[CONTROLLER]	[CONTROLLER] — vendor click-ID matching/ingestion windows bound downstream usefulness only; they are not UIAF client-retention promises or TTLs	`ad_storage` loss (click-ID members), `analytics_storage` loss (record), revocation, erasure	[CONTROLLER]
Immutable retry entries	Browser `uiaf_retry_queue`	Per-event purpose	Registry-governed TTL/attempt bounds (72-hour TTL)	Terminal outcome; predicate drop on any downgrade; revocation; erasure	[CONTROLLER]
Endpoint event content	Endpoint	[CONTROLLER]	[CONTROLLER] — legal/business retention	Configured expiry; erasure cascade	[CONTROLLER]
Endpoint dedup state (protocol)	Endpoint	Protocol correctness — duplicate suppression across the retry window	UIAF-08-RET-002 floor; upper bound [CONTROLLER]	Expiry after the configured window	Protocol floor fixed; [CONTROLLER] above it
Consent receipts	CMP (system of record); access-controlled server receipt referenced by `consent_record_id` — optional for `cmp_*` sources, required for `source: gcm` deployments in consent-required jurisdictions (see the Art 7(1) checklist item)	Consent-proof duty	[CONTROLLER] — jurisdictionally justified	Configured expiry	[CONTROLLER]
Suppression records	Endpoint	Honoring withdrawal	[CONTROLLER] — jurisdictionally justified; never indefinite by default	Configured expiry + review	[CONTROLLER]
Infrastructure logs (access/CDN/APM/error — including any full-URL or click-ID-bearing lines)	Edge, origin, tooling	Operations/security	[CONTROLLER] — with the Logging section’s redaction and truncation controls applied at the earliest boundary	Configured rotation/expiry	[CONTROLLER]

UIAF-08-RET-002 — Endpoint deduplication state is protocol state, distinct from event-content retention: it is keyed by the immutable event_id (retries resend the identical frozen bytes under the same event_id), and the endpoint MUST retain each dedup key for at least 72 hours — the retry-queue TTL — so a retried frozen payload cannot be double-counted after its dedup record expires. This floor is independent of controller event-content retention: event content (and any legal-hold duty) is separately configured per UIAF-08-RET-001 and is never bounded by the dedup window.

Dedup is duplicate suppression, not a security control: it does not authenticate the sender and it does not close replay. An attacker who observes a legitimate event_id can replay the exact frozen bytes from anywhere within the window. The endpoint will drop the replay as a duplicate. Dedup itself proved nothing about either delivery, and downstream “last seen” state can still be nudged by replays that a downstream system does not re-validate. Endpoints protecting privileged effects layer their own anti-replay controls (acceptance timestamp windows, origin binding on the relay, rate limits) independently of dedup state [CONTROLLER].

UIAF-08-RET-003 — Downstream systems MUST NOT treat receipt of a data-plane event as authorization for privileged effects: matching, audience admission, and any control-plane consequence follow the downstream system’s own consent ledger and authentication, never the mere arrival of a schema-valid payload (the unauthenticated-ingest handling contract is UIAF-08-TRUST-003/005).

The UIAF pending-context object is never persisted as UIAF state or copied into any durable sink (see Consent Integration). The initial request URL may already have reached request/history/log infrastructure before the earliest controllable boundary. That copy is governed by earliest-boundary redaction plus the infrastructure-log retention row above; no universal absence is claimed. Cookie Max-Age is not an endpoint retention period. The two are independent policies.

UIAF-08-CONSENT-001 — The CMP remains the system of record for consent proof. Payloads MUST carry only the minimized consent object, whose exact fields are signals, status, effective, gpc, source, state_updated_at, required derived integer tier (0..4 — serialized shorthand only; tier never drives permission, send, purge, or routing behavior), and optional opaque consent_record_id referencing a separately retained, access-controlled server/CMP receipt. No other consent field exists, and a raw CMP string MUST NOT appear in any payload, frozen retry body, or log. Whether and how long events and receipts are retained is controller configuration [CONTROLLER].

Controller-obligations checklist (each item the controller’s to complete; counsel-labeled where interpretation is required):

Art 7(1) consent demonstrability: the CMP is the system of record for consent proof (UIAF-08-CONSENT-001). That deferral does not cover source: gcm deployments, where Google persists no consent record. Those deployments persist their own Art 7(1)-adequate receipt (signal values, timestamp, UIAF/CMP version, request provenance) surfaced via consent_record_id, per the GCM-receipt requirement in Consent Integration [CONTROLLER].
Art 13/14 transparency: UIAF’s cookies, purposes, recipients, and lifetimes appear in the privacy notice and the CMP’s cookie table.
Art 30 records of processing.
Art 28 processor terms for the endpoint (typically server-side tag infrastructure, often agency-operated). Where this specification says “no-forward,” it means no unauthorized forwarding: any commitment to restrict onward disclosure is a deployment-specific contractual commitment in the processor terms, backed by technical controls. UIAF imposes no universal endpoint no-forward policy.
Chapter V transfers: endpoints commonly run on US-cloud infrastructure. The EU–US Data Privacy Framework adequacy decision (2023-07-10) was upheld at first instance (General Court, Latombe, 2025-09-03) with an appeal reported pending (C-703/25 P). Transfers under it remain lawful but monitored. The quarterly review tracks (a) the C-703/25 P appeal and (b) US-side institutional/oversight developments affecting the DPF adequacy basis, and the transfer basis is revisited at each implementation; document SCC/TIA fallbacks [COUNSEL].
Art 33/34 breach readiness: maintain breach-detection, assessment, and notification procedures that cover the UID/identity store. Whether a given compromise is notifiable is the controller’s risk assessment under Art 33(1) (supervisory authority, unless the breach is unlikely to result in a risk) and Art 34(1) (data subjects, where high risk) [CONTROLLER]. Not every compromise meets those thresholds.
Art 9 caution: on sensitive sites, landing paths and search-derived parameters can reveal special-category data. Gate or prohibit by site category [COUNSEL].
Art 8 / minors: sites whose audience reaches minors screen age, disable ad_personalization/ad_user_data for minor sessions, and review whether landing_url/conversion/utm_term capture is acceptable. GDPR Art 8 (parental consent for information-society services offered to children), the UK Age Appropriate Design Code, COPPA, and US state minors’ laws each impose heightened duties. Several states near-totally ban targeted advertising to minors. Controller/counsel determination [CONTROLLER][COUNSEL].
Art 22/35 screening: identity graphs are profiling infrastructure; a DPIA is likely required and Art 22 applicability should be screened [COUNSEL].

Honest persistence statement: UIAF specifies no server-side store of its own; the real endpoint and controller stores that implementations operate follow the retention schedule above. Browser-side persistence (up to the browser-enforced maxima in Browser Landscape, renewable) must be disclosed with a retention rationale.

National ePrivacy configuration

ePrivacy is directive law: national transpositions differ materially, and jurisdiction behavior belongs in reviewed controller configuration, not prose defaults. Rows appear here only with row-level primary evidence (verified 2026-07-19):

Jurisdiction	Instrument	Position	Last reviewed
Germany	TDDDG §25 (renamed from TTDSG, 2024-05-14)	Technology-neutral consent requirement for terminal-equipment storage/access; supervisory guidance (DSK Orientierungshilfe) treats analytics session stitching as not strictly necessary [COUNSEL]	2026-07-19
France	CNIL audience-measurement framework — self-assessment regime (approved-tools list withdrawn Jan 2026; seven cumulative conditions unchanged — CNIL, “Cookies et autres traceurs”, accessed 2026-08-07)	A narrow, conditional audience-measurement exemption exists; default UIAF does not meet its conditions (persistent renewable identifiers, identity resolution, endpoint forwarding each conflict), and qualification of any reduced configuration is a controller/counsel assessment [COUNSEL]	2026-08-07

The table contains the currently evidenced rows; other jurisdictions are controller/counsel configuration [COUNSEL]. Two further opt-in-leaning extraterritorial regimes warrant the same consent-first posture as the EU for their visitors: Brazil’s LGPD (Lei nº 13.709/2018: Art 3 extraterritorial reach, ANPD-enforced, full DSR set) and Quebec’s Law 25 (consent and opt-out duties reaching Quebec residents). For sites serving Brazilian or Quebec visitors, the T0 (no-consent-mechanism) path is not lawful regardless of the US/EU analysis. This jurisdictional surface is re-reviewed on the same quarterly cadence as the other legal-status lines on this page [COUNSEL].

US state privacy laws (mid-2026)

24 states have comprehensive privacy statutes as of mid-2026. Indiana, Kentucky, and Rhode Island took effect 2026-01-01; Alabama, Louisiana, Oklahoma, and Vermont passed laws in 2026; California’s AB 45 health-data law also took effect 2026-01-01 (state counts and effective dates per the secondary law-firm compilations cited below). California enforcement intensified through 2026. The CPPA fined Ford $375,703 (Mar 2026) for adding unnecessary friction to its opt-out process, and the California Attorney General secured a $2.75M settlement with Disney (Feb 2026) over opt-out effectuation gaps, including GPC requests honored only per device. GM settled for $12.75M (May 2026, the first CPRA data-minimization action, per the attributed secondary report below). Opt-out mechanism quality, meaning no friction, is now actively enforced, which bears directly on GPC handling and opt-out UX (Consent Integration) [COUNSEL].

Sources: CPPA, Ford opt-out-friction action (primary, accessed 2026-08-07); California AG, Disney opt-out settlement (primary, accessed 2026-08-07); secondary compilations: Koley Jessen — IN/KY/RI effective dates, Byte Back — 24-state landscape, Multistate — 2026 effective dates incl. AB 45, Akin Gump — GM data-minimization action (all accessed 2026-08-07).

UIAF-08-COOKIE-001 — UIAF cookies MUST set Secure. SameSite=Lax MUST NOT be treated as general CSRF prevention: state-changing routes (the cookie-issuance endpoint, the revocation control route) MUST carry their own CSRF defenses.

Attribute	Value	Purpose — stated precisely
`Secure`	`true`	Prevents transmission over plaintext HTTP
`SameSite`	`Lax`	Mitigates some cross-site request classes. Not general CSRF prevention — state-changing routes (the cookie-issuance endpoint, the revocation control route) require their own CSRF defenses
`Path`	`/`	Operational consistency. `document.cookie` visibility and sending are path-matched, but `Path` is not an isolation or security boundary — same-origin active content can typically still reach a scoped path
`Max-Age`	per policy	A client-persistence choice bounded by browser enforcement (see Browser Landscape) — not a guarantee and not an endpoint retention period

The HttpOnly trade-off is documented in Identity Management. The cookie-issuance endpoint’s validation/no-overwrite/no-logging contract lives with the auxiliary interfaces in Endpoint Schema.

Transport Security

UIAF-08-TLS-001 — Every website↔endpoint exchange MUST use HTTPS (TLS 1.2+).

UIAF-08-TLS-002 — Every value UIAF explicitly serializes into an application, data-plane, or control-plane request field MUST travel in the POST body, never in a URL parameter: URLs persist in access logs, proxy/CDN caches, browser history, and Referer headers. The server-set uiaf_uid that browsers necessarily transmit in the Cookie request header is separately governed (Identity Management) and is not permission to place arbitrary fields in headers. Exactly one constrained auxiliary exception exists: the single-use _uiaf_token query parameter of the cross-domain handoff, exactly as bound by the Endpoint Schema auxiliary contract. Its two hops: the source origin’s 303 produces the one token-bearing decorated target URL; the target server redeems the token through the authenticated server-to-server consume before render, and only then does the browser receive the clean allowlisted 303. The token MUST be single-use, MUST NOT appear in static or prefetchable markup, MUST be suppressed from access and application logs on every branch, and MUST NOT be reused. This exception covers the token alone and is not a general URL-data exception: the prohibition applies to values UIAF places in URLs — incoming advertising click IDs already arrive on landing URLs and are left intact per Attribution Capture.

UIAF-08-TLS-003 — Any direct-ingest CORS configuration MUST allowlist explicit origins, never * — while remembering that CORS is an abuse control, not authentication (see Trust Boundaries).

Logging

Server logs are a common leak path: long retention, weak encryption, broad operational access.

UIAF-08-LOG-001 — Raw PII MUST NOT be logged; the raw UID MUST NOT be logged (including on the cookie-issuance path); a raw CMP string MUST NOT be logged. Hashed or truncated persistent identifiers in logs remain linkable personal data: hashing a UID for a log line is minimization, not anonymization; log retention and access controls apply to it.

UIAF-08-LOG-002 — Transport-layer IP handling MUST be configured with stated controls: “let the transport carry it” is acceptable only with trusted-proxy configuration (so client IP is attributed correctly and not spoofable via forwarded headers), log suppression or truncation, and a configured retention period — all three MUST be in place [CONTROLLER].

UIAF-08-LOG-003 — Redaction MUST be applied at the earliest controllable boundary: CDN/edge, application, APM, and error-reporting sinks each redact allowlisted click-ID and user-specific query values (the click-ID parameter registry is the scan list). The initial request may already have reached infrastructure before the earliest boundary — redaction limits onward exposure; it cannot un-receive a request.

UIAF-08-LOG-004 — Classification labels are metadata, not enforcement. Tagging a field pii: true in structured logs enables nothing by itself: filtering or redaction happens only where each sink is explicitly configured to enforce the label — and that enforcement MUST be tested per sink.