Web Introducer and Capability URL Architecture

1. Protocol Actors and Non-Ambient Trust Model

Traditional cross-site integrations rely on either third-party script tags (importing foreign JavaScript directly into the host origin) or OAuth redirects paired with persistent third-party cookies. Both models violate least privilege: embedded scripts inherit full DOM access inside the publisher origin, while redirect flows leak the user's preferred service providers and browsing history across domains.

The Web Introducer architecture separates participants into three strictly isolated roles:

• Customer: Web content in origin A that needs access to a user's personal resource (such as a bookmark store, local printer, or television receiver) without knowing in advance which host provides it.
• Provider: An origin B previously registered by the user via Registration metadata, capable of offering typed capabilities filtered by data-type MIME or URI identifiers.
• Introducer (User-Agent Broker): The browser mediation layer that displays candidate Providers privately to the user, executes Customer filtering without exposing the installed list back to the Customer, and connects the selected pair inside an isolated frame or full-size trusted-path window.

2. W3C Web & TV Local Device Discovery Citation

On 14 April 2011, Dave Raggett posted to the W3C Web and TV Interest Group (public-web-and-tv/2011Apr/0092.html) evaluating how consumer electronics running UPnP, Bonjour, or mDNS discovery protocols could expose capabilities safely to browser scripts. Raggett cited http://web-send.org/introducer/ directly because Web Introducer prevented web pages from silently fingerprinting a user's local LAN hardware.

In a naive local-discovery API, any visited web page can enumerate every television, NAS, or consumer media receiver on a home subnet. Under Web Introducer's Provider Filtering rule, the browser matches the Customer's requested wanted service types locally inside trusted chrome and reveals a Provider endpoint only after an explicit user click. Today, that exact privacy boundary motivates Chrome's Local Network Access permission prompt and the W3C Presentation API.

Conformance Actors, Registration Schema, and Filtering Invariants

Section 2 of the February 2011 Web Introducer draft separates normative conformance into three distinct roles: the Registrant (a service origin declaring a Registration object), the Customer (an origin invoking navigator.introducer.introduce()), and the User-Agent (the browser mediating selection). A conforming Registrant declares its endpoint metadata including an action URI, supported accept MIME or protocol types, a human-readable title, an icon URL, and an optional window presentation hint indicating whether the Provider expects an inline container or a full-size top-level browsing context.

When a Customer invokes introduce(layout, wanted, callback), the first argument supplies a layout hint for the mediation prompt, the second passes an array of requested data-type strings, and the third registers a callback fired only after the user selects a Provider or cancels the prompt. Crucially, the User-Agent performs all Provider Filtering locally against the wanted array without returning non-matching Registrations or exposing which Providers a user has installed. If the user dismisses the picker, the Customer learns nothing beyond cancellation, preserving complete Preference Privacy.

Once the user chooses a Provider, Section 8 (Provider Loading) establishes an isolated execution environment according to the Provider's registered presentation mode. Either the User-Agent instantiates a constrained inline widget frame with zero access to the Customer's cookies and DOM, or it opens a full-size top-level window that gives the user an unspoofable address bar. The Customer receives an Introduction handle bound to an asynchronous MessagePort, allowing full-duplex, zero-sleep-power message exchange without ever sharing ambient credentials or leaking browsing history across origins.

3. Capability Delegation Sequence

4. Evolution Matrix: Web Introducer to 2026 Browser APIs

Although the navigator.introducer shim was superseded by native platform intents and privacy-preserving federation specs, every security invariant defined in Tyler Close's draft reappeared in modern W3C and WHATWG standards.

5. Reference Invocation & Safe Origin Check

Whether implementing a legacy introducer.js polyfill or modern window.postMessage capability exchange, receivers must treat the incoming message port or event origin as untrusted until matched against an exact serialized origin string:

// Strict origin verification for capability handoff
window.addEventListener("message", function (event) {
  if (event.origin !== "https://trusted-customer.example") {
    return;
  }
  const capabilityFragment = typeof event.data?.cap === "string" ? event.data.cap : "";
  if (!/^[0-9a-f]{32,64}$/i.test(capabilityFragment)) {
    return;
  }
  // Bind request strictly to explicit capability token; ignore ambient cookies
});

For the link-sharing implementation and the 19-point protocol scorecard cited by Tor Project, continue to Bookmark Introducer & Scorecard, or test how browser storage partitioning alters capability handoffs in the Isolation Sandbox.