syndeo

Syndeo represents a novel approach to web browser architecture, centering on the cache as the primary product rather than a secondary feature. The design is driven by a commitment to strict process separation and security boundaries, aiming to transform trust into verifiable truth through isolated interactions. **Architectural Foundations** The system is built around three critical load-bearing boundaries: 1. **Renderer Isolation:** Rendering processes (utilizing Servo or WebKit) are strictly prohibited from opening network sockets. Instead, they communicate with a separate network process (`syndeo-net`) via `NetRequest` objects. This prevents renderers from bypassing security policies or leaking information through network timing attacks. 2. **Agent Sandboxing:** The agent process, which executes WebAssembly tools, is isolated from the keystore. It cannot access cryptographic keys directly, significantly reducing the attack surface for malicious scripts or agents. 3. **Keystore Security:** The keystore exposes only a single operation: signing a payload. This action requires explicit confirmation from the shell, which includes a MAC over the origin, purpose, and payload hash, ensuring that consent is specific and non-transferable. **Core Components** - **`syndeo-cache`:** Implements RFC 9111 caching policies with a redb index and a BLAKE3-addressed blob store. The cache is partitioned by the top-level origin to prevent cross-site tracking via cache timing, while still allowing for efficient deduplication of content. - **`syndeo-net`:** Handles all network protocols (HTTP/1.1, HTTP/2, HTTP/3/QUIC). It integrates with the cache and provides a fetch API for the rest of the system, ensuring that all network traffic is mediated through a secure, controlled channel. - **`syndeo-peer`:** Facilitates peer-to-peer content fetching using libp2p. Peers are only requested for content that has already been identified by hash in the page, preserving privacy while enabling decentralized content distribution. - **`syndeo-keystore`:** Manages cryptographic keys with a sealed root secret protected by Argon2id. It integrates with OS-level credential stores (Keychain/Secret Service) and supports per-signature consent, automatically forgetting seeds after a period of inactivity or lock. - **`syndeo-dom`:** A headless DOM implementation used by the agent for tasks like reading prose, extracting links, and filling out forms, without the overhead of full rendering. - **`syndeo-ui`:** The graphical user interface, built with winit, wgpu, and egui. It provides a windowed shell with accessibility support and serves as the interface for user interactions and confirmations. **Privacy and Security Features** Syndeo enforces a number of privacy defaults: - **Partitioned Caching:** The cache is keyed by the top-level document's origin, effectively preventing cross-site tracking by isolating cache data between sites. - **DNS over HTTPS (DoH):** Enabled by default (with Cloudflare as the provider), ensuring that DNS queries are encrypted and secure. - **No Telemetry:** The codebase contains no analytics, crash reporting, or update pings, ensuring that user data is not collected or transmitted without explicit consent. - **Credential Stripping:** `Authorization` and `Cookie` headers are dropped when redirects cross origins, preventing the leakage of sensitive authentication information. **Usage and Installation** The project is distributed as a binary for macOS (Apple Silicon) and Linux (x86_64/arm64). Installation is performed via a shell script that verifies checksums, ensuring the integrity of the downloaded software. The system does not require `sudo` to run. Users interact with the system through a command-line interface (CLI) for tasks like browsing, running agents, and signing data, or through the graphical user interface for standard browsing activities. A proxy mode is also available for measuring cache efficiency on real-world traffic from other browsers. **Development and Future Directions** Syndeo is an active project with a focus on verifying the viability of the cache-first model. While the core architecture is in place, there are ongoing efforts to improve integration (such as supporting WebKit on macOS for video playback) and to extend support to other platforms like Windows and ChromeOS. The project includes extensive testing for RFC compliance and memory usage, ensuring that the system remains robust and efficient as it evolves.