Capability

Records what the user actually did — not just periodic snapshots

Periodic screenshots produce mostly blank frames. ZeroLeak captures the moments that matter — every click, navigation, form submission, key event, and clipboard operation — with the mouse cursor marked, before-and-after page transitions, and a word-level keystroke buffer that reads like prose, not a key dump.

Compliance, insider risk and incident investigation all need to answer the same question: what did the user actually do in this session? Periodic timed screenshots give you a directory of mostly-empty frames and force a human reviewer to scrub through endless idle states to find the consequential moments. ZeroLeak inverts this. The session is recorded continuously as video, screenshots fire at the events that matter (clicks, navigations, key submissions, clipboard operations), the mouse position is drawn into every screenshot so you can see what was clicked, navigations capture both before and after the new page loads, and keystrokes are buffered into words rather than individual key events — so the audit reads like text the user typed, with [BS] markers for corrections, instead of a tone-deaf timeline of every key down.

Event-driven
Screenshots fire on user actions, not on a timer — short directories, high signal
3 streams
Event-driven screenshots, continuous video, structured event log — all timestamp-aligned
Word-buffered
Keystrokes flush as readable text with [BS] markers, not key-by-key noise

Periodic screenshots produce noise; you need the moments that matter

The default session recording approach is to capture a screenshot every few seconds. The result is a directory full of identical-looking frames — the user is reading the page, the user is reading the page, the user is still reading the page — interspersed with the actual events that mattered, somewhere in between two snapshots that arrived too late and showed only the consequence, not the action.

Periodic capture also misses the answer to the most important question for any audit or investigation: what did the user do? A snapshot taken 1.5 seconds after a click does not show what they clicked. A snapshot taken 3 seconds after a form submission does not show what they typed. The audit log has events without context; the screenshots have context without events. Connecting them is manual work that scales badly with session count.

ZeroLeak takes a different approach. Screenshots fire on the events themselves, not on a timer. Navigations capture two screenshots — the page before clicking, and the page after the new one loads — so the cause-and-effect is preserved as a pair. The mouse position is drawn into every capture, so you can see what was clicked. Keystrokes are buffered into readable words. Video is recorded continuously underneath so the gaps between captured events can still be replayed if needed.

Event-driven capture, continuous video, readable text

Three recording subsystems run in parallel for every session: event-driven screenshots at consequential moments, continuous FFmpeg video at a configured frame rate, and a structured event log with word-buffered keystrokes and full clipboard activity. Each can be enabled or disabled per protected service; by default all three run together so reconstruction is always possible.

Screenshots fire on events, not on a timer

Captures are triggered by the user's actual actions — clicks, page navigations, key submissions, form submissions, clipboard operations. There is no time-based polling that fills the disk with idle frames. Every screenshot captures a consequential moment; the directory is short and informative, not long and noisy.

Mouse cursor drawn into every screenshot

Every captured screenshot has the mouse position marked with a visible indicator — a red dot at the exact coordinates of the click or hover. You see what the user clicked, not just the page that resulted from the click. Single-frame reconstruction of intent, not a multi-frame puzzle.

Before-and-after pair on every navigation

When the user navigates, two screenshots are captured — one of the page before the click, and one of the destination page after the new content has fully loaded. The cause and effect are preserved as a pair. A reviewer sees "user clicked link X, the next page loaded was Y" as two adjacent frames.

Keystrokes buffered into readable words

Individual key events are accumulated into a buffer that flushes on space, enter, tab, or short pause. The result reads like the text the user typed, not a key-by-key event dump. Backspaces are preserved as [BS] markers so corrections are visible. Repeating keys (held down) are filtered. Clipboard operations are recorded separately with the actual content.

What the recording subsystem captures

Each capture mechanism is independently configurable per protected service and runs without performance impact on the user session. The three streams (screenshots, video, event log) are timestamp-aligned so a reviewer can move between them seamlessly.

Event-driven screenshot triggers

Screenshots fire on user clicks, navigations (with before-and-after pair), form submissions, key submissions (Enter), clipboard operations (copy, cut, paste), manually-triggered captures from the operator console, and several other consequential event types. The exact event list is configurable per protected service.

Network-idle wait for navigation captures

On navigation, the destination screenshot is captured only after the new page has stopped loading — waiting for network idle plus a short additional render delay. The captured screenshot shows the page as the user would actually see it, not a half-loaded intermediate state.

Continuous FFmpeg video at configured frame rate

Underneath the event-driven screenshots, the session is recorded continuously as a video using FFmpeg's x11grab. Frame rate is configurable (default 10 fps for compact files; higher rates available for high-detail capture). Video is segmented for safe streaming and replay; segments are timestamped to align with the screenshot and event log streams.

Word-buffered keystroke log

Key events accumulate into a buffer that flushes on word boundaries (space, enter, tab) or after a short idle pause. The flushed string reads like prose — "hello world [BS][BS][BS][BS][BS]hi world" — preserving the user's intent and corrections without the noise of every individual keydown event.

Clipboard activity captured with content

