Browser Net Stack + chrome.* Bridge + BROWSER_RFC — OS 0.7.0 Complete

Two OS-level browser commits complete the 0.7.0 OS layer. 0ecc2f6 ships the browser net stack: http_fetch.sg (HTTP/1.1 GET/POST), tls_client.sg (thin cc0 wrapper over Kernel sys 117-119), dns_client.sg (A-record lookup over sys 120), and net_test.sg (PASS integration test). 13ecc3a ships chrome_bridge.sg — the OS-level chrome.* API bridge that routes extension zone calls through cap-validated bipc IPC to the correct process, never letting the extension bypass the cap grant — plus BROWSER_RFC.md, the complete joint OS+Apps browser design contract covering multi-process cap model, tab model, session model, net stack, chrome.* bridge security, cap inspector UX, private mode, and renderer crash recovery.

Section 1: Browser net stack (`0ecc2f6`)

The browser Net process (process 3 in the 4-process model) needs three primitives: DNS to resolve hostnames, TLS to secure connections, and HTTP to fetch pages. All three are now in cc0.

http_fetch.sg — HTTP/1.1 client

HTTP in the browser runs through Cap<NetConn> (sys 110/111 net_conn_send/recv). The browser never opens raw sockets — all transport goes through the Net process's capability token.

http_fetch_build_get

Build a well-formed HTTP/1.1 GET request with Host, Connection: close, and \r\n\r\n terminator. Correct header framing — no "\n"-only line endings. Args: host, hlen, path, plen, buf.

http_fetch_build_post

Build HTTP/1.1 POST with Content-Length header. Body appended after the double CRLF. Args: host, hlen, path, plen, body, blen, buf.

http_fetch_parse_status

Parse status code from "HTTP/1.1 NNN " line. Returns 200/404/etc, or -1 on malformed response. Args: buf, blen.

http_fetch_body_off

Find body start — offset of the first byte after \r\n\r\n. Returns -1 if not found (incomplete response). Args: buf, blen.

http_fetch_content_length

Parse Content-Length header value. Returns -1 if absent. Args: buf, blen.

http_fetch_redirect_location

Parse Location header from 3xx response. Used by the HTTP_MAX_REDIRECTS recv-loop stub. Args: buf, blen, out, outlen.

tls_client.sg — Kernel TLS via sys 117-119

TLS is not implemented in EL0 cc0. It's a Kernel responsibility, called via three new syscalls:

sys 117 (tls_wrap): Upgrade an existing Cap<NetConn> to TLS. Kernel validates the certificate chain against the trusted root store. Returns -1 on any cert failure — no EL0 override of trust decisions possible.
sys 118 (tls_send): Send data over a TLS-wrapped connection. Same ABI as net_conn_send but encrypted.
sys 119 (tls_recv): Receive data from a TLS-wrapped connection. Same ABI as net_conn_recv but decrypted.

Security contract: the EL0 layer never sees the private key, the cert, or the TLS handshake internals. The Kernel holds the trust store. sys 117 = -1 on cert failure is the only outcome EL0 sees — no partial trust, no cert-bypass flag, no configurable trust level. This is structural, not policy.

dns_client.sg — A-record lookup via sys 120

sys 120 (dns_resolve)

Single A-record lookup. EL0 passes hostname + length + a 4-byte output buffer. Kernel returns the resolved IPv4 address in network byte order, or -1 on NXDOMAIN/timeout.

dns_resolve

cc0 wrapper for sys 120. Args: name, nlen, out4.

dns_format_ipv4

Format 4-byte IPv4 as "A.B.C.D\0" string. Args: addr4, buf.

dns_ipv4_to_int

Pack 4 octets into a 32-bit address for Cap<NetConn> connect. Args: a, b, c, d.

net_test.sg — PASS integration test

Check	What it verifies
DNS roundtrip	dns_resolve + dns_format_ipv4 round-trips correctly
TLS wrap stub	tls_wrap loopback returns 0 (success)
HTTP GET builder	Correct method, Host, Connection headers, CRLF framing
HTTP POST builder	Correct Content-Length, body appended after double CRLF
Status parser 200	"HTTP/1.1 200 OK\r\n..." → 200
Status parser 404	"HTTP/1.1 404 Not Found\r\n..." → 404
Status parser junk	Non-HTTP response → -1
body_off	body starts after \r\n\r\n
Content-Length	"Content-Length: 42\r\n" → 42
format_ipv4 8.8.8.8	dns_format_ipv4(0x08080808) = "8.8.8.8"
format_ipv4 127.0.0.1	dns_format_ipv4(0x0100007f) = "127.0.0.1"

