The User, Not the Platform, Controls the Interface

A platform decides what enters a feed, how it is ranked, which controls are prominent and which forms of automation are available.

The user may select among the settings the platform offers. That is not the same as controlling the interface.

Browser AI creates the possibility of another layer: software acting locally, under rules the user can inspect, across sites and independently of one model provider.

This chapter assembles the system we have built and defines the limits of that claim.

1. Move policy toward the user

The website still publishes the application. The browser still enforces the web security model. The operating system and network remain below it.

Within those boundaries, a user-owned layer can decide:

• what to emphasize or reduce;
• which evidence to display;
• what content to label, blur or hide;
• which AI runtime may process which data;
• which tools an agent may discover;
• which effects require confirmation;
• what history is retained.

This is not absolute sovereignty. It is a meaningful relocation of decisions that otherwise belong entirely to the platform.

2. Assemble the complete architecture

    flowchart TD
    U[User goals and policies] --> C[Local coordinator]
    C --> W[Browser workers]
    W --> M[Model adapters]
    W --> X[Page and tool adapters]
    M --> E[Evidence and proposals]
    X --> E
    E --> G[Policy and authority gate]
    G --> R[Reversible interface or approved effect]
    R --> O[Observatory trace]
    O --> U
  

The coordinator accepts versioned JSON jobs and distributes them to browser workers. A worker may use Chrome’s built-in AI, an in-browser open model, a local service or an explicitly configured remote system.

Page adapters extract bounded content units. Tool adapters expose typed capabilities. Models return evidence or proposals. Deterministic policy chooses allowed actions. Consequential effects stop at the human authority boundary. The Observatory preserves the path.

No single company owns the entire architecture.

3. Make policies portable

A rule trapped inside one extension’s settings screen is fragile. A user-owned policy should have:

• a documented schema;
• stable identifiers and versions;
• explicit scopes and actions;
• declared evidence requirements;
• import and export;
• human-readable explanations;
• migration rules;
• safe handling for unsupported clauses.

Portability creates competition. Another extension or browser can implement the same policy without receiving the user’s browsing history or asking them to reconstruct every preference.

It also makes the policy reviewable. Researchers can analyze the rule itself rather than reverse-engineering hidden product behavior.

4. Make decisions inspectable

User control is weakened when automation is invisible.

The interface should answer:

What changed?
Which rule changed it?
What evidence was used?
Which runtime processed the data?
Did data leave the device?
How can I reverse this decision?

The Observatory evolves from a model debugger into a policy debugger. Its central object is no longer just a prompt trace; it is a decision trace that connects content, evidence, policy, authority and effect.

5. Reversibility is a constitutional rule

Local policy actions should prefer transformations that can be undone:

• a hidden unit leaves a placeholder;
• a summary can reveal the original;
• a ranking change can show the unmodified order;
• a blocked tool proposal remains visible in the audit view;
• remembered permissions can be revoked;
• imported policies can be disabled without deleting them.

Reversibility is useful for debugging, but it also protects the user from their own mistaken rules and from imperfect models.

Some external effects cannot be reversed. Those belong behind the authority boundary from Chapter 21, with exact confirmation before execution.

6. Defend against a personal filter bubble

A personal policy engine can reinforce bias as easily as a platform recommender can. User ownership does not guarantee good judgment.

Controls should include:

• a visible count of affected units;
• previews before enabling a broad rule;
• sampled review of hidden items;
• periodic policy review;
• false-positive feedback;
• origin and language breakdowns;
• clear distinction between evidence and inference;
• an emergency pause that restores the unmodified view.

The engine should help users understand the consequences of their policies, not merely execute them efficiently.

7. Defend the policy itself

Sites and hostile content may try to manipulate the layer that judges them.

The engine must therefore keep policy outside page-controlled text. A page may supply content, metadata and tool descriptions, but it cannot rewrite the governing rule or grant itself authority.

Policy packages should have explicit sources and integrity checks. Updates should show meaningful changes. Site-specific exceptions should be visible. Sync, if enabled, should not expose raw browsing data unnecessarily.

As in prompt-injection defense, the key protection is architectural separation—not asking a model to remember which text deserves trust.

8. Keep the provider boundary honest

Provider independence is not achieved by adding a dropdown with several company names.

Every adapter should report:

• capability and version;
• execution location;
• data route;
• model identity when available;
• context and size limits;
• cost or resource implications;
• known unsupported features;
• evidence provenance.

The coordinator can then enforce rules such as:

{
  "dataClass": "page-private",
  "allowedExecution": ["browser", "localhost"],
  "remoteFallback": false
}

A system that silently sends content to the cloud because local inference failed is not user-controlled, even if its settings page says “local first.”

9. The book has become the product specification

The progression now looks like this:

capability detection
  → sessions and resources
  → traces and evaluations
  → structured outputs
  → JSON jobs and browser workers
  → typed web tools
  → authority boundaries
  → personal interface policy

Each chapter introduced a mechanism, a failure and evidence that can reveal the failure. Together they specify a product larger than a prompt console.

Browser AI Observatory can become a user-owned browser policy runtime: part debugger, part evaluation harness, part agent inspector and part interface mediator.

The AI-origin content filter is its first opinionated application, not its final purpose.

10. What remains experimental

Several boundaries will move:

• built-in AI APIs and the models behind them;
• WebMCP registration and permission behavior;
• extension platform capabilities;
• provenance adoption;
• local model performance;
• policy portability across browsers.

That uncertainty is why the architecture depends on adapters, typed evidence, versioned policy and recorded traces.

We should expect implementation details to change. We should not accept changes that make data movement, authority or decisions less visible.

Conclusion

The browser is becoming an AI runtime, but that does not determine who benefits from the runtime.

It can become another channel through which platforms and vendors mediate the user’s experience. Or it can support software that executes locally, accepts interchangeable providers, exposes its evidence, asks for authority at the right boundary and enforces policies chosen by the user.

The second future is not automatic. It has to be engineered.

That is the larger purpose of this book. We began by asking how to call a model in Chrome. We end with a more consequential question:

Can the browser become the place where the user regains control over intelligent software and the interface it shapes?

The Observatory gives us a way to build the answer, measure it and revise it when the evidence changes.

Sources and further reading

1. W3C, WebExtensions Community Group.
2. Chrome for Developers, Extensions platform documentation.
3. Coalition for Content Provenance and Authenticity, C2PA specifications.