9.3 Browser Safety Settings and Extension Risks
The Origin Sandbox
The browser's core defense is the origin: scheme, host, and port together. Scripts on one origin cannot read the DOM, local storage, IndexedDB, or service worker cache of another, and cross-origin frames expose only a narrow surface -- postMessage channels and a handful of read-only attributes. The isolation is enforced by the rendering engine, and modern browsers back it with process separation so a compromised renderer for one site cannot trivially read another's memory. Nearly every browser setting worth touching is really a dial on how much cross-origin contact is tolerated.
Cookies, Storage, and the Tracking Layer
Cookies are scoped by domain suffix and path, so a page on a.example.com can send cookies set for example.com; the effective-toplevel-domain boundary is what tracking protection operates on. SameSite=Lax and Strict stop cookies riding along on cross-site requests, and third-party storage is increasingly partitioned per top-site so an embedded widget gets a separate jar. Sandbox tracking layers are what these controls target: cross-site local storage beacons, canvas and font fingerprinting, and CNAME-flared embeds that masquerade as first-party to escape blocking. A strict default -- block third-party cookies, enhanced tracking protection, forget-on-close -- degrades some embeds and is the right trade.
Permissions and Powerful APIs
Powerful capabilities are gated behind an origin allowlist plus a user gesture. Geolocation, camera, microphone, notifications, clipboard reads, serial and USB access all require an explicit grant, and transient activation blocks silent prompts. Secure-context rules make the strongest APIs (service workers, crypto.subtle, geolocation) unavailable over plaintext HTTP. Turn on HTTPS-Only mode, deny notifications by default (they are a support-scam delivery channel), require a click before autoplay, and periodically audit the permission list per site -- grants accumulate silently and are almost never legitimately needed.
Extension Privileges Are the Real Boundary Break
An extension is user-installed code the browser trusts, running outside the per-origin box. Manifest V3 gives it a privileged background service worker plus content scripts injected into pages matching its host_permissions. Grant <all_urls> and the extension sees every DOM: reading form fields, observing navigation, mutating pages, rewriting links, and with declarativeNetRequest or legacy request permissions watching every network call. chrome.runtime.connectNative goes further, spawning a local binary that escapes the browser entirely. Supply chain dominates: extensions change owners, get listed for sale, and ship minified bundles nobody diffs, so a clean utility becomes an ad-injecting or credential-reading one in a routine update.
Practical Posture
Keep the extension count as close to zero as the workflow allows, prefer one capability per need, review requested hosts rather than clicking through, disable extension access in incognito, and check the last-updated date and permission diff before installing anything. Use a separate profile or container identities for banking versus browsing, disable card autofill, and clear cookies on exit.
Architecture Diagram
Key Takeaways
- Origin isolation (scheme + host + port) is the browser's primary containment mechanism, backed by process separation.
- Cookie
SameSiteand storage partitioning are what actually blunt cross-site tracking and beacons. - Powerful APIs need a secure context plus an explicit grant and user gesture; audit grants, deny notifications.
- Broad host permissions let content scripts read forms and rewrite pages everywhere; native messaging escapes to the OS.
- Extensions are a supply chain: ownership changes and opaque updates turn trusted tools into risks -- minimize count, verify permissions.