# WebBrain: read the page before handing over the controls
- Author: RomanMotion (https://wurk.fun/user/RomanMotion)
- Published: 2026-11-04
- Canonical (HTML): https://wurk.fun/blog/webbrain-read-the-page-before-handing-over-the-controls
- Cover image: https://ik.imagekit.io/wurk/browser-uploads/f1c626b5c17e7f0a61dfbbe7a20d85ae7b33a20527243aeec2ee1d0a8b87562a/9340d63a-ff5b-4ef5-a934-63200a98f913/1-2026-11-04-webbrain-browser-agent-data-boundaries-hero-1200.jpg?wurkUpload=v1.jA2xiOn8Ha1aYH8ZsrjLKnjp3buPqOimo-8HbpMiQW8
---
By Jack Gross. Originally published November 4, 2026 on [Jack Gross](https://jackgross-five.vercel.app/posts/webbrain-browser-agent-read-before-act).
A browser assistant can read a product table and save ten minutes. The same extension can also inherit a signed-in browser session and reach controls that change somebody's account. WebBrain puts those two uses in a sidebar. Before handing it a real task, decide which pages it may see, where their contents will go, and what counts as a finished action.
The [HowtoWebDev Short](https://youtube.com/shorts/4WGIzwJkw2o?si=i7lSz5AimkWSSzxt) names one project: WebBrain. Its description links the [WebBrain repository](https://github.com/webbrain-one/webbrain). The pitch covers page chat, extraction and automation with local models or an OpenAI-compatible endpoint. The current project has more moving parts than that short introduction can explain.
This is a source review of the public documentation, manifests and license checked on November 4, 2026. I did not install the extension, run its browser tasks or measure its accuracy. The trial below is a proposed acceptance check with invented data.
## What WebBrain puts beside the page
The [README](https://github.com/webbrain-one/webbrain) describes a browser extension for Chrome and Firefox, with installation links for Chrome, Firefox and Edge. Ask mode reads and answers questions; Act adds browser interaction such as clicking and typing; Dev exposes additional diagnostic and editing capabilities. A task runs through a loop: read page evidence, ask the configured model for the next step, execute an allowed tool, then read the result.
That makes a sidebar useful for work that already lives in a web page. A researcher might extract a comparison table with source links. A developer might inspect a test form in a disposable environment. Saved workflows can preserve a successful sequence for later reuse. These are plausible applications of the documented tools, not results from my own runs.
The distinction between reading and acting should be visible in the task itself. "List these products" needs no submission. "Fill this test form and stop before Submit" names a boundary the reviewer can inspect. A general instruction to "handle this website" leaves too much room for an agent to decide what the person meant.
## A local model changes one part of the data path
The [privacy and data-flow document](https://github.com/webbrain-one/webbrain/blob/main/docs/privacy-and-data-flow.md) says provider requests can include the question, page URL and title, extracted page content, tool history and, when vision is used, screenshots. Cloud inference therefore means sending browser context to the chosen provider. A locally installed extension does not by itself make those requests local.
The document distinguishes local runtimes, bring-your-own cloud providers and WebBrain Compass, its managed route. It also warns that a local OpenAI-compatible proxy can forward context upstream. Inspect the gateway as well as the address the extension calls. A loopback URL is useful evidence about the first hop; it says nothing about a relay's next destination.
There are separate settings to inspect. The documentation describes an optional research-sharing switch for bring-your-own providers, off by default, and Compass retention and improvement rules. Help Improve WebBrain is on by default for Compass; check that setting before using its managed route. Assistive models have their own roles. Selecting a local decision model does not automatically move the main conversation model onto the device. Review the main provider, vision provider and any enabled auxiliary route before introducing sensitive content.
```text
Page evidence + task
|
+-- Local runtime: inspect endpoint and any relay
|
+-- Cloud provider: page context leaves the device
Tool result returns to the conversation for the next step.
```
This is a conceptual sketch, not a packet capture. For an initial trial, use public or synthetic pages in a browser profile without personal sessions. Do not put passwords or API keys into the conversation. The project's own data-flow table allows that credentials can reach a provider when they appear in chat or tool results.
## Permissions deserve their own review
The current [Chrome manifest](https://github.com/webbrain-one/webbrain/blob/main/src/chrome/manifest.json) includes broad host access and capabilities such as debugging, downloads, clipboard access and cookies. These capabilities enable useful automation, but also increase what a faulty or misdirected extension could reach. An installation permission and an approval for a particular action are different decisions.
The [security model](https://github.com/webbrain-one/webbrain/blob/main/docs/security-model.md) documents mode restrictions, capability-and-origin permission prompts and credential-handling controls. It also describes limitations in secret redaction. Read these as the project's stated controls, not an independent security certification. A source review cannot establish that every path implements them correctly or that a model will always resist hostile page text.
My practical recommendation is a dedicated trial profile with no banking, personal mail or production administration sessions. Start with Ask. Move to Act only on a disposable form where an unintended click has no outside consequence. Keep a way to inspect the page's final state independently of the assistant's completion message.
## Chrome and Firefox are different test targets
The README explicitly describes Firefox as weaker than Chrome for several interactions. Chrome can use DevTools Protocol-backed events and deeper page inspection. The Firefox build lacks equivalent capabilities in areas such as closed shadow roots and trusted mouse events; some reactive interfaces can therefore behave differently. The [architecture document](https://github.com/webbrain-one/webbrain/blob/main/docs/architecture.md) explains the build split.
A task that works in one browser is not evidence for the other. If a workflow relies on a custom widget, test the exact browser and widget together. Record whether the page changed and whether the saved value survives a reload. A convincing click animation is weak evidence when the application never accepted the value.
## A small trial with a checkable answer
Use a synthetic product table before connecting a real account. Save this explanatory fixture as an HTML file and open it in the trial profile. It has no scripts, network requests or submission target. I have not run this fixture through WebBrain.
```html
Browser extraction fixture
Invented product records
| SKU | Price USD | Stock |
|---|
| A-17 | 12.50 | available |
| B-08 | 7.00 | unavailable |
| C-42 | 19.25 | available |
```
Ask for JSON containing only available SKUs and their numeric prices. The expected rows are A-17 at 12.50 and C-42 at 19.25. Check the output against the visible table yourself. A fabricated product or inclusion of B-08 fails the extraction, even if the response is neatly formatted.
For an action trial, use a separate throwaway form with no backend and request field entry without submission. Inspect both fields and confirm that the agent stops before the final control. Repeat with an unavailable field and check whether it reports the limitation instead of claiming success. These checks separate reading accuracy from control over browser actions; neither establishes safety for payments or production work.
## License and cost need separate answers
The repository's [LICENSE](https://github.com/webbrain-one/webbrain/blob/main/LICENSE) says WebBrain 33.0.0 and later is GPL version 3 or later. The README connects that choice to its bundled Xapian/libzim WebAssembly runtime. The fetched [Chrome Web Store description](https://chromewebstore.google.com/detail/webbrain/ljhijonmfahplgbbacgcfnaihbjljhhb) still contains an MIT line. For the current source tree, use the repository license and investigate the exact artifact before redistribution. Do not assume old store copy settles its terms.
Free extension code also does not settle inference cost. Cloud API usage depends on the provider's terms; local inference needs suitable hardware and model downloads. The Short's subscription-free framing fits some setups, but it cannot promise every provider or workload costs nothing.
My assessment: WebBrain is worth a controlled look for page reading and bounded, inspectable browser tasks. Start with the synthetic extraction, record the provider and permission settings, then test the particular browser interaction you need. Keep the accepted output and the observed page state alongside the exact installed version. Those records are more useful than a general claim that the agent "worked."
## Sources
*
*
*
*
*
*
*
*
## Optional tools for your own projects
Advertisement / referral links. We may receive referral credit. For a separate coding workflow, [try ZCode free through this invitation](https://zcode.z.ai/invite/ALWM9JUA). Complete the invitation onboarding steps and check current eligibility. This is not a WebBrain feature or integration.
[Check the Coding Plan referral discount](https://z.ai/subscribe?ic=R0K78RJKNW). Confirm included models, eligibility and the final discount at checkout. Standard API usage is billed separately.