What it is, in plain terms
ITISYOU Browser is a desktop web browser I am building on top of Chromium, the same open-source engine underneath most major browsers. It is currently at version 0.1.0-dev, and it is in development, not released: there is no installer, nothing to download, and no date for when there might be. What exists today is Phase 1 of a plan with four phases, and Phase 1 — the foundation — is complete on Windows. Linux and macOS are not yet verified. Phases 2, 3 and 4 have not started.
In practical terms, that means the browser I have today genuinely renders real web pages over real HTTPS connections, in tabs, with back and forward and reload working, with the Chromium security sandbox switched on rather than disabled for convenience, and with an AI system built into the code but currently making zero calls to any AI provider anywhere. It is a real, working thing you could point at a website and watch it load — it is just not yet a finished product, and it is not something I am distributing.
I keep a public site for this project at browse.itisyou.app, which states its own status honestly: Phase 1 of 4, foundation complete, no releases yet, nothing to download. That site is a public engineering record, not a demo or a download page.
Why I built it
I wanted to find out whether it is possible to build a real, functioning browser where the privacy and safety boundaries — what a web page can and cannot touch, whether an AI feature can silently reach out to a server, whether one tab can affect another — are designed in from the very first working build, rather than added as a later hardening pass once a product already exists and has users depending on it.
A specific instinct behind this project is that a lot of browsers today treat AI as something to bolt onto an existing product, with broad access to browsing history and behaviour granted by default because it is convenient for the feature to have it. I wanted to try the opposite ordering: build the browser to be fully useful with AI structurally absent, and only ever let AI in later behind a boundary that has to be deliberately opened rather than one that starts open and has to be deliberately closed.
None of this is a claim that the finished product will be better than existing browsers, or that it will ever ship widely. It is the question this phase of the project was built to test, and the honest answer so far is that the foundation can be built this way — that is what Phase 1 demonstrates, no more and no less.
The problem underneath
A browser sits in a genuinely difficult position: its entire job is to render content from strangers, at speed, while keeping that content from ever touching anything it should not. Every browser built on a serious engine like Chromium already does a great deal of this well — process separation between tabs, a sandbox around the part of the program that parses untrusted content, and so on. The part that is easy to get wrong is everything layered on top of that foundation: a custom internal settings interface, a command palette, an AI assistant, workspace data — any of these can accidentally create a shortcut that lets untrusted web content reach something it should never see, if the boundary between "the browser's own trusted interface" and "a web page" is not enforced as strictly as the boundary Chromium already enforces for you.
That is precisely the category of problem this project ran into and fixed during Phase 1, described below, and it is the reason I think the underlying question — can these boundaries hold up under scrutiny from day one, rather than being patched in after the fact — is worth spending real engineering time answering properly rather than assuming.
How it works, without the jargon
The browser is built using the Chromium Embedded Framework, a way of taking the real Chromium engine — the actual code that renders web pages, runs JavaScript, and keeps different pages isolated from each other — and wrapping a custom interface around it, rather than writing a browser engine from scratch or using a lighter-weight substitute that does not carry Chromium's full security model. When you open a tab, that tab is a genuine, isolated Chromium browser view; the security separation between the part of the program that talks to the operating system and the part that renders potentially hostile web content is the same separation Chromium ships with, not a simplified stand-in.
On top of that engine sits the browser's own interface — the tab strip, the address bar, a command palette, and a handful of internal pages like history and settings. Those internal pages are served from a separate, privileged address scheme that ordinary web content cannot reach, is not allowed to load inside an iframe, and can only be talked to by code running in that same privileged context. That separation exists specifically so a hostile website cannot pretend to be part of the browser's own interface, or sneak a request through to something a web page should never be able to touch.
Anything that touches your data locally — browsing history, saved sessions, workspace state — is written to its own separate store rather than one shared file, and written using a pattern that keeps a backup copy in case the write is interrupted partway through, say by a crash or a forced shutdown. Whether a session actually comes back correctly after the browser restarts is something the automated tests check directly, rather than something I merely assume works because the code that writes it looks correct.
And the AI system, which does exist in the code as an interface, currently has only one thing plugged into that interface: a provider that is permanently disabled and makes no network calls at all. If something in the code tries to switch AI on in this phase, that attempt is rejected, and rejected honestly — the system does not pretend to comply while quietly doing nothing.
What building it taught me
The most useful thing that happened in this phase was not a feature going right, but a deliberate adversarial review after the browser was already considered functionally complete for the phase — and that review finding something real. It discovered that a hostile website could load the browser's own privileged internal pages inside an invisible iframe and, through that, reach the internal interface meant only for the browser's trusted UI to use. Nothing about the individual pieces of code looked obviously wrong on their own; the gap was in what was missing, not in what was present.
The fix, which I applied the same day it was found, was deliberately layered rather than single-point: the privileged interface pages were marked as display-isolated so other pages cannot easily reference them, a strict framing policy now refuses to let them be embedded at all, any attempt by an embedded subframe to navigate to them is blocked outright, and the internal bridge itself independently checks that a request is genuinely coming from the main frame of a privileged page before it does anything. I did that deliberately, on the theory that a single fix at a single layer is exactly the kind of thing that gets quietly bypassed later when something else changes nearby — four independent checks are harder to accidentally undo all at once.
I also learned, again, that writing the tests before the first real launch pays for itself quickly rather than eventually. The unit test suite caught three genuine bugs in the very first hour it existed as a complete suite — including one where a command's identifier was read from an object in the same expression that moved the object elsewhere in memory, and the compiler was free to do those two things in either order. It happened to move the object first, which meant every single command in the browser was silently registering under an empty identifier. That is not a bug you would necessarily notice by reading the code; it is exactly the kind of bug a test that actually exercises the running behaviour is built to catch.
A smaller but telling lesson: every tab rendering completely blank turned out to be a framework limitation rather than a bug in my own code — the underlying engine only permits one browser view of a particular hosting style per window, and the shell was quietly violating that. The fix required switching to a different view-hosting approach for the whole window, which sounds architectural and slightly alarming until you realise the actual security model — the sandbox, the process separation — was never at risk; only how views are hosted inside a window changed.
Where it stands today
Phase 1 of the plan's four phases is complete, verified on Windows on 2 September 2026. The browser builds in release mode with the Windows sandbox enabled, renders real HTTPS pages in isolated tabs, supports basic navigation and tab management, has a working command palette, a foundation for separate workspaces, local browsing history, and a permission system that denies capability requests by default. Thirty of thirty unit tests pass, and a 24-step smoke test suite that exercises the actual running binary against real websites — including the fix for the internal-page embedding issue — also passes in full, with session restoration across a process restart separately verified.
That is a genuinely functioning browser, and it is also a genuinely early one. Nothing about Phase 1 completion means the product is close to ready for anyone else to use. Linux and macOS builds are configured but have never actually been compiled or run, because I do not yet have working build environments for either. Phases 2 through 4 of the plan — which cover deeper browser services, real workspace and data systems, and whatever follows after that — have not started, and I am deliberately not detailing their scope publicly before the work exists to back it up.
The AI-off claim is one I want to be precise about, because it is easy to state weakly. It is not that AI features are hidden behind a settings toggle that happens to be off. The AI runtime's only wired-in provider in this phase is a disabled one, and the code path that would make an AI provider network call does not exist in a reachable state — attempts to enable it are refused rather than routed anywhere. That is a stronger and more specific claim than "AI is off by default", and it is the one the evidence actually supports.
Where it may go
- Next: begin Phase 2, covering browser services, workspace persistence and underlying data systems.
- Next: get a working Linux build environment in place and actually run the existing Linux build configuration for the first time, then do the same for macOS.
- Then: go beyond the framework's default Windows sandbox settings with a dedicated hardening pass.
- Then: consider extending the AI runtime past its current, permanently disabled state, only behind an explicit and reviewable boundary rather than a default that starts open.
- Later: Phases 3 and 4 of the plan, whose scope I am not detailing yet because the work to back it up does not exist.
This project shares a habit of mind with a much lower-level piece of work I am also doing, an operating-system kernel described on its own page, ITISYOU OS — both are attempts to get privilege boundaries right at the foundation, before building anything on top that would make changing them later expensive.
For developers: the engine choice and the isolation model underneath it
The browser is built on a pinned, checksum-verified binary distribution of the Chromium Embedded Framework rather than a from-source Chromium checkout. That decision was made explicitly against the constraints of the development environment at the time — a full Chromium source build needs a disk footprint the project's machine did not have — with a documented migration path to a source-based build recorded for later, should the product ever need engine-level changes the framework cannot expose. Electron was ruled out as a permanent runtime on different grounds: it is documented upstream as not designed to act as a security boundary for arbitrary untrusted content, which is disqualifying for a browser whose whole purpose is safely handling exactly that.
The browser's own interface — tabs, address bar, settings, history, diagnostics — is implemented as trusted content served over a dedicated internal address scheme, rendered in a privileged view that is kept structurally apart from ordinary web content. The bridge that lets that trusted interface call into native browser code is origin-gated, and is checked independently at more than one point: bindings that expose it are only installed for the privileged scheme in the first place, the browser process itself verifies the origin of any request that reaches it, and navigation into the privileged host from an untrusted context is blocked outright. The framing and embedding protections added after the adversarial review sit alongside these as a fourth, independent layer.
Permission handling for capabilities like camera and location access is centralised in one service that applies a default-deny policy, rather than being implemented independently wherever a given browser feature happens to need a permission check. That centralisation is what makes "default deny" an enforceable property of the whole browser instead of a convention that individual features are merely expected to follow. Local data — session state, browsing history, workspace configuration, settings — is kept in separate stores, each written with an atomic-write-and-backup pattern specifically so a write interrupted by a crash cannot leave that store, or any other, in a corrupted state; the recovery path itself is covered by unit tests rather than assumed to be correct.
Test coverage for this phase spans two layers: a unit test suite exercising the underlying C++ core in isolation — covering things like JSON parsing correctness, address-bar classification, atomic persistence and recovery, and the AI-off invariant directly — and a smoke test suite that drives the actual compiled binary against real HTTPS sites, checking navigation, tab lifecycle, workspace switching, history recording, and the specific security regression from the adversarial review. Both suites are re-run to a full pass whenever a fix like that is made, rather than trusting that a targeted fix alone is sufficient evidence.