The first Chromium-based browser with local-first Agentic AI and hardware-bound cryptography. Your data never leaves your device. Ever.
Built from the ground up with security-first architecture and cutting-edge cryptography
Native Apple Silicon optimization with deep Secure Enclave integration for hardware-backed security impossible on other platforms.
Learn moreRun any GGUF or CoreML model from Hugging Face. BYOM architecture with automatic quantization and hot-swap capability.
Learn more256-bit AES with keys derived inside Secure Enclave. Three-tier key hierarchy with boot attestation and anti-tamper protection.
Learn moreNIST-standardized ML-KEM (Kyber) and ML-DSA (Dilithium) with hybrid classical/post-quantum key exchange.
Learn moreTLS 1.3 with X25519Kyber768 hybrid key exchange. DoH, ECH, and traffic analysis resistance built-in.
Learn moreNetwork-level blocking with bloom filters, CNAME uncloaking, scriptlet injection, and comprehensive fingerprint protection.
Learn moreSee how Dart Browser stacks up against the competition
Our journey to delivering the most secure browser on the planet
Ironclad storage engine with Secure Enclave key derivation. Chromium fork with privacy patches. Internal dogfooding begins.
Neural Engine integration. BYOM architecture with llama.cpp and MLX backends. Local vector database for RAG-based page chat.
Rigorous code-level security audit begins, led by DeepStrike Security. Closed beta program launches for waitlist members.
Mac App Store release. Post-quantum TLS by default. Full multi-model orchestration with agentic browsing capabilities.
Available on the Apple App Store starting Q3 2026
Complete privacy suite for power users
No payment required until launch. Cancel anytime.
We're assembling a world-class team to redefine what a browser can be
Lead the development of our Chromium fork's core engine, focusing on performance optimization, memory management, and deep integration with our privacy-first architecture.
Architect and build our hardware-bound encryption system (Ironclad Locker) using Rust and WebAssembly. Implement post-quantum cryptographic algorithms.
Define and drive the product vision for Dart Browser. Balance user experience with uncompromising security.
Build and optimize our on-device AI capabilities. Work on model quantization, inference optimization for Apple Silicon.
Create the best native macOS browser experience. Integrate deeply with Apple's ecosystem, implement Keychain and Secure Enclave features.
Technical deep-dives into how Dart Browser works
Yes. Dart's BYOM (Bring Your Own Model) architecture supports any GGUF or MLX-format model from Hugging Face. When you paste a repo ID (e.g., TheBloke/deepseek-coder-6.7B-instruct-GGUF), Dart:
1. Fetches metadata from the Hugging Face API, identifying available quantizations (Q4_K_M, Q5_K_S, Q8_0, F16).
2. Auto-selects quantization based on your unified memory: 8GB → Q4_K_M (~4GB for 7B), 16GB → Q5_K_S (~5GB), 32GB+ → Q8_0 (~8GB).
3. Verifies integrity via SHA256 hash comparison against Hugging Face's published hash, preventing supply-chain attacks.
4. Memory-maps weights using mmap() with MAP_PRIVATE—pages load on-demand, reducing cold-start by 60%.
Hot-swap (⌘+Shift+M): Because weights are memory-mapped (not loaded into private memory), switching models means munmap() + mmap() on different files. KV-cache clears, new model loads in <2 seconds.
Inference pipeline: Tokenization → Embedding → Transformer layers (ANE for ≤7B, GPU via Metal for larger) → Sampling → Detokenization. We achieve ~35 tok/s on M2 Air (7B Q4), ~60+ tok/s on M3 Max (7B Q8).
Dart depends on hardware security features with no cross-platform equivalent:
Secure Enclave Processor (SEP): Dedicated ARM core with isolated encrypted memory. Generates and stores encryption keys that physically cannot be extracted. Windows TPM connects via slow LPC/SPI bus; Android TrustZone shares memory with main CPU. Neither matches SEP's isolation.
Unified Memory Architecture (UMA): CPU, GPU, and Neural Engine share memory without copying. AI inference path: page content → Neural Engine → response with zero memcpy(). This provides 3-4x lower latency and 40% better battery vs. discrete GPU architectures.
Neural Engine (ANE): 16-core matrix accelerator (15.8-31.6 TOPS). Optimized for transformer attention patterns. We offload attention + KV-cache to ANE, freeing GPU for rendering.
Pointer Authentication (PAC): ARM64e cryptographically signs all pointers. ROP/JOP attacks require forging PAC signatures—effectively impossible without the signing key.
Metal Performance Shaders: Our llama.cpp fork uses custom MPS kernels for quantized matmul that outperform generic CUDA on equivalent TFLOPs.
Ironclad Locker uses a three-tier key hierarchy with Secure Enclave as root of trust:
Hardware Root Key (HRK): 256-bit key generated inside SEP at first launch using hardware RNG. Never leaves SEP—only used as HKDF input for derivation operations.
Device Encryption Key (DEK): Derived via HKDF-SHA256(HRK || UID || salt) where UID is the Secure Enclave's unique identifier fused into silicon during manufacturing. Cannot be computed on any other device.
Data Encryption Keys: Per-file 256-bit AES keys, wrapped (encrypted) by DEK. Stored alongside ciphertext. Unwrapping requires SEP operation—physically impossible on different hardware.
Boot attestation: Before releasing DEK, SEP verifies: Secure Boot enabled → signed bootloader → signed kernel → SIP active → FileVault on. If attestation fails (modified OS, external boot), DEK remains sealed.
Anti-tamper: SEP monitors voltage, temperature, and light. Physical probing attempts trigger permanent HRK destruction—data becomes unrecoverable by design.
Encryption scheme: AES-256-GCM with random 96-bit nonces. AAD includes filepath + timestamp, detecting file relocation attacks.
We implement NIST's 2024 post-quantum standards to defeat "Harvest Now, Decrypt Later" attacks:
ML-KEM (CRYSTALS-Kyber): Lattice-based key encapsulation for TLS. Security relies on Module Learning With Errors (MLWE). Kyber-768 provides 192-bit post-quantum security. Public key: 1,184 bytes. Ciphertext: 1,088 bytes. Encapsulation: ~0.1ms on Apple Silicon.
ML-DSA (CRYSTALS-Dilithium): Lattice-based signatures for code signing and certificates. Dilithium-3 for 192-bit security. Signature: 3,293 bytes. Sign: ~0.3ms. Verify: ~0.1ms.
SLH-DSA (SPHINCS+): Hash-based signatures for long-term integrity. Security relies only on hash collision resistance—the strongest security proof of any PQ algorithm.
Hybrid approach: TLS uses X25519Kyber768—classical X25519 combined with Kyber. If Kyber broken by cryptanalysis → X25519 protects. If quantum breaks X25519 → Kyber protects. Both must fail for compromise.
Implementation: liboqs (Open Quantum Safe) with constant-time guarantees. Integrated into BoringSSL. ~2KB additional per TLS handshake—imperceptible on modern connections.
DeepStrike Security will be conducting our pre-launch audit starting in Q2 2026. They specialize in hardware security modules, cryptographic implementations, and secure enclave integrations. Scope includes:
Cryptographic implementation review: Line-by-line analysis of AES-256-GCM, HKDF key derivation, Kyber/Dilithium implementations. Verifying constant-time operations, correct nonce handling, side-channel resistance.
Secure Enclave integration: Review of SEP communication layer, key attestation flow, hardware binding mechanism. Analysis of boot attestation and anti-tamper response.
Memory safety: Rust components verified using Kani and MIRI for absence of undefined behavior. C++ Chromium integration points reviewed for use-after-free, buffer overflows, type confusion.
AI isolation: Verification that LLM inference runs sandboxed with minimal permissions, cannot access arbitrary files, and that prompt injection cannot escape AI context without user confirmation.
Network security: TLS 1.3 + post-quantum implementation, certificate validation, DoH configuration reviewed for downgrade and MITM vulnerabilities.
Chrome extensions with "read all sites" permission can inject scripts, intercept requests, and access cookies across all domains. Dart's model is fundamentally different:
Origin-isolated execution: Extensions run in per-origin sandboxes. Extension activated on gmail.com cannot access bankofamerica.com data, even with broad permissions.
Capability-based permissions: Extensions request specific capabilities ("read page content on this domain," "modify these headers for this API"). Users grant individually; enforced at browser engine level.
No HTTPS interception: Extensions cannot see or modify encrypted request/response bodies. Only whitelisted headers accessible. HttpOnly and SameSite=Strict cookies invisible.
No remote code: Extensions cannot load external scripts. All code bundled at install, signed, reviewed. Prevents post-install supply-chain attacks.
AI firewall: If you use local AI to "summarize page" or "fill form," actions are logged and displayed before execution. Extensions cannot invoke AI actions without visible user confirmation—prevents prompt injection exfiltration.