Pluggable, competition-neutral modules with a technical permission model #777

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 module behind a small trait, named by its crate folder, 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 module. The existing implementations 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 module declares the technical permissions its data use requires, and the core runs the module only when those permissions are held.

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

• (a) Country, when known. Resolved from the country the geo module returns, keyed by ISO 3166-1. When no country is identified, the deployer's required default country ([geo] default_country) applies. Trusted Server does not assume a jurisdiction, so a default is always declared and startup fails without one.
• (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 the stacked pull requests #1043, #1044, #1045, #1046, #1047 and #1094, with the design in #1084, which close each task on merge. In that series every module is named by its crate folder and selected from the table of its type, as [ec] module, [device] module, [geo] module and [permission-signal] modules, and the auction's [demand] modules and [ad-server] module select the same way.

Related

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