Three origin-validation procedures for untrusted IPC values
Component: WebKit IPC | aba0fcd
In WebKit's multi-process architecture the WebContent process is the sandboxed, attacker-reachable renderer, while the UI process holds higher privilege and must not blindly trust origin values a renderer claims over IPC — which is what the IPC::Untrusted<T> wrapper exists to force. Which validation is correct depends on what ground truth the UI process actually tracks, and that varies with configuration.
This commit introduces three validation primitives that recover a trusted origin from an Untrusted<T> value — FirstPartyAuthority, TopLevelFirstPartyAuthority and CommittedClientOriginAuthority — and documents the EXTRACT_WITH_MESSAGE_CHECK macro shape callers will use. Nothing calls them yet; wiring them into real message handlers is deferred, so there is no behaviour change.
Significance
FirstPartyAuthority disables its site check entirely when site isolation is off or only one web process exists, because the ground truth it needs does not exist in that configuration. Without site isolation a single WebContent process can host a page plus every cross-site iframe it embeds, so comparing an arbitrary claimed origin against the process's recorded main-frame site cannot give a meaningful answer for subframe origins. TopLevelFirstPartyAuthority and CommittedClientOriginAuthority apply to values that are guaranteed by construction to be the process's own top-level or committed origin, so they need no such carve-out.
Audit directions
The forward-facing pattern is a validator whose strength depends on runtime configuration. Narrow: as the follow-up commits wire these into handlers, the per-call-site question is whether the chosen validator's ground truth actually covers the value being checked — a subframe origin validated by FirstPartyAuthority on a non-site-isolated build is validated by a function that has switched itself off. Wider: the three procedures form a small vocabulary, and mismatches between them are the likely error class, so audit each future call site for whether the value really is the process's own top-level or committed origin when the stronger validators are used. Widest: any validation layer with a configuration-dependent bypass needs an explicit answer for what the weaker configuration is relying on instead; in code review, a validator containing a branch that skips its own check deserves a comment naming the property that makes the skip safe.