A web browser is an application that fetches documents over the network and renders them into an interactive interface. It is also the runtime our web products actually execute inside, which makes its behaviour a practical engineering concern rather than a consumer preference.
01What a browser is made of
Underneath the interface, a browser is a set of cooperating subsystems. A networking layer resolves names and opens connections. Parsers turn HTML and CSS into a document tree and style rules. A layout engine computes the geometry of every element, and a compositor turns that geometry into pixels, usually with GPU assistance. A JavaScript engine compiles and runs page code, typically with several tiers of optimisation behind it.
Two consequences are worth knowing. First, the number of independent engine implementations is small, so several browsers that look and feel different share rendering behaviour underneath. Testing across browsers is really testing across engines, plus each vendor's own additions. Second, layout and script share a single main thread per document, which is why an expensive script blocks scrolling and animation on the same page.
02The security model
Browsers run untrusted code from arbitrary sources by design, so their security model is unusually explicit.
- Same-origin policy. Content from one origin — the combination of scheme, host and port — cannot read content from another origin by default. Nearly every browser security feature is an elaboration of this rule, and cross-origin sharing has to be granted deliberately by the server.
- Process isolation and sandboxing. Sites are separated into distinct processes with limited operating system privileges, so that a compromise of the rendering process does not automatically yield the machine.
- Transport security. The browser validates the server's certificate chain against trusted authorities before it will treat a connection as secure, and increasingly refuses or downgrades features on connections that are not.
- Permission prompts. Camera, microphone, location, notifications and similar capabilities require explicit user consent per origin, and can be revoked.
03Practical implications for our work
Browsers update continuously and largely automatically, which means the target moves. Features arrive at different times across engines, and capability detection at runtime is more reliable than inferring capability from the user agent string.
Several browser behaviours regularly surprise people building on the web. Autoplay of media with sound is restricted until the user has interacted with the page. Storage is partitioned by origin and can be cleared by the user or evicted under pressure, so nothing stored client-side is durable. Private browsing modes and tracking protections restrict or clear storage more aggressively. And extensions can modify pages before the application ever sees them, which means a bug report from a user's browser is not always a bug in the application.
Developer tools ship with every major browser and expose the network waterfall, the DOM and style computation, console output, storage inspection and performance profiling. For diagnosing a reported problem, reproducing it in a clean profile with extensions disabled is usually the fastest way to separate an application defect from a local environment issue.