Why do a hosted browser provider's settings arrive as one colon-prefixed capability map?

## The specification leaves exactly one door open A WebDriver `New Session` request is not a free-form settings bag. The W3C WebDriver specification defines a **table of standard capabilities** — the browser's name and version, the platform, the page load strategy, the proxy configuration and a few more — and that table is closed. Which keys sit in it, and how a client negotiates them, is capability negotiation's subject; what matters here is that you cannot add a row. For everything outside the table the spec defines the **extension capability**: an extra capability *"used to provide configuration or fulfill other vendor-specific needs"*, whose key **must contain a `:` (colon) character**, denoting an implementation-specific namespace. The value may be arbitrary JSON. That is the entire mechanism, and every non-standard setting you have ever sent to a browser or a grid went through it. ## Why an intermediary is the spec's own example The spec's illustration of what extension capabilities are for names two consumers: they are *"typically used to provide UA or intermediary node specific configuration that is not handled by the table of standard capabilities."* An **intermediary node** is the spec's term for something that sits in the request path, accepts a `New Session` and routes it onward to an **endpoint node** that owns the actual browser. A hosted browser provider is exactly that. So the namespaced map is not a vendor's stylistic choice — it is the only shape the standard offers something in that position. That produces a recognisable pattern across products that never coordinated: - Selenoid — unmaintained, per its own README — reads its per-session settings from `selenoid:options`. - Selenium Grid uses its own `se:` namespace for grid-level concerns. - Browser vendors do the same thing one hop further down for engine options. - A hosted provider does it for account, run-labelling and capture settings. Four different owners, one shared rule, because the specification gave them one shared door. ## Why one key rather than many The colon rule alone would permit a provider to send several top-level namespaced keys. In practice the settings arrive as a single prefixed key whose value is an object. Three reasons stack up: 1. **Stripping is one operation.** An intermediary must not forward its own extension capabilities to the endpoint node, and removing one key is trivially correct where removing a scattered set risks missing one. 2. **The namespace stays stable while the vocabulary moves.** New settings appear inside the object without any new top-level key, so nothing on the wire changes shape. 3. **The grouping documents ownership.** Reading a request, a single prefixed object says plainly which hop each setting is aimed at — the browser's own options map is visibly separate. ## What the map is not Being inside a namespace does not make a setting privileged or validated: - Nothing checks the *contents* of a namespace you do not own. A misspelling inside the object is accepted and ignored. - Nothing in the specification checks the prefix, so an invented namespace is as legal on the wire as a real one — though a client library's own key filter may be fussier about its shape. - The map is still ordinary capabilities data, so it travels in `alwaysMatch` or in a `firstMatch` entry like anything else. ## The same setting, both spellings The documentation of Selenoid (unmaintained, per its own README) shows the two forms side by side and states the reason for the second in as many words: some clients will carry only capabilities the specification names, so the namespaced spelling exists so that a strict client can still deliver a non-standard setting. The pair is worth memorising because it is the whole idea in two lines — the same value, once as a loose key that only a lenient client will carry, once wrapped in a namespace that everything will carry. Concretely, for a school-timetabling web app whose weekly grid needs a wide viewport to render without clipping, the request either carries a bare resolution key that a strict client refuses to send, or the same value inside the owning namespace, which every hop carries whether or not it understands it. ## What to take into an interview The answer that lands is short and mechanical: - The standard capability table is **closed**. - Anything else must be an **extension capability**, and its key **must contain a colon**. - A hosted provider is an **intermediary node**, which is one of the two cases the spec names for extension capabilities. - Therefore the provider's settings arrive namespaced, and grouping them under one key makes them removable in one step before the request continues to the browser. Notice what that answer never needs: the name of any particular provider's prefix, or any key inside it. The shape is a consequence of the standard, and you can explain it completely without knowing a single vendor's vocabulary — which is also why the shape has stayed stable while individual vendors' settings have not.