Summary

  • The W3C Security Interest Group's 22 September Threat Model for the Web Draft Note redraws its high-level model around a page's Web API request to browser-controlled mediation and a separate result, event or error returning to the page.
  • The 21 September version represented the user agent as one process. The new L0 is a logical map, not a claim about how Chromium, Gecko or WebKit divides processes.
  • An API name, an origin label and an observed call do not by themselves identify where a permission decision was made or enforced. That is an editorial review implication, not a new W3C compliance test.

Consider a page that asks for a sensitive capability. Its script may make a Web API call and receive an answer, yet a reviewer of that code still cannot see the full authority path. Did browser-managed policy allow the request? Was the user asked through browser-controlled UI? Was the outcome an error? Which component protected the relevant state? A request trace is an account of what the page attempted, not a certificate of what the browser authorized.

The Security Interest Group's 22 September Draft Note gives this gap a clearer drawing. At the most abstract level, its PO-02 is the document and origin execution context. It sends DF-05, the Web API request with its arguments or options, to browser-controlled mediation PO-01. The latter returns DF-06: a value, promise settlement, event, status or error. A separate TB-02 represents the family of boundaries between web origins and contexts. User input and remote site resources remain distinguishable from those browser and document roles.

That was a real change in the publication, not the first appearance of browser security thinking. The 21 September draft's high-level model treated the user agent as a single process, P0, with browser-managed state S0 and broader flows to websites, the network and the operating system. Even then, the draft said reviewers must open the lower-level browser model when they need to locate enforcement, state or permission mediation. The 22 September revision brings the request and return across the document/browser boundary into the top-level picture itself.

The distinction matters because a specification can precisely define the syntax and outcome of a Web API while leaving a reviewer to ask which actor controls the sensitive transition. An origin-bound page has an execution context; that does not make its UI a browser prompt, or its invocation an approval. In the draft's lower-level model, privileged browser functions commonly coordinate policy and permission mediation, while content execution is exposed to untrusted web material. Network, storage and operating-system access can require further mediation.

Those are architectural roles for analysis, not a universal description of every browser build.

W3C's own status notice narrows the authority of this publication. It is a Security Interest Group-endorsed Group Note Draft, neither endorsed by W3C nor its Members, and it may change. The series began in May, not on 22 September. The threat-analysis and controls sections still mark themselves incomplete. Nothing in the two September versions proves that a named browser enforces a particular API safely, reports an exploit, or creates a new permission requirement.

The useful governance consequence is more modest and more exact. In a review, document the page's request, the browser-controlled decision, the returned result or error, and the implementation evidence for enforcement as separate observations. A model that makes the path legible helps locate the missing evidence. It cannot supply that evidence by being published.

Sources