PASS: NET-PASS dns=ok tls=ok http_get=ok http_post=ok status=ok body=ok cl=ok ipv4=ok

Section 2: chrome_bridge.sg — OS-level chrome.* API bridge (`13ecc3a`)

Chrome extensions expect a chrome.* JavaScript namespace. In Chrome, these calls go to the browser's extension host — a trusted process that grants permissions based on the extension's manifest. In sigilOS, the analog is chrome_bridge.sg: the OS-level bridge that intercepts extension zone chrome.* calls, validates the cap grant bitmask, and routes to the correct process via bipc IPC.

The critical difference from Chrome: validation happens OS-side, not extension-side. An extension cannot call chrome.webRequest.onBeforeRequest if it wasn't granted CHROME_CAP_WEBREQ at install time — the bridge rejects the call before any IPC is dispatched. The extension manifest can claim whatever it wants; the cap grant is what actually matters.

Cap grant bitmask

Checked before every dispatch:

CHROME_CAP_TABS — chrome.tabs.* (navigate, close, create)
CHROME_CAP_WEBREQ — chrome.webRequest.* (observe/intercept HTTP)
CHROME_CAP_STORAGE — chrome.storage.local/sync
CHROME_CAP_RUNTIME — chrome.runtime.* (messaging, lifecycle)
CHROME_CAP_HISTORY — chrome.history.* (not yet exposed in ext_zone)
CHROME_CAP_COOKIES — chrome.cookies.* (not yet exposed)

Route table

chrome.webRequest.*

→ bipc IPC_T_NET_REQ → Net process (Cap<NetConn>). The extension sees the request; the Net process decides whether to proceed. webRequest observers are read-only by default — blocking requires an additional cap flag.

chrome.tabs.*

→ bipc IPC_T_NAVIGATE / bipc IPC_T_CLOSE_TAB → Browser process (orchestrator). Tab operations go to the Browser process (process 0), not the renderer. Renderers cannot be navigated directly.

chrome.storage.*

→ bipc IPC_T_NET_REQ → Storage process (Cap<FS>). Storage reads/writes go through the FS cap gate, not directly to the filesystem.

chrome.runtime.*

In-process stub (messaging between extensions; full impl pending).

Unknown API

Immediate cap check failure, return -1. No silent pass-through.

Section 3: BROWSER_RFC.md — the complete design contract (`13ecc3a`)

BROWSER_RFC.md is the joint OS+Apps ratified design contract for the sigilOS browser. It supersedes earlier design notes and is now the canonical reference for the OS (process model, cap grants, syscalls), Apps (browser chrome, session manager, ext_manager), and Docs (chromium-parity.html, browser.html) agents.

Section	Subject	Key decision
Multi-process cap model	Browser=0 / Renderer=1+tab / GPU=2 / Net=3	Renderer gets only CAP_IPC; cannot write to display or network
Tab model	Column-browser metaphor, Smart Folder integration	`@web @recent` tag query — tabs and SRDX sessions in one view
Session model	SRDX sessions = browser sessions	`srdx://sigil-pi:5900` is a browser tab with [srdx] mode chip
Net stack	DNS sys 120, TLS sys 117-119, HTTP via Cap<NetConn>	TLS cert validation is Kernel-only; no EL0 trust override
chrome.* bridge security	Honest trust tiers, not hidden sandboxing	Cap grant validated OS-side before any IPC dispatch
Cap inspector UX	Live HELD/NOT HELD table per tab	cap_inspector.sg wired to bipc; Revoke drops cap in-session
Private mode	Structural: separate EL0 context, fs:rw removed	Kernel synchronous heap-zero on close — not policy
Renderer crash recovery	Process restart with session state preserved	Tab stays alive in browser chrome; renderer respawns
Performance targets	60fps composite, <16ms frame budget	GPU compositor path; SRDX delta ≤77KB@100Mbit measured
Sign-off checklist	Joint OS+Apps readiness gate	All items must PASS before 0.7.0 GA