Architecture Overview

Early Draft

This specification is at an early draft stage. Ideas are open for change and debate. A lot of the content was developed with the help of Claude AI.

Architecture Overview

Technology Foundation

Vera is a direct Chromium fork, the same architecture used by Brave, Microsoft Edge, and Opera. Chromium runs as a single process; all Vera-specific code lives in a clean /vera/ directory alongside the Chromium source tree. Only three minimal patches are maintained against Chromium itself.

This decision has one clear reason: fast and cost-efficient implementation. Vera adds no new process layer. All features (request enrichment, 402 handling, dialogs, status bar) are native Chromium components hooked into well-defined extension points.

What this means in practice:

• Chromium update = git rebase upstream/main, then review 3 patches
• No separate app process, no IPC layer, no custom build system
• The same method Brave uses for its wallet and ad-blocking, and Edge uses for Copilot
• 1 senior Chromium engineer is sufficient for integration, not 2-3

Fork Structure

vera-browser/
├── CHROMIUM_VERSION           <- Version pin (e.g. 124.0.6367.60)
│
├── vera/                      <- All Vera-specific code (new)
│   │
│   ├── core/
│   │   ├── token_store.cc     <- Vera SSO JWT: store, retrieve, refresh
│   │   ├── verify_provider.cc <- Network verification signal management and caching
│   │   └── wallet.cc          <- Wallet API client (PPR, wallet)
│   │
│   ├── network/
│   │   └── header_injector.cc <- User-Agent + X-Vera-Token + X-Vera-Verify
│   │
│   ├── browser/
│   │   ├── response_handler.cc <- 402 interceptor -> native dialog
│   │   ├── content_filter.cc   <- Popup/SEO block (client-side fallback)
│   │   └── status_bar.cc       <- Vera status bar in the browser chrome
│   │
│   └── ui/
│       ├── payment_dialog/     <- PPR and subscription selection dialog
│       ├── consent_center/     <- Vera consent UI
│       └── account_panel/      <- Vera account, active subscriptions, wallet
│
└── patches/                   <- Minimal Chromium patches (3 total)
    ├── 001-user-agent.patch    <- Register hook in URLRequest stack
    ├── 002-402-throttle.patch  <- Register NavigationThrottle
    └── 003-status-bar.patch    <- Status bar slot in browser chrome

The Chromium source is never modified directly; only at the three patch locations, each under 50 lines.

The Two Chromium Extension Points

Vera hooks into two well-defined, stable Chromium interfaces. Both have existed for years and are used identically by Edge, Brave, and Opera.

Extension Point 1: URLRequest (Request Enrichment)

net/url_request/url_request.h provides a delegate hook called before every outgoing request. Vera uses this to attach the three headers:

// vera/network/header_injector.cc

class VeraHeaderInjector : public net::URLRequest::Delegate {
 public:
  void OnBeforeSendHeaders(net::URLRequest* request,
                           net::HttpRequestHeaders* headers) override {

    // 1. Set Vera User-Agent
    headers->SetHeader(
        net::HttpRequestHeaders::kUserAgent,
        base::StrCat({"Vera/", kVeraVersion,
                      " (Chromium/", GetChromiumVersion(),
                      "; ", GetPlatformString(), ")"})
    );

    // 2. Attach identity token (audience = current domain)
    const std::string host  = request->url().host();
    const std::string token = VeraTokenStore::GetInstance()->GetToken(host);
    if (!token.empty()) {
      headers->SetHeader("X-Vera-Token", token);
    }

    // 3. Attach network verification signal (if available)
    const std::string verify_signal = NetworkVerifyProvider::GetInstance()->GetSignal();
    if (!verify_signal.empty()) {
      headers->SetHeader("X-Vera-Verify", verify_signal);
    }
  }
};

patch 001 (< 10 lines): Registers VeraHeaderInjector in URLRequestContext.

Extension Point 2: NavigationThrottle (Response Handling)

content/browser/navigation_throttle.h allows intercepting navigations after a response is received, before the page is rendered. Vera uses this to catch 402 responses:

// vera/browser/response_handler.cc

class VeraResponseHandler : public content::NavigationThrottle {
 public:
  ThrottleCheckResult WillProcessResponse() override {
    const net::HttpResponseHeaders* headers =
        navigation_handle()->GetResponseHeaders();

    if (!headers || headers->response_code() != 402) {
      return PROCEED;
    }

    std::string vera_access;
    if (headers->GetNormalizedHeader("X-Vera-Access", &vera_access)) {
      // Show native Vera dialog — do NOT render the page
      ShowVeraPaymentDialog(vera_access);
      return CANCEL;
    }

    // No X-Vera-Access header: pass through normally
    return PROCEED;
  }

 private:
  void ShowVeraPaymentDialog(const std::string& access_json) {
    // Native dialog — no WebView, no JavaScript
    VeraPaymentDialogController::Show(
        navigation_handle()->GetWebContents(),
        VeraAccessOptions::Parse(access_json)
    );
  }
};

patch 002 (< 15 lines): Registers VeraResponseHandler in NavigationThrottleRunner.

System Diagram

+----------------------------------------------------------+
|                    VERA BROWSER                          |
|                                                          |
|  +------------------+    +---------------------------+  |
|  |   Browser Chrome  |    |    Chromium Renderer      |  |
|  |  (native code)    |    |  (unchanged except for    |  |
|  |                   |    |   3 minimal patches)      |  |
|  |  [Vera Status Bar]|    |                           |  |
|  |  [Payment Dialog] |    |  net/    <- header_inj.   |  |
|  |  [Consent Center] |    |  content/<- resp_handler  |  |
|  |  [Account Panel]  |    |  chrome/ <- status_bar    |  |
|  +------------------+    +---------------------------+  |
|                                    |                     |
|             vera/core/             |                     |
|        +-----------+-----------+   |                     |
|        |           |           |   |                     |
|  token_store  verify_provider  wallet                    |
+----------------------------------------------------------+
        |               |              |
        v               v              v
   +---------+   +----------+   +---------+
   |  Vera   |   |  Network |   |  Vera   |
   |  SSO    |   |  Verify  |   | Wallet  |
   | (Ident/ |   |  (Human  |   | (Subs/  |
   | Consent)|   |  Verify) |   |  PPR)   |
   +---------+   +----------+   +---------+

The Three-Channel Model

The core architectural principle of Vera: one request, three possible delivery paths. The channel decision is made by the publisher server based on the Vera headers, not by the browser.

Incoming request to publisher
          |
          v
   +----------------------------+
   |  Header inspection         |
   |  User-Agent: Vera/* ?      |
   |  X-Facilitator present ?   |
   |  No Accept-Language ?      |
   +----------------------------+
          |
    +-----+----------+------------------+
    v                v                  v
+--------+      +---------+       +----------+
|  VERA  |      |  AGENT  |       | STANDARD |
| HUMAN  |      | TRAFFIC |       | BROWSER  |
|        |      |         |       |          |
| SSO    |      |   403   |       | Classic  |
| Wallet |      | blocked |       | paywall  |
| VRP    |      |         |       |          |
| HTML   |      |    —    |       |  HTML    |
+--------+      +---------+       +----------+

Comparison with Other Chromium Forks

Browser	Own Patches	Own Directory	Separate Process
Vera	3	/vera/	No
Brave	~500	/brave/	No
Microsoft Edge	~200	/components/edge/	No
Opera	~150	/opera/	No
Arc	~100	/arc/	No

Vera is deliberately at the lean end of this spectrum. This is not a compromise; it is the goal. Fewer patches mean faster Chromium updates, lower maintenance costs, and a smaller team.