IP & User‑Agent Collection

ExpressConsent attaches network and device context to each snapshot so you can confidently attribute events to the actual client environment. This page outlines our high‑level approach to determining the client IP, handling modern User‑Agent (UA) signals, and what information is typically recorded for auditing.

Objectives

Accuracy first: Favor the most trustworthy representation of the client’s public IP, even through multiple proxies.
Resilience: Work reliably with modern browsers (UA reduction) and diverse network topologies (CDNs, WAFs, reverse proxies).
Auditability: Preserve enough provenance to explain “where an IP came from” without over‑exposing sensitive data.

Determining the Client IP (High Level)

Evaluate standard proxy headers: In practice, edge/CDN providers place the original client IP in well‑known headers. We consider those in a sensible order and prefer values that represent the true public client address.
Filter private ranges: Private, loopback, and link‑local ranges are ignored to avoid selecting intermediary hops.
Retain the chain: We keep the ordered list of IPs we saw (the “chain”) so there’s a clear provenance trail during audits.
Fallback behavior: If no public address is available, we fall back to the best available signal for deterministic operation.

User‑Agent and Client Hints (Modern Browsers)

Legacy UA string: We record the traditional User‑Agent string for broad compatibility and quick triage.
Client Hints (when permitted): Modern browsers increasingly reduce the UA string. Where available, we also capture high‑entropy Client Hints (e.g., platform model/version, architecture, bitness) to improve accuracy.
Graceful fallback: If Client Hints aren’t provided, the legacy string and baseline browser surfaces still give useful context.

Telemetry We Commonly Record

The goal is to create a reliable record that stands up to audit:

Canonical client IP and the ordered IP chain we observed
User‑Agent string and, when available, Client Hints
Basic request context like language preferences and relevant referrer/origin signals
Correlation identifier that links the signer request to the subsequent object upload

IPv4 vs IPv6: what you’ll see and why

Two address families: IPv4 uses dotted decimals (for example, 203.0.113.42) and IPv6 uses hexadecimal groups (for example, 2001:db8::1). Many clients and networks are dual‑stack and can use either family.
Why you’ll only see one per request: A given network request ultimately uses a single source address (either IPv4 or IPv6). Even if a device supports both, the connection is established over one family, and the upstream edge forwards that as the canonical client IP. You cannot reliably “infer” the other family’s address for the same client.
When IPv4 appears: IPv4‑only networks; corporate environments using NAT44; devices or browsers with IPv6 disabled; proxies or middleboxes that terminate IPv6 and egress over IPv4.
When IPv6 appears: Dual‑stack networks where IPv6 is available and preferred; many mobile carriers; ISPs and CDNs that prioritize IPv6 via Happy Eyeballs; environments with limited IPv4.
Mixed proxy chains: It’s common to see a mix of IPv4 and IPv6 across different hops in a proxy chain. The canonical client IP corresponds to the hop designated by your trusted edge; other hops may be in either family.

What we record

The authoritative client address for the request (IPv4 or IPv6), along with enough surrounding context to audit how it was derived.
Where relevant, we retain the address family so downstream systems can apply family‑specific policies (e.g., allowlists, geolocation libraries, or rate‑limiting strategies).