bi-02 — Broader Ideas
The same problem in your systems
"Assume the client is compromised" is the browser's version of a rule every backend engineer knows and many frontend engineers do not apply consistently:
| Browser | Your system |
|---|---|
| Renderer is untrusted | the browser client is untrusted |
ProcessLock enforces identity | server-side authorisation, not client-side checks |
frame-ancestors enforced browser-side | authorisation decided server-side, never by the caller |
| Capability handed as a Mojo endpoint | scoped tokens rather than repeated permission checks |
| Rule of Two | untrusted input parsed in a memory-safe language or a sandbox |
Capability-passing is the transferable design. Instead of "may I do X?" answered repeatedly, hand out a scoped, revocable ability. That is what a signed URL, a scoped OAuth token, and a Mojo endpoint all are.
Where the cost model shows up in product decisions
Site isolation's memory cost is why it shipped on desktop before mobile. The equivalent decision in your product: what is the resource budget on the worst device you support, and what security or correctness property are you trading against it? Teams that cannot answer that ship features that work in the office and fail in the field.
Ordering hazards, generalised
Mojo's "ordering per pipe, not across pipes" is the same hazard as:
- two HTTP requests to different endpoints,
- two Kafka topics,
- two WebSocket channels,
- two
postMessagetargets.
Associated interfaces are the general fix: share a channel when you need ordering. If you find yourself adding sequence numbers to recover ordering across channels, ask whether one channel was the right design.
Next
bi-10 shows the process boundaries as observable flow arrows in a trace; bi-11 shows how work is
prioritised inside one. fw-04's tearing problem is the same consistency question one layer up.