-
Notifications
You must be signed in to change notification settings - Fork 13
2026
- GitHub issue: https://github.com/Igalia/webengineshackfest/issues/94
- URL: https://meet.jit.si/WEH2026-web-security
- Deck: https://docs.google.com/presentation/d/11yBjV-ys4wc-MNJLdTYGouO7swEsmuIx5k1fq9kxY9c/edit?slide=id.p#slide=id.p
These notes complement the slide deck for the June 17, 2026 breakout. They focus on what participants added during the discussion, rather than repeating the Data Flow Diagram (DFD), STRIDE, Eliminate, Reduce, Transfer, and Accept (ERTA), and Geolocation examples already covered by the slides.
This is an informal session capture.
During introductions, several participants said they had not created a formal threat model, but had drawn system diagrams. The room treated that as a practical entry point: a useful diagram already gives the group something concrete to question, correct, and extend.
The wider direction also came into focus. A single threat model for the whole Web Platform would be too large to use. The working idea was a “forest” of smaller, reusable models that can be connected when a specification needs more detail.
The first missing boundary raised in the room was Web IDL: the point where JavaScript values are translated into constrained interface types before they reach the rest of an implementation. The suggestion was to make that translation step visible in the model instead of treating web content as if it passed arbitrary data straight through.
Origins and embedded contexts need more detail too. Same-origin frames, third-party frames, sandboxed frames, and Permissions Policy delegation may be clearer in focused diagrams rather than one overloaded baseline diagram. This keeps the high-level story usable while preserving the details needed for deeper review.
The discussion also reinforced a useful review habit: security-relevant controls may appear inside normative algorithms even when a Security Considerations section is brief. In the Geolocation example, document state, secure-context, allowed-use, visibility, permission, caching, acquisition, timeout, and error behavior all changed the security story.
Browser engines do not all use the same process, thread, sandbox, or privilege layout. The session therefore did not propose one browser architecture for specifications. The open question was different: can a specification state the security expectation clearly enough that each implementation can map it to its own boundaries?
The discussion used user activation as a concrete example. If a less trusted context can influence state that later leads to a privileged operation, the privileged side may need to verify that the activation is still valid rather than trust the earlier state. More generally, the model should make visible where data or authority crosses a boundary and where checks need to be repeated.
Participants discussed whether specifications should expose more of these security assumptions. Phrases such as “in parallel” can describe algorithmic behavior without showing whether work crosses a task, thread, process, or privilege boundary. A specification does not need to prescribe an architecture, but it can identify:
- security-sensitive operations;
- data that should not be trusted across a boundary;
- checks that need to occur, or occur again, before a privileged action;
- mediation expected from the user agent;
- implementation responsibilities left outside the specification.
This would make the same text more useful to editors, implementers, reviewers, and tools that derive or inspect implementation artifacts.
For implementers, security information in a specification should help answer practical questions: where a check belongs, what data remains untrusted, what operation needs mediation, what property must hold across different architectures, and what changes if a feature runs in a less isolated process. The actual solution may differ by engine or platform.
This also exposed the trade-off. Implementers may have to balance security, performance, complexity, and available resources. A useful specification records the security expectation and the consequence of weakening it, without assuming one implementation design.
The artificial intelligence (AI) discussion was more operational than the slide summary. The suggested approach was to work one step at a time: ask for a high-level diagram, check it, add trust boundaries, check them, generate questions, and then review the answers manually.
AI may help with question generation, clustering, challenging assumptions, and drafting. It can also hallucinate, go deep too early, or return long lists that take more time to verify than they save. The conclusion in the room was practical: use AI as a sparring partner, not as the author of the final security analysis.
The discussion left several concrete artifacts to explore:
- focused diagrams for the Web IDL boundary and for embedded or third-party contexts;
- clearer ways to record architecture-neutral trust-boundary expectations in specifications;
- reusable threat stories and response patterns linked back to specification text;
- more useful Security Considerations sections and threat models linked from specifications;
- guidance, prompts, or lightweight checks that authors and reviewers can use during specification development;
- future review sessions where participants bring a diagram or specification and work through it together.
The slides remain the main reference for the method itself. These notes capture the parts that came from the room and may need a separate issue, diagram, or edit before they can be reused.