Pluggable, competition-neutral providers with a technical permission model

[jwrosewell]

Overview

Trusted Server hard-wires several request-time decisions (how the Edge Cookie identity is minted, how a request is classified for the bot gate, how geolocation is resolved) and gates Edge Cookie creation on a country rule baked into the core. This epic makes each capability a configuration-selected provider behind a small trait, with neutral defaults that make no host-specific call, and replaces the baked-in gate with a technical permission model.

Privacy is a spectrum, not a binary, and Trusted Server is technology that is neutral on policy. Different deployers operate under different laws and run different policies, so it is the deployer who decides how to configure the stack. This work provides the mechanisms and respects the deployer's choices, rather than deciding on their behalf. The default deployment makes no host-specific call, creates no identifiers, and resolves no location until an operator enables these features via a provider. The existing providers are retained.

The permission model: separating legal policy from the core

The Trusted Server core does not encode any jurisdiction's law or any single policy. Instead, a provider declares the technical permissions its data use requires, and the core runs the provider only when those permissions are held.

How a permission becomes held is established outside the core, from one or more sources (permission providers):

• (a) Country, when known. Resolved from the country a geo provider returns, keyed by ISO 3166-1, with a fail-closed fallback when no country is identified. This fallback might be the country that the website operator is based in, or a global default.
• (b) Interaction with the user. A publisher may interact with the user to establish their preference. This is the publisher's choice and need not be driven by a legal requirement. A publisher may do it because they want to, not only because a law requires it.
• (c) Data provided from another source. For example a browser extension, or a person's profile provided by an external service.

The permission vocabulary uses the IAB TCF Europe purpose set only as technical identifiers. No policy framework is implemented in the core. Trusted Server provides the mechanism to establish and check permissions, and the deployer brings the policy that decides how permissions are established and what they permit. The model is source-agnostic. It gates on whether a permission is held, not on how it was established, so the sources above plug into the same mechanism.

Tasks

• Make Edge Cookie identity pluggable and opt-in #778 Make Edge Cookie identity pluggable and opt-in
• Establish a technical permission model and gate Edge Cookie creation on it #779 Establish the technical permission model and gate Edge Cookie creation on it
• Make device classification pluggable with a no-host-call default #780 Make device classification pluggable with a no-host-call default
• Make geolocation selectable with a no-location default #781 Make geolocation selectable with a no-location default
• Add an integration response-header hook #782 Add an integration response-header hook
• Select a scenario configuration at startup, with a ready-to-run development.toml #790 Select a scenario configuration at startup

Delivered by a single neutral-providers PR, which closes each task on merge.

Related

• Establish provider-scoped configuration pattern #683 (provider-scoped configuration pattern)
• Remove fastly from core crate #496 (remove fastly from core, the neutrality foundation)

[jwrosewell]

Provider wiring: dependency injection

Recording the provider-wiring approach here, as it is part of this rework rather than a separate issue. Delivered by the neutral-providers PR.

The pluggable providers are wired by dependency injection rather than handed a fixed evidence struct. A provider's constructor takes the services it needs as trait objects, and the adapter, acting as the composition root, supplies concrete instances per request. Core defines the service interfaces and the host-neutral defaults. The interfaces are RequestInfo (the client IP, User-Agent, and headers) and HostSignals (the TLS JA4 and HTTP/2 fingerprints). Host-specific implementations such as FastlyHostSignals live in their own crates and are injected by the adapter, so core never calls a host SDK and the default request path makes no host-specific call. A provider that needs a service the host cannot supply cannot be built, so the request stops rather than minting a degraded identifier.

As implemented:

• Core defines the RequestInfo and HostSignals service traits, with an owned default (OwnedRequestInfo).
• RuntimeServices carries the optional host-signal service, supplied by the adapter composition root.
• build_provider and build_device_provider inject the services each provider needs.
• A provider whose required service the host does not supply fails to build, and the request stops.
• The neutral built-in providers require no host service, so the default path makes no host-specific call.