Repository navigation
Conversation
Brings the permission signal work up to the documentation branch. The merge has no conflicts.
Brings the permission signal work up to the integration seam. Eight files conflicted, because both sides changed the same startup and runtime services code. They are CLAUDE.md, Cargo.toml, Cargo.lock, platform/types.rs and the app.rs of each of the four adapters. Every resolution keeps this branch's seam in full, being the registrations, the Edge Cookie provider resolved at the composition root and the providers a module supplies, and adds the permission signal providers beside it. Each adapter selects those once at startup from the four scheme crates it links and hands them to every request's runtime services. In platform/types.rs the new field, accessor and builder method sit next to the device provider, and CLAUDE.md and Cargo.toml list the seam probe and the four signal crates together. The resulting tree is the one the local gate run covered before this merge, and it differs from this branch by exactly the permission signal work.
The permission signal module documentation opened with the argument for keeping signaling schemes out of core. That is a position rather than a description of the code, and the same argument already stands in docs/guide/permission-signals.md, so the module documentation now points there and keeps to what core holds.
AGENTS.md asks for a descriptive message on every assertion, and the tests added with the permission signal seam left 21 without one. Each now states the rule it holds, so a failure names what broke rather than printing two values that differ.
Brings the documentation and assertion message fixes up from split/3-permissions. The merge has no conflicts.
Brings the documentation and assertion message fixes up from split/4-client-resolve. The merge has no conflicts.
Brings the documentation and assertion message fixes up from split/5-response-hook-docs. The merge has no conflicts.
Brings main at 066ea3c into split/1-ec-provider. Twelve files conflicted and one more needed a change without a textual conflict. Most resolutions keep both sides. Five needed a decision, recorded here so that no behavior changes silently. Edge Cookie generation, in ec/mod.rs. Main's IABTechLab#885 creates a row only when no row holds the key, retries on a collision and binds the request snapshot to the new row. This branch creates identifiers through the selected provider. Both are kept. Each attempt asks the provider for a candidate through the new EcContext::candidate_id, which runs the reserved-header and identifier-bound checks, then creates the row with create_if_absent under the provider's canonical key and binds the snapshot to that key. Orphan recovery, in ec/finalize.rs. Main's IABTechLab#885 rotates an orphaned cookie by generating an HMAC identifier directly, which would give a vendor-provider deployment a built-in identifier. Recovery now asks the selected provider through candidate_id, keeps main's proof of absence and retry limit, and does nothing when no provider is selected. Any headers the provider asks for while creating the replacement are applied to the response. Withdrawal, in ec/finalize.rs. Main's IABTechLab#1113 hardening is kept whole, being finalize_unusable_consent, the existence check inside write_withdrawal_tombstone, the snapshot write-back and log_tombstone_outcome. The tombstones are keyed by this branch's withdrawal_kv_keys, the canonical keys of the cookie and the active identifier, in place of withdrawal_ec_ids, and the write-back compares against the active identifier's canonical key. EID ingestion on the returning and generated paths uses main's collect-then-upsert form under the canonical key. Secret references, in config.rs. Main's IABTechLab#1036 resolves secret settings from the secret store by the paths listed in secret_fields. This branch makes the legacy ec.passphrase optional and adds the [ec.providers.hmac] passphrase, which was not listed, so it would have been read as a literal value. Both are now listed as optional paths and checked as key references when the configuration is pushed, and the integration fixture and the example configuration name the secret key rather than a value. Spin start-up, in the Spin adapter. Main's IABTechLab#1036 loads settings from the config store with secret resolution, which fixes the same start-up failure this branch's Spin commit fixed. Main's loader is taken and SpinPlatformConfigStore, which nothing else uses, is removed. The four adapters keep this branch's composition-root provider check, and Axum, Cloudflare and Spin keep its error propagation from build_ec_context, alongside main's compiled auction plan from IABTechLab#1016. Tests. Main's collision-retry tests and its orphan-rotation tests built their context with no provider selected, which main's code did not need. They now select the built-in HMAC provider, as an HMAC deployment does, because with no provider there is nothing to create or rotate. No other test reaches identifier creation or orphan recovery without a provider selected. Tests from each side were moved onto the other side's interfaces, being this branch's six-parameter context helpers, main's mutable context in ec_finalize_response, and the [ec.providers.hmac] passphrase in main's two secret validation tests.
Main's IABTechLab#1016 builds the orchestrator and the integration registry from a compiled auction plan, and limits IntegrationRegistry::new to core's own tests. The merge of main moved the Axum adapter's state building onto the plan and took main's imports, but missed the test helper state_with_uninjected_provider, which still called build_orchestrator and IntegrationRegistry::new, so the adapter's library tests stopped compiling. The helper now builds both from the plan, the same way build_state_with_settings does.
Brings upd/split/1-ec-provider at cb28ad3, which carries main at 066ea3c, into split/2-device-geo. Six files conflicted, all where this branch's host signals meet main's compiled auction plan or main's imports. Each resolution keeps both sides' changes, so nothing either side does is dropped. The Axum, Cloudflare and Spin adapters keep this branch's provider calls, which pass the host signals (None in all three) as well as the injected provider, with this branch's comments saying so. They then build the orchestrator and the integration registry from main's compiled auction plan, the way split/1 does. The Fastly imports keep what each side still uses. app.rs keeps main's StoreName alongside this branch's build_geo_provider and FastlyHostSignals. main.rs drops the config_store_name import, because main replaced its only use with the runtime store names, and keeps this branch's device provider import. platform.rs keeps main's BackendNamingPolicy and drops GeoInfo and PlatformGeo, which this branch moved into the trusted-server-geo-fastly crate.
Main's IABTechLab#1036 resolves secret settings from the secret store by the paths TrustedServerAppConfig::secret_fields lists, and push validation skips the validators on those paths because they hold key names. Merging main registered the [ec.providers.hmac] passphrase, but not this branch's [ec.providers.host-signals] passphrase. A key name there failed the passphrase length check when the configuration was pushed, and a key name long enough to pass would have been used unresolved as the HMAC key. The path is now listed as an optional secret and checked as a key name. EdgeZero matches secret paths against validation error keys verbatim, and the derived validation keyed the block's errors by the Rust field name host_signals, so EcProviders now validates each built-in block under the key the configuration uses. New tests cover pushing a host-signals key name, resolving one from the mapped store, and still rejecting a short resolved value.
Brings upd/split/2-device-geo at 0832f00, which carries main at 066ea3c through split/1, into split/3-permissions. Eleven files conflicted, and CLAUDE.md changed type. Most resolutions keep both sides. Four needed a decision, recorded here so that no behavior changes silently. Withdrawal, in ec/finalize.rs. Main's IABTechLab#1113 moved the path for a request whose Edge Cookie is not permitted into finalize_unusable_consent, and tells that path whether the request withdraws with ec_consent_withdrawn, which looks for an explicit withdrawal signal in the consent context. This branch decides withdrawal in the permission model, where the signal providers answer it when the permissions are assembled, and reads the answer with storage_withdrawn. Main's hardened path is kept whole and is given storage_withdrawn as that answer. Of the shipped schemes only a TCF record refusing storage withdraws, and only where the storage baseline is not granted. On main, has_explicit_ec_withdrawal also treats a Global Privacy Control, GPP or US Privacy sale opt-out in a US state as a withdrawal. On this branch those opt-outs suppress without withdrawing, as the permission model spec records, so the Edge Cookie headers are stripped and the cookie is kept. The identifier sent to auction partners, in auction/endpoints.rs and publisher.rs. Main's IABTechLab#885 makes the identifier an owned value so the identity-graph snapshot can be written back to the context, and on the navigation path keeps the active identifier unfiltered for the snapshot preload and finalization. This branch forwards the identifier only when sharing is permitted, being storage plus personalized-ad selection, the same pair that gates EIDs. Both are kept. The snapshot preload still reads the active identifier, and only the forwarded copy is gated by sharing. Settings validation, in settings.rs. Main's IABTechLab#1117 removed the warning about disabled creative rewriting, because request-time settings loading logged it on every request. The warning stays removed. This branch's log of the permission baseline sits in the same function and would repeat for the same reason, so it now logs at debug level rather than info. The template cache harness. Main rewrote the configuration edits with a replace_once helper that stops on a missing target. This branch's switch to the platform geo provider, which gives the harness a US state jurisdiction now that default_country is retired, is written the same way. The harness fastly.toml gets main's local backend and secret stores as well as this branch's Viceroy geolocation answer. CLAUDE.md is a symlink to AGENTS.md on main (IABTechLab#923). The 80 lines this branch added to CLAUDE.md are applied to AGENTS.md instead, and CLAUDE.md stays the symlink. The four adapters build main's compiled auction plan (IABTechLab#1016) and then this branch's permission signal providers. The example configuration keeps this branch's [permission_signal] notes and main's asset proxy example. Tests. Main's endpoint tests from IABTechLab#885 and IABTechLab#1016 called the test helper with a jurisdiction, where this branch's helper takes the permission gate. They now build a non-regulated context with the gate open, which is what their jurisdiction gave them on main. Main's withdrawal tests from IABTechLab#885 and IABTechLab#1113 used a Global Privacy Control opt-out as the withdrawal. They now use a TCF record refusing storage and state the withdrawal answer, as this branch's withdrawal tests do because core links no provider, and what they check, the tombstone and cookie handling, is unchanged. This branch's own opt-out test, which now passes main's mutable context, keeps the case where an opt-out leaves the cookie in place. Main's asset proxy test from IABTechLab#742 sets this branch's permissions_script field to None, and its settings acknowledge single-jurisdiction operation, which this branch requires of an Edge Cookie provider with no geo provider.
The Windows notes said CI runs the adapter tests on both ubuntu-latest and windows-latest. No job in this branch's test workflow runs on Windows, so the sentence now says ubuntu-latest. The notes also say that trusted-server-cli does not build on a Windows host, because its dependency edgezero-adapter-fastly uses a standard library feature that is unstable on Windows, so its tests and the template cache harness, which builds it, run in WSL too.
Brings upd/split/3-permissions at 3c9f4b0, which carries main at 066ea3c through split/1, split/2 and split/3, into split/4-client-resolve. Two files conflicted. Each resolution keeps both sides' changes. ec/finalize.rs takes main's imports for identity-graph writes and EID collection, and keeps this branch's expire_ec_resolved_marker beside them. This branch's two resolved-marker tests from ee07418 sit beside main's orphan-recovery tests from IABTechLab#885, and now pass main's mutable context to ec_finalize_response. docs/guide/api-reference.md keeps this branch's section for the POST /_ts/api/v1/ec/resolve endpoint and drops the POST /third-party/ad section, which main's IABTechLab#1016 removed.
Brings upd/split/4-client-resolve at 69e7d57, which carries main at 066ea3c through split/1 to split/4, into split/5-response-hook-docs. Five files conflicted, all in the documentation set and the example configuration, and all for one reason. This branch documents split/1's move of the Edge Cookie passphrase under [ec.providers.hmac] behind provider = "hmac", still as a plaintext value, while main's IABTechLab#1036 made the passphrase the name of a secret-store key. Every resolution keeps this branch's layout with main's key-name model. In configuration.md, ec-setup-guide.md, error-reference.md and fastly.md, the TOML examples select provider = "hmac" with passphrase = "ec_passphrase" under [ec.providers.hmac], and the environment overrides use TRUSTED_SERVER__EC__PROVIDERS__HMAC__PASSPHRASE with the key name. Three examples merged cleanly with the plaintext placeholder still under [ec.providers.hmac] and take the key name too. The [ec.providers.hmac] reference table gains main's note that the passphrase is a key name, and its passphrase row says so. The security, staging and placeholder bullets are main's, because this branch's bullets described plaintext values in environment variables. The validation bullets keep this branch's provider bullet and take main's three, naming providers.hmac.passphrase. trusted-server.example.toml keeps this branch's host-signal provider block with a key-name placeholder, because that passphrase is also resolved from the secret store (a75571d on split/2), and takes main's partner comment.
The example configuration said the host-signal provider creates the identifier from the host's TLS JA4 and HTTP/2 signals instead of the client IP. HostSignalProvider::generate hashes the JA4 and HTTP/2 signals together with the client IP, as the provider's own documentation says, so the comment now says so.
The configuration guide said a failed geo lookup at request time does not fall back to default_country, a setting that no longer exists. The sentence now says what a failed lookup does without naming it.
Christian Pavilonis's review thread on provider response effects asked core to validate them against the managed ts- cookies, the x-ts- namespace and framing headers. The check is in place, but several comments said a rejected effect "fails the request", which is not what happens. EcContext::generate_if_needed returns the error, and its only two callers outside tests, the publisher fallback in the Fastly adapter and IntegrationRegistry::handle_proxy, log it and serve the response without an Edge Cookie. The reserved_response_effect and apply_provider_response_headers docs, the comment in EcContext::candidate_id and the reserved-surface test now say that. The candidate_id comment no longer implies the rejection matches the identifier-bounds check in every respect, because that check runs after the provider's headers are captured. A new test, a_rejected_provider_effect_never_reaches_the_finalized_response, proves a rejected header never reaches the response. For each reserved effect it lets generation fail, runs EC finalization on the same context, and checks the response carries no forged ts-ec cookie, no x-ts-ec header and no transfer-encoding. It failed when the header capture in candidate_id was moved ahead of the reserved check, and passes with the code as it is. The test helper now hands back the context even when generation fails, so the test can finalize on it. The review thread is IABTechLab#1043 (comment)
Christian Pavilonis's review thread on partner paths asked for validation and KV normalization to be dispatched by provider code. Validation already was, but several paths still read or wrote identity graph rows under the identifier as issued, while generation stores each row under the owning provider's canonical form. For a provider whose canonical form differs from the cookie value those paths found no row. - Pull sync validated the identifier but kept only the raw value. It looked the request snapshot up under that value, while generation binds the snapshot to the canonical key and every read EC finalization makes uses that key, so it skipped every partner. Its revalidation read and write-back used the raw value too. - The admin lookup answered 404 for a row that exists. - The /auction, publisher navigation and /_ts/page-bids preloads loaded a miss, and resolve_auction_eids matched the snapshot by the raw identifier, so auctions carried no server-side EIDs. - The navigation preload also replaced the snapshot generation had just bound to the canonical key with that miss, so a newly created identifier got no ts-ec cookie on a navigation with no EID cookies to ingest. Pull sync now carries the canonical key and uses it for the request snapshot lookup, the revalidation read and the write-back. Partners still receive the identifier as issued, and the pull rate limit key still hashes the issued identifier, which leaves rate limiting unchanged for every provider. The admin lookup reads under the key, reports the requested identifier as ec_id, and adds the key it read as kv_key, which the API reference now describes. The three preloads load under EcContext::ec_kv_key and resolve_auction_eids looks the entry up under the key. EcContext::accepts_id lost its only caller and is removed. For the built-in HMAC provider the canonical key is the identifier itself for every identifier read-back accepts, so these paths behave as before for HMAC cookies. Apart from the new kv_key field, the one change an HMAC deployment can see is that an admin lookup given an identifier with an uppercase hash now finds the row stored under the lowercase key instead of answering 404. Each path has a test using CanonicalizingProvider, whose identifier t0ca~MiXeD.CaseId is stored under t0ca~mixed.caseid, and all seven new tests failed before the fix. The shared constants for that identifier now live beside the provider, so the identify, finalization and new tests use one definition. The known-gap note on EcContext::kv_key_for, which cited commit 343ac3e from outside this branch, and the matching note on AcceptedProviders now state which paths key rows through the canonical form. The review thread is IABTechLab#1043 (comment)
Some comments added for the two review threads on provider response effects and canonical keying claimed more than the code does, and one changed comparison had no test that depended on it. The AcceptedProviders doc said pull sync, batch sync and the admin lookup all read and write rows, but the admin lookup only reads. The comment in the test a_rejected_provider_effect_never_reaches_the_finalized_response said a rejected header kept anywhere on the context would reach the browser, when EC finalization applies only the response headers the context holds. The admin lookup docs and the API reference entry for kv_key named the owning provider as the source of the row key, which does not hold for a deployment with no provider selected, where the built-in HMAC identifier format supplies the key. Three other comments now say precisely what they mean. The EcContext::kv_key_for doc names the function each reference points at, the EcContext::candidate_id comment no longer credits an unnamed caller with serving the response, and the dispatch_pull_sync doc names ec_hash as the input to the rate limit key. Before replacing the snapshot that generation bound, the publisher navigation preload compares that snapshot with its fresh read. The comparison is keyed by the canonical key, yet the navigation tests for a provider whose canonical key differs from the cookie value passed with it keyed by the identifier as issued, because their stores returned the row on the first read. The test for a newly created identifier's cookie now also runs against a store whose first point read misses the row generation just wrote. With the comparison keyed by the identifier as issued, the preload replaced the snapshot with that miss, EC finalization skipped the cookie and the test failed. With the canonical key the test passes.
Main's configuration-driven OpenRTB auction providers (IABTechLab#1016) added three startup tests each to the Cloudflare and Spin adapters, and their settings set the deprecated [ec] passphrase with no geo provider. That form migrates to provider = "hmac", and on this branch GeoConfig::validate_jurisdiction_acknowledgment requires [geo] assume_single_jurisdiction = true for an Edge Cookie provider with no geo provider, so the settings failed to load and all six tests failed. The four settings blocks now set it, as the other test settings in both adapters that select an Edge Cookie provider already do.
A provider's own response headers, such as an evidence cookie, reached the browser even when generation discarded the candidate they came with. EcContext::candidate_id kept the headers before checking the identifier against the cookie bounds, and generate_with_provider left them on the context when the candidate collided with an existing row or its row could not be written. EC finalization applies whatever headers the context holds, and the publisher and integration proxies log a generation error and still serve the response, so the cookie went out with no identifier stored for it. candidate_id now keeps the headers only once the identifier has passed the bounds check, or when the provider produced no identifier at all, and generate_with_provider drops them with a colliding or unpersisted candidate. The reserved-surface check asked for in the review thread on provider response effects already ran before any header was kept, so the same rule now also holds when the identifier is rejected, when it collides and when its row cannot be written. A test covers each of those three cases, and all three failed before the change with the provider's cookie on the finalized response. HeaderSettingProvider now takes the identifier it returns, so a test can pair a permitted header with an identifier outside the cookie-safe alphabet. The finalization comment on applying provider headers now names candidate_id as the place they are checked, where it named generate_with_provider. The review thread is IABTechLab#1043 (comment)
The API reference said the explicit admin EC lookup route accepts an EC
ID in the bare {64 lowercase hex}.{6 alphanumeric} form. The route
accepts whatever AcceptedProviders::canonical_kv_key accepts, which is
an identifier created by the selected provider, such as the built-in
HMAC provider's hmac~ form, and the bare legacy form that provider
still reads, with both HMAC forms accepted when no provider is
selected. The hash may be given in either case, because
canonical_kv_key lowercases it before the check.
The note on retiring the legacy bare reader said a page view with
ts-eids or sharedId cookies runs ingest_eid_cookies in
ec_finalize_response and so restarts the row's one-year clock. Main's
change threading the EC KV read through the request (IABTechLab#885) moved
finalization to collect_eid_cookie_updates and
upsert_partner_ids_from_snapshot, which writes nothing unless a partner
ID is added or changed. The note now names that function and says only
such a view restarts the clock.
Brings upd/split/1-ec-provider at 1b88e42 into split/2-device-geo. The five commits this branch lacked, on top of the cb28ad3 it already had, answer two review threads on IABTechLab#1043 and correct what reviewing those answers found. - Pull sync, the admin lookup, /auction, the publisher navigation preload and /_ts/page-bids read and write identity-graph rows under the owning provider's canonical key (0e7f7eb and fb1bc28). - The docs on a rejected provider effect say generation returns an error and the page is served without an Edge Cookie, with a test that a rejected header never reaches the finalized response (0980b73). - A provider response's headers are kept only for a candidate that generation commits (cb6f717). - The API reference lists the admin lookup's accepted EC ID forms, and the bare reader note names the function that writes EID updates (1b88e42). The merge had no conflicts. The merged tree passes a native all-targets check, 2,763 core tests, the Axum, Cloudflare and Spin tests and the three wasm checks.
Brings upd/split/2-device-geo at 37eadae, which carries the split/1 review follow-ups (0980b73, 0e7f7eb, fb1bc28, cb6f717 and 1b88e42), into split/3-permissions. Two blocks conflicted. - The build_pull_sync_context doc keeps this branch's statement that pull sync needs the sharing permission pair, and adds the follow-up's case where no provider this deployment reads owns the identifier. - In handle_publisher_request the forwarded identifier keeps this branch's ec_sharing_allowed() filter, and the follow-up's active_kv_key line goes in front of it, so the navigation preload reads and compares the row under the canonical key. One test needed a change without a textual conflict. The follow-up's auction_endpoint_loads_the_row_under_the_canonical_key built its context with make_ec_context(Jurisdiction::NonRegulated, ...), and on this branch that helper takes the permission gate as a bool. The test now uses this branch's make_non_regulated_ec_context, which opens the gate in a non-regulated jurisdiction. The other new tests build their context with EcContext::new_for_test, which on this branch grants storage and personalized-ad selection, so they pass the sharing gate unchanged. Tests. The merged tree passes a native all-targets check, 2,851 core tests, the Axum, Cloudflare and Spin adapter tests, the permission signal crate tests, and the Fastly, Cloudflare and Spin wasm checks.
Brings upd/split/3-permissions at e3bb4b9 into split/4-client-resolve. That carries the split/1 review follow-ups (0980b73, 0e7f7eb, fb1bc28, cb6f717 and 1b88e42), their merge into split/3 under that branch's permission gate, and split/3's be0ed2d, which lets the Cloudflare and Spin startup tests from main's IABTechLab#1016 load under the single-jurisdiction rule. This branch carries the same four settings blocks, so it takes that fix here. The merge had no conflicts. The resolve endpoint already applies a provider's response headers only with the 200 that sets the cookie or the 204 when the provider creates nothing, which is the rule cb6f717 brings to organic generation, so nothing in resolve.rs changes. Tests. The merged tree passes a native all-targets check, 2,885 core tests, the Axum, Cloudflare and Spin adapter tests, the permission signal crate tests, and the Fastly, Cloudflare and Spin wasm checks.
Brings upd/split/4-client-resolve at 2c34be4 into split/5-response-hook-docs. That carries the split/1 review follow-ups (0980b73, 0e7f7eb, fb1bc28, cb6f717 and 1b88e42) through split/2, split/3 and split/4, and split/3's be0ed2d fix for the Cloudflare and Spin startup tests, whose four settings blocks this branch carries too. One block conflicted, the admin lookup sentence in docs/guide/api-reference.md. This branch added the hmac~ prefix to main's {64 lowercase hex}.{6 alphanumeric} sentence, and split/1's 1b88e42 rewrote the same sentence to list every form the route accepts, being an identifier from the selected provider such as the hmac~ form, the bare legacy form the HMAC provider still reads, and both HMAC forms when no provider is selected. That sentence covers what this branch added, so it is kept. Tests. The merged tree passes a native all-targets check, 2,885 core tests, the Axum, Cloudflare and Spin adapter tests, the permission signal crate tests, and the Fastly, Cloudflare and Spin wasm checks, and Prettier accepts the resolved API reference.
The inspector calls `assemble_permissions`, which this branch later gave two more arguments, the request evidence and the signal providers. Nothing caught it, because `tools/permissions-inspector/wasm` is deliberately its own workspace, so the gates that build the main workspace never build it, and the `Permissions Inspector` workflow that does is added by this branch too and so first ran on this pull request. It failed with three E0061 errors. The inspector now builds the same four providers every adapter offers, in the same default order (`gpc`, `gpp-sale-opt-out`, `us-privacy`, `tcf`), and hands them to `assemble_permissions`. Passing an empty slice would have compiled just as well and silently stopped the page acting on any signal at all, which is the one thing the page exists to show. The evidence argument is an empty `OwnedRequestInfo`. The page carries no request, only the consent signals its form collects, and each of the four providers answers from the consent record rather than from request evidence, so empty evidence changes none of their answers. The comment in `eval_json` says so, and says that a provider reading a header or a cookie would need real evidence there. The lock file picks up the four crates, and with them the edgezero v0.0.7 to v0.0.8 bump and `cssparser`, which this separate lock had not taken from the `main` merge. `build.rs` and one line of `src/lib.rs` are rustfmt output. The crate is outside the workspace, so `cargo fmt --all` never reached it and `build.rs` had never been formatted. Tests. `./scripts/build-inspector-wasm.sh` builds clean for wasm32-unknown-unknown, and `cargo fmt --check` on the crate is clean.
Brings upd/split/3-permissions at 88a7482 into split/4-client-resolve. That carries the one commit which makes `tools/permissions-inspector/wasm` pass the request evidence and the signal providers to `assemble_permissions`, and which formats the crate. This branch carries the same inspector and the same `Permissions Inspector` workflow, so it failed the same way. The merge had no conflicts and touches only the four files under `tools/permissions-inspector/wasm`. Tests. `./scripts/build-inspector-wasm.sh` builds clean for wasm32-unknown-unknown on this tree, and `cargo fmt --check` on the crate is clean.
Brings upd/split/4-client-resolve at b7dd13f into split/5-response-hook-docs. That carries split/3's 88a7482, which makes `tools/permissions-inspector/wasm` pass the request evidence and the signal providers to `assemble_permissions`, and which formats the crate. This branch carries the same inspector and the same `Permissions Inspector` workflow, so it failed the same way. The merge had no conflicts and touches only the four files under `tools/permissions-inspector/wasm`. Tests. `./scripts/build-inspector-wasm.sh` builds clean for wasm32-unknown-unknown on this tree, and `cargo fmt --check` on the crate is clean.
The deploy check of the inspect patterns now sees every secret leaf the settings load resolves, including a labeled Edge Cookie block's passphrase and a module's declared secrets. A show pattern naming one of them is refused at ts config validate as it is at startup. A test covers both kinds. Comments in the inspection code now state each rule once, and the API reference says the data page answers 403 on a plain http host other than localhost.
An operator's response_headers replaced headers of the same name as the response was finalized, so a site-wide Content-Security-Policy removed the sandbox from /_ts/data and a page that opened it could read the record. The data page now marks its headers as required, and core sets them again after the operator's headers on every adapter.
# Conflicts: # crates/trusted-server-core/src/auction/endpoints.rs # crates/trusted-server-core/src/ec/finalize.rs # crates/trusted-server-core/src/test_support.rs
# Conflicts: # crates/trusted-server-adapter-fastly/src/main.rs # crates/trusted-server-core/src/test_support.rs
main's new EID persistence gate is the permission model's sharing check. EIDs are written to the identity graph only when the storage and personalised-ad permissions are both set, the pair that already gates the bid request, so allows_eid_persistence and its parity test are removed and the tests that described Purpose 4 denial state the permissions instead.
main's rule that partner EIDs are written to the identity graph only with consent for personalised ads is stated in the guides as the storage and personalised-ad permissions, the pair the permission model already uses for sharing.
…d run the Cloudflare auction test with no demand modules The build script's TRUSTED_SERVER__GIT_VERSION reaches test processes and the strict loader refused it as an unknown field. Cloudflare runs one demand source at a time, so the fixture's two demand modules stopped worker startup.
jwrosewell
marked this pull request as ready for review
October 14, 2026 12:35
This was referenced Oct 14, 2026
Collaborator
|
Moved into this repository as #1350, one branch of the stack, so the review continues there. This pull request is closed in its favor and its comments stay here for the record. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacks on the one module context (#1293). The additions that follow the seven pull requests open here are listed in #777.
Compare
split/8-module-contextwithsplit/9-visibility-endpointsto see only this pull request's change.
A deployment shows what it runs and what it decided, with no credential, at three addresses that are the same on every deployment. A publisher can point a reader, a regulator or an auditor at them.
What this pull request does
/_ts/permissionsand/_ts/permissions.json/_ts/configand/_ts/config.json/_ts/dataOne handler in core answers each address on all four adapters, and a parity test checks each. All three are read only. On Fastly each answers before the Edge Cookie lifecycle, so no cookie is set and no identity row is written.
The permissions endpoint
The answer is the evaluation a page receives as
window.tsjs.permissions, with three things added that a person asking why a permission is not set needs and a page does not, being whether storage was explicitly withdrawn, which signal modules the publisher configured and which of them contributed a signal, and the version that answered.It resolves the request's state as a page's is resolved and writes nothing for the reader. The answer is never stored.
The configuration endpoint
It shows the settings the deployment holds after defaults are applied, with values masked as
XXXXand every masked path listed.Three kinds of value are masked.
The publisher decides with a new
[inspect]section, which holdsshow,hideandconfig = false, the last of which answers404. A pattern that would not be honored as written refuses the configuration, both when a deployment is validated and when the settings load, so a publisher cannot believe a value is hidden when it is shown.A stored document is unchanged. The marking that lets the view find sensitive values is a mode of one serialization call, every other serialization writes what it wrote before, and the
[inspect]section is left out of a document unless the publisher wrote one.Both are readable from any origin
/_ts/permissionsand/_ts/configboth answerAccess-Control-Allow-Origin: *, so another site can render them. A request from another origin carries no cookies, so that site reads the permissions of a request with no stored signal.The data endpoint
The page shows the identity graph record stored against the identifier in the request's own
ts-eccookie, as it is stored, being when it was made, the consent recorded, the location and device class kept, and which partners hold an identifier of their own for the same browser.The Edge Cookie is
HttpOnly, so a script on the page cannot read the identifier, and the page does not undo that.Sec-Fetch-Mode: navigateandSec-Fetch-Dest: document. Anything else is answered403. A browser sendsSec-Fetch-*only to a trustworthy origin, so every browser on a plainhttp://host other than localhost is answered403too.Content-Security-Policy: sandbox, so the document has an origin of its own and a page that opened it cannot read it. The adapters set it again after the operator'sresponse_headers, so a site-wideContent-Security-Policycannot remove it.XXXX.device.h2_fp_hashanddevice.ja4_classare shown unmasked, as the record holds them.These were checked in Chrome against a server on localhost answering by the same rule with the same headers. A page's
fetch, the same with the two headers set by the script, a frame and an embedded object were each answered403. A page that opened the address withwindow.opencould not read it, and could once the sandbox policy was left out.So two parties other than the reader can read the page. The first is a service worker the publisher's own site registers for the whole site, and the second is whoever holds an identifier and sends it as the cookie with both headers. Neither finds an identifier in the page, which is why none is shown.
A test lists every field the record has, so a field added to the record fails that test until it is decided whether the field is an identifier.
Only the Fastly adapter keeps an identity graph, so Axum, Cloudflare and Spin answer that nothing is held.
Why
Nothing let a reader, a regulator or an auditor see what a deployment runs and what it decided, so each had to take the publisher's word for it.
What breaks
resolve_secret_references_withnow returnsResult<ResolvedSecrets, _>, the record of where the secrets went, in place ofResult<(), _>.How it was verified
On
1c02104bd, locally: format, Clippy with warnings denied on the six adapter targets,trusted-server-core(2,617 passed), Fastly under Viceroy (3,628), Axum with the module crates (900), Cloudflare (52) and Spin (87). CI passed on the fork on the head,a085a3ce7. CI has not run here, because the branch conflicts withmain.Closes #1268.