Copy, cut, and paste operations are recorded separately from keystrokes, including the actual clipboard content involved. A reviewer can see exactly what was copied and what was pasted, not just that a clipboard event occurred.

Sequential numbering and lookup

Screenshots are numbered sequentially (0001, 0002, ...) and stored with the timestamp and event metadata. The operator console lists them with the triggering event so a reviewer can jump directly to the moment of interest — for example, all clipboard-triggered captures in a session, or the navigation pair around a specific URL.

The event log — what beyond clicks gets recorded

Beyond screenshots and video, a structured event log captures the user's interaction history with full context. Each event has a type, a timestamp, an associated screenshot reference (when applicable), and the relevant payload. The log is what makes the recording searchable and analytically useful, not just visually browsable.

01

Mouse clicks with coordinates and target element

Each click event records the x/y coordinates and the DOM element under the cursor (tag, class, ID, text content when available). A reviewer can search for clicks on a specific button or link across the session log, not just scrub through screenshots looking for one.

02

Scroll events (throttled)

Scroll position changes are recorded with throttling to avoid log spam. Enough resolution to reconstruct where the user was looking on long pages without producing thousands of redundant scroll events per minute.

03

Navigation events including SPA route changes

Every navigation — full page loads, single-page-app pushState changes, programmatic location changes — is logged with the source URL, destination URL, trigger (link click, manual, programmatic), and the time it took to complete. SPA navigations that traditional logging misses are captured by ZeroLeak's URL polling layer.

04

Form submission events with field references

When the user submits a form, the event log captures the form's action URL, method, and field names. The actual field values are captured through the keystroke log (so the typing history is preserved) rather than duplicated in the form event.

05

Idle and activity transitions

The session tracks user activity at the input layer. Transitions between active and idle states are recorded with timestamps so reviewers can see periods of attention vs. inactivity — useful for compliance review and time-based audit questions.

06

Session-level metadata at end

On session end, summary metadata is recorded: total duration, idle-vs-active breakdown, total events of each type, screenshots produced, video file references, and the termination reason (timeout, manual end, error). If a coordinator webhook is configured, this summary fires to it as well.

Where session recording earns its keep

Compliance audits and regulatory review

Regulators asking what specific users did during specific sessions — HIPAA review of patient-record access, financial trading floor compliance, government data-handling audits. Event-driven capture produces a short, informative trail per session that reviewers can navigate quickly.

Insider threat investigation

When a leak or policy violation is suspected, the investigator needs to know exactly what the user did — not just when. Sequential screenshots with mouse markers, word-buffered keystrokes and full clipboard content make the session replayable in detail without watching hours of video.

Contractor and third-party access audit

External users granted view-only access into your environment. Per-session full recording — with the visible watermark identifying the user — gives downstream accountability for everything they saw and every action they took during their access window.

Operational incident analysis

After an unexpected event in a SCADA or operational console, the recording shows exactly what the operator was seeing and which controls they clicked in the moments before. The before-and-after pair on navigation makes diagnosing cascading errors much faster.

Common questions

How much storage does a typical session consume?
Event-driven screenshots produce a small directory per session because they only fire on consequential moments — typically tens of screenshots per active session, not thousands. The continuous video stream is configurable in frame rate and resolution; at the default 10 fps and segment compression, hours of session video stay in manageable file sizes. The event log is text and adds little overhead. Total storage scales with active user-hours, not with session count.
Can the user know when they are being recorded?
That is a policy decision per protected service. Some compliance regimes require an explicit user notification at session start; others record silently for insider-threat coverage. Both modes are supported. The visible watermark (when forensic watermark is also enabled) doubles as a recording notice for deployments that combine the two.
What happens to the recording if the session ends abruptly?
Graceful shutdown captures the final state and closes the video segment cleanly. On unexpected termination (process crash, container kill), the FFmpeg segment-based recording leaves recovered segments behind — at most the most-recent segment is lost, not the entire session. The event log and earlier screenshots survive any such termination.
How do reviewers navigate a recorded session?
The operator console lists the session's events in chronological order with the triggering event type, timestamp, and (where applicable) a thumbnail of the associated screenshot. A reviewer can jump directly to any event — "show me all clipboard operations", "show me the navigation that took the user away from the dashboard", "show me the form submissions" — without scrubbing through video.
How does this combine with the watermark and the isolation?
Browser context isolation gives each session its own browser environment and enforces the navigation boundary. Forensic watermark identifies the user on every frame. Session recording captures what they did. The three are complementary layers — isolation defines the scope, watermark establishes who is in it, recording captures what they did inside it.
Can the protected application disable or interfere with the recording?
No. The recording subsystem operates outside the protected application's runtime — at the rendering and input layers managed by ZeroLeak, not inside the application's DOM or JavaScript. The application has no API to inhibit screenshots, suppress keystrokes from the log, or pause video. Recording is enforced by the policy, not requested from the application.

See event-driven recording in a live demo

We will run a session, click some links, fill some forms, copy some content, and show you the resulting screenshot directory, keystroke log and video segments — and how a reviewer reconstructs the session from them.