Good news: It is technically possible.
Bad news: It does not work under Xenocara (OpenBSD X11 clone) with out of DRI/KMS (kernel video driver) (X access hardware using
/dev/xf86 in this case) but works on XOrg with Linux and FreeBSD. You can try if it works in your case. If you are using KMS then it will probably work.
Good news again: you do not need it because it does not increase security: web browser is X client: it runs as any regular process and uses X to display data.
X and virtual terminals.
PC video hardware is under control of OpenBSD console driver
wscons which provides several virtual terminals (
vt). When X launches, it borrows
wscons and from than moment it controls video by itself using its driver (directly using
/dev/xf86 or using KMS driver in kernel). Keyboard control is also moved from
wscons to X, so when you push CTRL+ALT+F* X asks
wscons to switch to another
wscons gets video and keyboard back. So, you can have to X running on two different
X has an option
vtXX to choose
vt to borrow. Since running X with out of client makes no sense, you could do
DISPLAY=:2 xinit xterm -- vt1 :2
-- is passed to X, so X will start on vt1. You then switch to the different
vt and run
DISPLAY=:3 xinit xterm -- vt3 :3
You now have 2 X servers. If it works, you can them configure your display manager (
xenodm on OpenBSD) to pass
vtXX option to
X, its clients and why there is no reason to run 2 X servers.
X client (be it
DISPLAY environment variable to find its
X server, connects to it and uses it to display data and read keystrokes.
So, client runs locally, it just uses different X servers to display data. Once your client hacked -- it does not matter which X server it is connected to.
PS: This is why Xenocara does not run on 2 different vts when using
vesa(4) driver: it uses
xf86(4)) to access video memory and it sets lock on this device file. So, it may work with KMS