react-x11 2.51.1 → 2.53.0

package/docs/remote.md

@@ -0,0 +1,179 @@
+# Remote display
+
+A react-x11 app **draws over the wire**. It does not render pixels and ship
+them; it sends X11 drawing requests — rectangles, glyph runs, composites —
+and the X server on the far end turns them into pixels. So running the app
+somewhere else is not a feature bolted on top: it is what the protocol is,
+and the program does not know the difference.
+
+```sh
+ssh -X buildbox
+npm start          # the window opens on your desktop
+```
+
+Nothing in the app changes. No VNC, no browser, no streaming daemon, no port
+to forward, no second copy of the UI.
+
+**This is the X11 backend**, and it is the reason X11 stays the flagship
+target: the Cocoa, win32 and Wayland backends have no wire at all, so
+nothing on this page applies to them. That matters in one case — **an app
+running on a Mac or on Windows and drawing somewhere else**. `$DISPLAY` in
+the environment does not choose the backend there; `backend: 'auto'` sees
+darwin and picks Cocoa, or win32 and picks the win32 backend, and the window
+opens on the local machine. Say which you want:
+
+```sh
+REACT_X11_BACKEND=x11 DISPLAY=thin-client:0 npm start
+```
+
+`createRoot({ display: … })` or `createRoot({ stream: … })` also settle it —
+naming an X endpoint in code _is_ choosing X11, because an ignored
+connection option would be worse than either answer. An app running on Linux
+and drawing to a Mac's XQuartz is not affected: both ends are X11 already.
+
+## What it costs, measured
+
+Bandwidth is small: **a whole window appears for about four kilobytes** of
+requests, and scrolling a 500-row table ten notches costs 11 kB, because
+only the damaged strip is redrawn — where a single frame of pixel streaming
+(VNC, RDP) is tens to hundreds of kilobytes, sent again whenever anything
+moves.
+
+What react-x11 pays instead is **latency**. A request that waits for a
+reply with nothing pipelined behind it stalls the connection for a full
+round trip, so on a 60 ms link every such reply is 60 ms of nothing. That is
+why atoms, geometry and glyph pages are cached rather than re-asked, and
+why the column to watch on a slow link is `stalls`, not `replies`:
+`npm run bench -- --hotspots` attributes them, request by request.
+
+Rules of thumb, reasoned from the request and reply counts rather than
+measured over a shaped link:
+
+- **Under ~20 ms RTT** (a LAN, a nearby VPS): indistinguishable from local.
+- **20–80 ms** (a continent away): typing and scrolling stay responsive;
+  window mapping and font setup have a visible beat.
+- **Above ~150 ms** or on a lossy link: X11's chattiness starts to show, and
+  a pixel-streaming protocol designed for high latency will feel better.
+  This is X11's limit, not react-x11's.
+
+The per-scenario numbers are in the
+[design notes](../design/remote.md#what-it-costs-measured).
+
+## `ssh -X` and `ssh -Y`
+
+`-X` runs your app as an **untrusted** X client. `-Y` runs it trusted, which
+turns the restrictions off. They are not "the one that works" and "the one
+that does not":
+
+|                                    | `-X` (untrusted) | `-Y` (trusted) |
+| ---------------------------------- | ---------------- | -------------- |
+| read other windows' pixels         | no               | yes            |
+| grab the keyboard, record input    | no               | yes            |
+| take the clipboard from other apps | restricted       | yes            |
+| your app's own windows             | fine             | fine           |
+
+**Prefer `-X`.** react-x11 should work under it — it draws into windows it
+created, which is what untrusted mode is for. If something does not, that is
+a bug worth filing rather than a reason to reach for `-Y`, which hands every
+program on the remote host the ability to read your screen and log your
+keystrokes.
+
+### The failure that looks like a crash
+
+An untrusted `-X` cookie **expires**. OpenSSH's `ForwardX11Timeout` defaults
+to 20 minutes; after that the connection is refused and your app dies
+mid-session with a connection reset — no warning, no message that mentions
+X11, and it happens long enough after startup that nobody connects the two.
+
+```sh
+# in ~/.ssh/config
+Host buildbox
+  ForwardX11 yes
+  ForwardX11Trusted no
+  ForwardX11Timeout 8h        # or 0 for no expiry
+```
+
+If a long-running app dies after roughly twenty minutes and
+`onDisconnect(reason)` reports `'error'`, this is the first thing to check.
+react-x11 tells you it happened, and nothing more —
+[a reconnect is not a reconnect](README.md):
+every window id, pixmap, glyph set and font died with the connection.
+
+## `DISPLAY=host:0` — and why not
+
+The other way to reach a remote display is to point `DISPLAY` straight at it
+and open port 6000. Do not:
+
+- The connection is **plaintext**. Every keystroke, every glyph you draw and
+  the authentication cookie itself cross the network in the clear.
+- Making it work usually means `xhost +`, which turns off access control for
+  _everyone_, or `xhost +host`, which trusts every user on that host.
+- Most X servers ship with TCP listening disabled now, so it takes
+  deliberate work to open the hole.
+
+`ssh -X` gives you the same thing, encrypted, authenticated per-session, and
+with no listening port. Use it. If you genuinely need a raw display
+connection — a lab network, a kiosk — carry the cookie explicitly with
+`xauth` and never with `xhost` (see [security.md](security.md)).
+
+## The other X servers
+
+"An X server" is broader than "a Linux desktop":
+
+| where                         | what runs                                                                                                                                    |
+| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
+| Linux desktop                 | X.Org, or **Xwayland** — see below                                                                                                           |
+| macOS                         | [XQuartz](https://www.xquartz.org). `ssh -X` from Terminal starts it for you                                                                 |
+| Windows                       | VcXsrv, Xming, or an X server inside WSLg                                                                                                    |
+| headless CI                   | `Xvfb :99 -screen 0 1280x800x24`                                                                                                             |
+| a disposable screen           | `Xephyr :10 -screen 1200x800` — a window on your desktop that _is_ a display. What the [window-manager example](../examples/README.md) needs |
+| a session you can reattach to | `Xvnc` / TigerVNC, or **Xpra**, which is X11-native and can detach and reattach a running app                                                |
+| no display at all             | node-x11's in-process server — [testing.md](testing.md)                                                                                      |
+
+**Xwayland: yes.** On a Wayland desktop, X11 clients run under Xwayland, and
+react-x11 is an ordinary X11 client there. Everything in this documentation
+applies. Some window-manager interactions are thinner (Xwayland brokers what
+the compositor is willing to expose), and `WM_TRANSIENT_FOR` and the
+`_NET_WM_STATE` work are among the things that survive the trip — see
+[elements.md](elements.md#transientfor--a-window-that-belongs-to-another).
+
+**Native Wayland: not remotely.** Wayland has no drawing protocol: a client
+renders pixels into a buffer itself and hands the compositor a handle, so
+there is no drawing to send over a wire. The
+[Wayland backend](wayland-backend.md) rasterizes locally, which is why it is
+opt-in and never what `'auto'` picks: on Linux the default stays X11, and
+with it everything on this page.
+
+**XQuartz notes**, since it is the most common macOS path:
+
+- The window manager is quartz-wm, which has the thinnest EWMH support in
+  the stack. It does not advertise `_NET_WM_STATE_ABOVE`, so `alwaysOnTop`
+  falls back to Apple-WM window levels ([elements.md](elements.md)).
+- Put `/opt/X11/bin` first on `PATH`. Font family resolution shells out to
+  `fc-match`, and Homebrew's fontconfig — which is usually found first —
+  ships no macOS system-font aliases, so `sans-serif` resolves to a CJK
+  face.
+
+## Making it feel better
+
+Everything the renderer does to be cheap locally pays double here, because
+each saved request is a saved trip across the link:
+
+- Keep repaints **bounded**. `REACT_X11_DEBUG_PAINT=full` warns, with a
+  reason and a stack, on any silent full-window repaint —
+  [debugging.md](debugging.md). A full repaint is the difference between
+  4 kB and 40 on every frame.
+- `REACT_X11_TRACE=summary` prints the request and byte counts for a live
+  app, so you can see what a given interaction actually costs on the wire
+  before blaming the link.
+- `ssh -C` compresses. X11 traffic is highly compressible — repeated
+  drawing requests, text, glyph data — and on a slow link it is usually
+  worth it.
+- Prefer one long-lived connection to many short ones: connection setup is
+  several round trips of its own, plus the font and atom warm-up.
+- **Drags across applications are round-trip heavy**, because finding the
+  foreign window under the pointer means asking the server, per pointer
+  position. Dragging _within_ the app costs nothing extra — it never
+  touches the wire — and a drop target that answers with `e.freeze()` stops
+  the source asking while the pointer stays inside it. See
+  [drag-and-drop.md](drag-and-drop.md).

package/docs/scale.md

@@ -0,0 +1,225 @@
+# Display scale
+
+Every length in react-x11 is a **logical pixel**: a unit sized so that
+`fontSize: 14` is comfortably readable at the distance the display is
+actually viewed from. On the panels of the last decade one logical pixel is
+two device pixels — or 1.5, or 1.25 — and the renderer multiplies exactly
+once, on the way to the server. An app says nothing and gets a UI the same
+physical size on a 2013 monitor and a retina laptop.
+
+```jsx
+const root = await createRoot();               // scale: 'auto' is the default
+const root = await createRoot({ scale: 2 });   // pin it
+REACT_X11_SCALE=1.5 node app.js                // the user outranks everybody
+```
+
+```jsx
+import { useScale } from 'react-x11';
+const scale = useScale(); // 1, 2, 1.5... static for the life of the root
+```
+
+## What is logical and what is device
+
+**Logical — everything application code touches:**
+
+- every style length (`width`, `padding`, `fontSize`, `borderRadius`, the
+  lengths inside `boxShadow` and gradient stops, `hitSlop`…)
+- window geometry props (`width`, `height`, `x`, `y`, `minWidth`…) and the
+  `onResize` payload
+- event coordinates: `ev.x`/`ev.y`/`ev.localX`/`ev.localY`, wheel
+  `deltaX`/`deltaY`, drag `screenX`/`screenY`
+- `getClientRects()`, `measure()`, `useScreens()` rects,
+  `anchorRect`/`centerRect`/`anchorArea`
+- the scroll surface: `scrollTo()`/`scrollBy()` arguments, `onScroll` and
+  `onViewport` payloads
+- the theme: `DefaultTheme.fontSize` is 14 and stays 14
+
+**Device — the renderer's internals and the deliberate escape hatches:**
+
+- `node.abs`, yoga's computed layout, everything painted
+- `node.scrollX`/`scrollY`/`contentWidth`/`contentHeight` read directly off
+  a ref (positions in the rendered surface; use the `onScroll` payload for
+  logical math)
+- `<canvas onDraw>`: the browser's own canvas contract — the box arrives in
+  device pixels and the payload carries `scale`, so detail is drawn on the
+  real grid. It is deliberately not pre-scaled with `ctx.scale()`: text
+  drawn through a scaled transform moves without growing.
+- a registered element's `paint()` and `hitTest()` (see
+  [extending.md](extending.md)): `this.style` and `this.abs` arrive already
+  device, and so are `paintDamage()`, the rects handed to `invalidate` and
+  `scrollContents` and the rects of an a11y scene; synthetic events are
+  logical, and `this.scale` is on every node for the constants that never
+  pass through a style and the event coordinate on its way to `abs`.
+
+Fonts are the point of the whole exercise: a `fontSize: 14` at scale 2 is
+shaped, measured and rasterized at 28px. Text on a retina panel is _sharper_,
+not bigger-blurrier.
+
+Fractional scales (`1.25`, `1.5`) work end to end, with the usual X11
+caveat: a 1-logical-px hairline at 1.25x is 1 or 2 device pixels depending
+on where it lands. Integer scales have no such seams.
+
+"Logical" is per node rather than per window as soon as a `scale` prop is in
+the tree: everything in the first list is divided by the scale of the node
+it is about, which is the display's until an enclosing `scale` says
+otherwise. See [A subtree of its own](#a-subtree-of-its-own) below.
+
+## How `'auto'` decides
+
+X11 has no scale protocol, so `'auto'` consults these in order and takes the
+first that answers:
+
+1. **Environment** — `REACT_X11_SCALE` (wins over everything, an explicit
+   `scale:` number included: it is the accessibility escape hatch), then
+   `GDK_SCALE`, then `QT_SCALE_FACTOR`.
+2. **XSETTINGS** — `Gdk/WindowScalingFactor` when it is 2+, then `Xft/DPI`:
+   what the desktop's own settings dialog writes.
+3. **`RESOURCE_MANAGER`** — `Xft.dpi`, the `xrdb` convention.
+4. **RandR millimetres** — the panel's physical size against its pixel
+   size, per output, under mutter's viewing-distance model: the DPI that
+   counts as 1x is 135 under a 20″ diagonal and 110 over it, snapped to
+   quarter steps in [1, 3]. A 27″ 2560×1440 monitor is 1x, a 27″ 4K 1.5x, a
+   16″ MacBook panel 2x.
+5. **The resolution class** — when the millimetres are absent or not
+   credible: a grid ≥3000 wide, or taller than 1600 on its short side, is
+   2x, and everything else 1x. 2560×1440 and 2560×1600 stay 1x.
+6. **1.**
+
+**96 is not an answer**: `Xft.dpi: 96` and `Gdk/WindowScalingFactor: 1` are
+what daemons publish when nobody opened the dialog, so they fall through to
+the hardware rather than pinning an unconfigured 4K laptop to 1x. And
+**millimetres are believed only when credible**: zeroes, aspect ratios
+posing as sizes, a physical/pixel aspect mismatch and virtual machines'
+monitors (by EDID — QEMU, VMware, VirtualBox, Parallels, Hyper-V — and by
+connector name, `Virtual-*`, `qxl`, …) fall through to rung 5. So do
+`XWAYLAND*` outputs' millimetres: the compositor owns scaling there and
+publishes its decision through rung 2.
+
+### Servers that are not describing hardware
+
+Rungs 4–5 read a panel, so they are skipped where the connection has none:
+
+- **XQuartz** (the `Apple-WM` extension) hands X macOS's point space,
+  already normalised for density, and macOS scales the window onto whichever
+  panel it lands on. The answer is 1x, with the source `xquartz`.
+- **A single synthetic output covering every monitor** — Xvfb, x11vnc,
+  TigerVNC, Xephyr and pre-RandR drivers — would read the union of two 1x
+  monitors as a retina panel, so rung 5 is skipped when Xinerama reports
+  more heads than outputs. Credible millimetres (rung 4) still count.
+
+`REACT_X11_SCALE`, `GDK_SCALE` and a desktop's own XSETTINGS still win over
+both. `REACT_X11_DEBUG_SCALE=1` in an app prints how the ladder resolved.
+
+## On Wayland
+
+A compositor has a scale protocol, and its answer is the display scale:
+fractional-scale-v1 where it is offered (1.25, 1.5…), else
+`wl_surface.preferred_buffer_scale`, else the integer `wl_output.scale` of
+the output a window is on. Buffers are drawn at that density, so text is
+as sharp at 1.5 as at 2. Two things still outrank it, as on X11:
+
+- **`REACT_X11_SCALE`, then `createRoot({ scale })`** pin the factor,
+  absolutely: device (buffer) pixels per logical pixel. On a compositor at
+  1x, `REACT_X11_SCALE=2` is a window twice the size drawn at full
+  resolution, not a small one stretched.
+- **The resolution class, when the compositor says 1.** When every output
+  is at 1x and the largest has no credible millimetres but a retina-class
+  grid — a VM window over a retina panel — the layout is 2x, as the X11
+  ladder answers for the same screen through Xwayland. A compositor that
+  scales any output, or credible millimetres, keep the compositor's answer.
+
+The frame a window draws for itself follows the compositor, not the
+layout: it is drawn at the desktop's scale, beside every other window's.
+`REACT_X11_DEBUG_SCALE=1` prints which of these answered.
+
+## Several monitors
+
+Rungs 4–5 are computed for every connected output. The **root's** scale —
+the one layout and paint use — is the primary output's (the largest, where
+nothing is flagged primary), as GNOME does on X11: one scale for the
+session.
+
+The per-output answers ride on `useScreens()` — every entry carries its own
+`scale` — so an app that places windows can do better, and a window can be
+pinned with `createRoot({ scale })` per root. A window is **not** re-scaled
+as it is dragged between mismatched monitors: X11 has one coordinate space
+and no per-window scale protocol, so the scale is chosen at creation and
+static after.
+
+It is static for the session too: a mid-session change of `Xft.dpi` or a
+monitor swap does not re-scale running windows. Restart the app.
+
+## A subtree of its own
+
+The display scale is one number for the whole window. `scale` on an element
+is a second factor for one **subtree** of it:
+
+```jsx
+<box scale={zoom} style={{ width: w / zoom, height: h / zoom }}>
+  <NodeBody /> // written in plain logical pixels, unaware of the zoom
+</box>
+```
+
+The semantics are CSS's `zoom`, not a transform:
+
+- A node's **effective scale** is its parent's times its own `scale` prop,
+  so nested props multiply and the display scale is the floor they multiply.
+  `node.scale` is that number, and everything the display scale reaches —
+  styles, the caret and scrollbars, shadows and gradients, a registered
+  element's own `paint()` — follows it.
+- **The node's own style scales too.** `scale={2}` on a box with
+  `padding: 8` gets 16 device pixels of padding, not 8 with bigger children
+  inside it. That is what makes the caller's job the one-liner above: divide
+  the size you want the box to occupy by the zoom, and write everything
+  inside it at 1x.
+- **Text is shaped at the size it is drawn at.** A `fontSize: 14` inside
+  `scale={2}` is shaped, measured and rasterized at 28 — the same thing the
+  display scale does, for the same reason. A zoomed-in graph is not a
+  stretched screenshot of a zoomed-out one.
+- **Yoga lays out the scaled numbers** like any others, so a zoomed subtree
+  wraps, flexes and measures its content floors at the size it is drawn.
+
+What it is for: an element that owns a viewport — a graph pane, a canvas, a
+map — and mounts application content inside it. The pane draws its own
+world, and the React subtree beside it follows the same zoom, laid out,
+drawn and hit at the zoomed size.
+
+### What a boundary costs
+
+**Events are in the target's unit.** `ev.x`, `ev.y`, `localX`/`localY` and
+`getClientRects()` on a node inside a zoomed subtree are all divided by
+_that node's_ scale, so they agree with each other and with the styles it
+was written in — a handler inside the subtree needs to know nothing. The
+trade-off is CSS `zoom`'s: a handler on an **unzoomed ancestor** reads a
+coordinate in the zoomed descendant's unit, because the target is what
+decides. When a pane needs its own coordinates for a hit that landed inside
+the content it hosts, `ev.nativeEvent` is the way back — device pixels of
+the window, which `/ node.scale` converts to whichever unit is wanted.
+`screenX`/`screenY` are unaffected: they are desktop coordinates, and the
+desktop has one scale.
+
+A wheel notch scrolls `48` of the target's logical pixels, so content under
+the pointer travels the distance the zoom says it should.
+
+**A real X window is its own root.** `<window>` and `<popup>` take no
+`scale` prop and ignore an enclosing one: their geometry is the server's, a
+window manager sees no zoom, and a menu opened from a zoomed card should
+come up at the size the rest of the app's menus are. `<glarea>` and
+`<foreign>` do inherit — their boxes are laid out by the parent like any
+other child's.
+
+**Quantise a gesture-driven zoom.** Every distinct factor is a distinct
+font size to shape and cache, so a wheel handler feeding the raw accumulator
+into `scale` makes a new set of glyphs per frame. Round to a step — 5%, or
+a ladder of preset zooms — and the cache does its job.
+
+## In tests
+
+The headless harnesses resolve to exactly 1 — a mock app has no display to
+ask — so a geometry assertion means its numbers literally.
+`createRoot({ app, scale: 2 })` opts a test in, and so does
+`renderX11(element, { scale: 2 })` from `react-x11/test`.
+
+Design notes — the ladder's rationale, prior art, and why lengths are
+multiplied rather than the context transformed:
+[design/scale.md](../design/scale.md).

package/docs/security.md

@@ -0,0 +1,132 @@
+# Security model
+
+Read this before you decide what to put in a react-x11 window.
+
+## X11 has no isolation between clients
+
+Any program connected to an X display can read any other program's window
+contents, grab the keyboard, and synthesize or record input. Not through a
+bug — that is the 1987 design. X11 predates the idea that programs on one
+machine might not trust each other, and the protocol's power was the point.
+
+It is not theoretical, and it is not hard. node-x11 ships bindings for both
+extensions that make it a five-line program on a shared display:
+
+- **XTEST** (`x11/lib/ext/xtest.js`) — `FakeInput` synthesizes key presses
+  and pointer events indistinguishable from real ones.
+- **RECORD** (`x11/lib/ext/record.js`) — a keylogger, by design; it exists
+  so that macro recorders can work.
+
+Plus `GetImage` on another client's window, which needs no extension at all
+and is what this project's own [framed screenshots](../AGENTS.md) use.
+
+Two consequences, both practical:
+
+1. **Do not run untrusted programs on a display you use.** A malicious npm
+   postinstall script that reaches `$DISPLAY` owns your session — your
+   browser's rendered pages, your password manager's window, your
+   keystrokes.
+2. **Do not treat a react-x11 window as a confidential surface.** If a
+   secret must not be readable by other software on that display, it does
+   not belong in an X11 window. This applies to every X11 toolkit equally;
+   react-x11 has no way to change it and does not pretend to.
+
+Under Wayland this is different — a Wayland client cannot read its
+neighbours — but react-x11 running under Xwayland is inside the X11 sandbox
+with every other X client, so it shares theirs and not the compositor's. The
+opt-in Wayland backend (`backend: 'wayland'`,
+[wayland-backend.md](wayland-backend.md)) is a native Wayland client instead,
+and is isolated the way any other one is. The Cocoa and win32 backends
+connect to no X display at all, so what isolation they have is the
+platform's, not X11's.
+
+## `$XAUTHORITY` is a password
+
+Access to an X display is a **bearer token**: the MIT-MAGIC-COOKIE-1 cookie
+in `~/.Xauthority` (or wherever `$XAUTHORITY` points). node-x11 sends it on
+connect (`x11/lib/auth.js`). Whoever holds the cookie has the display, with
+everything in the section above.
+
+So:
+
+- **Never bake it into a container image.** `COPY . /app` with an
+  `.Xauthority` in the build context ships your display credentials to
+  whoever pulls the image.
+- **Never log it, and never put it in a bug report.** Nor
+  `xauth list` output, nor a strace of the connect handshake.
+- **Do not mount `~/.Xauthority` into a container** you would not trust with
+  your desktop. Mounting `/tmp/.X11-unix` has the same effect.
+- Cookies are per-display and long-lived. Rotating one means
+  `xauth remove` / `xauth generate`, not restarting the app.
+
+`ssh -X` sidesteps all of this: it creates a **separate, per-session,
+expiring** cookie on the remote side, which is worth far less if it leaks.
+That is a security argument for `ssh -X` beyond the encryption.
+
+## Prefer `ssh -X` over `ssh -Y`
+
+`-X` runs the app as an untrusted client: it cannot read other windows,
+cannot grab the keyboard, cannot record input. `-Y` turns those restrictions
+off and hands the remote host your whole session.
+
+**react-x11 should work under `-X`.** It draws into windows it created,
+which is exactly what untrusted mode allows. **If it does not, that is a bug
+worth filing** rather than a reason to switch to `-Y`. That is a deliberate
+position: most toolkits' documentation says "use `-Y` if `-X` misbehaves",
+which quietly trades the entire isolation model for a workaround.
+
+The one thing untrusted mode costs you is a cookie that expires — see
+[remote.md](remote.md#the-failure-that-looks-like-a-crash), because the
+symptom looks like a crash rather than a permission problem.
+
+## Never `xhost +`
+
+`xhost +` disables access control for every host on the network. `xhost
++local:` does it for every user on the machine, including the ones you did
+not have in mind. Both are common advice for "X11 in Docker" and both mean
+"anything that can reach my display now owns my session".
+
+The right tool is `xauth`: extract the cookie for one display and give it to
+one consumer.
+
+```sh
+# hand a container the cookie for :0, and nothing else
+xauth nextract - "$DISPLAY" | docker exec -i box xauth nmerge -
+```
+
+`ssh -X` is better still, because the cookie it hands over is not the one
+that opens your desktop.
+
+## What react-x11 does and does not do
+
+**Does:**
+
+- Sends the cookie ntk/node-x11 read from `$XAUTHORITY` — the standard
+  handshake, nothing custom.
+- Contains a throwing event handler rather than letting it take the process
+  ([events.md](events.md#when-a-handler-throws)); a bad handler is a bug, not
+  a way to wedge the app.
+- Bounds what it draws to the damaged region, which is a performance
+  property but also means less of your window crosses the wire per frame.
+
+**Does not:**
+
+- Defend against a hostile X server. The server you connect to sees
+  everything you draw, everything you type into your own windows, and holds
+  your clipboard. Connecting to an X display is trusting it completely —
+  there is no protocol-level way to do otherwise, and no library can add
+  one. `DISPLAY=evil.example:0` is equivalent to handing over the session.
+- Sanitize content. `<svg>` renders the markup you give it through ntk's
+  SvgView, and a document component renders the source you hand it —
+  untrusted markup should be treated the way you would treat it in a
+  browser. Anything that fetches a remote resource on a document's behalf
+  is yours to police.
+- Isolate one window from another within an app. Every node in a root shares
+  one connection and one process; `trapFocus` is a focus policy, not a
+  security boundary, and neither is a modal `Dialog`
+  ([components.md](components.md#dialog)).
+- Encrypt anything. That is `ssh`'s job.
+
+## Reporting a vulnerability
+
+See [SECURITY.md](../SECURITY.md).