What is OS-level keystroke capture — and why it produces stronger writing evidence than browser recording alone

The short answer

OS-level keystroke capture hooks into the computer's input system before any application processes the event. It sees physical key presses — with hardware-sourced timestamps, regardless of which application is in focus — and it cannot be bypassed or suppressed by the writing tool itself. A browser extension or document add-on, by contrast, observes only what the application's programming interface exposes: DOM events inside the browser, or document content changes inside the writing app. Each lower layer sees less, misses more, and is more susceptible to synthetic injection. For writing evidence that needs to hold up under scrutiny, the layer of observation matters.

The four observation layers

Writing can be captured at four distinct levels. Each has a different relationship to the physical keystroke event.

Layer 1 — OS kernel / driver level

When you press a physical key, the keyboard hardware generates a signal that the operating system's input driver receives before any application does. At this layer, the system sees the raw key event — which key, whether it was pressed or released, and a timestamp drawn from the system clock — without any application having the opportunity to intercept, transform, or suppress it.

A tool recording at this layer (on macOS this requires Input Monitoring permission granted explicitly by the user; on Windows it uses the standard low-level keyboard hook in the Win32 API) captures writing regardless of which application is active. The record is application-agnostic: whether you write in Word, Google Docs in Chrome, Notepad, or any other app, the physical events arrive at the OS layer identically.

Crucially, nothing the writing application does can hide events from the OS layer. An app can intercept and rewrite DOM keydown events in the browser; it cannot suppress the physical key press from the OS hook.

Layer 2 — Application layer (native app)

A native application — Microsoft Word desktop, Apple Pages, Scrivener — can register for keyboard input events within its own window. This gives it access to input that the OS has already delivered to it, at roughly the same fidelity as the OS layer for that application's window. The difference: it only sees keystrokes when its window is the active focus. Writing in another app during the same session is invisible. And the record is entirely under the application's control, which matters for tamper-evidence.

Layer 3 — Browser extension

A browser extension operates inside the browser sandbox. It can listen for DOM keyboard events (keydown, keyup, input) within web pages the browser renders. This is a different signal from the physical keystroke:

• Composition events differ from key events. When a user types using an IME (Input Method Editor for Chinese, Japanese, Korean, etc.) or when autocorrect or autocomplete fires, the DOM receives transformed text, not the individual key presses that produced it. The physical events and the DOM events diverge.
• Synthetic injection is straightforward. Any script with DOM access can fire synthetic KeyboardEvent objects into a browser page. These are indistinguishable from real keypresses at the DOM level — the isTrusted property on a synthetic event is false, but this requires the extension to check it explicitly, and checking it is not universal.
• Cross-application blindness. The extension sees nothing outside the browser. Drafting notes in a text editor, copying from a PDF, or typing in any other application is invisible to a browser extension.

Layer 4 — Document add-on

A Google Docs add-on or a Microsoft Word add-in sits at the furthest remove from the physical event. These tools have access to the document content — the current state of the text — not to the keyboard events that produced it. An add-on can observe that a paragraph changed between one polling interval and the next; it cannot observe whether those characters were typed one at a time or pasted as a block. The "how it arrived" question — the forensically relevant one — is not answerable from document content changes alone.

The comparison at a glance

Observation layer	What it sees	Cross-app visibility	Synthetic injection risk	Timestamps
OS kernel / driver	Physical key events	Yes — all apps	Very difficult (hardware timing)	Hardware-sourced
Native application	App-scoped key events	No — own window only	Low within app	System clock
Browser extension	DOM keyboard events	No — browser only	Easy (synthetic KeyboardEvent)	DOM-sourced
Document add-on	Document content changes	No — one document	N/A (sees result, not events)	Polling interval

What the gaps introduce

Each step down the observation stack introduces specific blind spots that matter for authorship evidence.

Paste detection: a browser extension using DOM events can detect a paste operation (the paste event fires). But it cannot always distinguish whether pasted text came from another browser tab, from a native app, from a clipboard manager, or from a tool that injected the content programmatically. OS-level capture sees the Ctrl+V keystroke alongside all the context of what the user was doing immediately before, which provides more signal.

Autocomplete attribution: when a user accepts a browser-native or application autocomplete suggestion, the document may receive characters that the user did not type keystroke-by-keystroke. An add-on that observes document content changes has no way to distinguish accepted autocomplete from typed text. An OS-level record shows the key sequences that led to the autocomplete trigger and the single accept keystroke, which tells a different story.

Off-document composition: many writers draft passages in notes apps, email clients, or even other documents before pasting into the final file. A browser extension or document add-on is blind to this entirely. OS-level capture records the typing wherever it occurred.

Why OS-level is forensically stronger

The keystroke biometrics research literature provides a useful frame. Teh, Teoh, and Yue's survey (2013) of keystroke dynamics established that inter-key timing intervals — the precise duration between successive key events — are the core biometric signal, and that this signal is only reliably measured at the OS or driver level where hardware-resolution timestamps are available. DOM-sourced timestamps are subject to browser rendering latency, JavaScript event-loop queuing, and timer throttling; they introduce noise that reduces the fidelity of the timing record.

Acien, Morales, Fierrez, Vera-Rodriguez, and Montalban (TypeNet, 2020) demonstrated that OS-level keystroke timing data, at scale, supports highly accurate biometric authentication — including identification in unconstrained typing scenarios. The forensic implication is the same: the timing signal that makes individual keystrokes biometrically distinctive lives at the OS layer, and that is exactly the signal that writing-process evidence relies on.

Crossley et al. (EDM 2024) achieved 99% accuracy distinguishing composed from transcribed text using process features drawn from keystroke logs. The discriminative signal — the variance in inter-key timing, the pattern of deletions and revisions, the behavioral signature of thinking and rewriting — is present in OS-level records and diluted or absent in DOM-event records and invisible in add-on-level content changes.

The synthetic input problem

The most adversarially relevant question: can a determined actor fake a process record?

At the document add-on layer: the add-on only sees content, so injecting content via any means produces the same record. A script that types into a document and a human typing produce identical observations at this layer.

At the browser extension layer: synthetic KeyboardEvent objects injected via JavaScript are flagged with isTrusted: false, but this requires the capturing code to check and store that flag. Without that check, synthetic DOM events are indistinguishable from real ones. Even with it, a script running in a browser extension (rather than injected via the page) can produce events with isTrusted: true.

At the OS level: fabricating physical key events with realistic inter-key timing distributions requires either direct hardware access (not available to ordinary software) or a system-level tool that drives the keyboard driver. Such tools exist — auto-typers and keyboard macros — but they produce detectably different timing distributions from human typing. Human keystroke timing follows characteristic statistical patterns (inter-key intervals are not uniformly distributed; they reflect cognitive processing, not clock ticks). A macro typing at a fixed rate produces a suspiciously regular timing signature. Leijten and Van Waes established in their foundational writing-research work that this behavioral signature is robust across extended writing sessions.

To make this concrete: consider two typists both averaging 60 WPM on the same essay. The auto-typer fires a keystroke every 200 milliseconds, session after session, with inter-key intervals clustering tightly around that mean — no slowing at sentence starts, no brief hesitations before an unfamiliar word, no burst-then-pause rhythm when a new idea is being formed. The human at the same average speed shows something entirely different: inter-key intervals follow a log-normal distribution, heavily right-skewed, with high variance at sentence and paragraph boundaries where cognitive load spikes, short burst sequences within familiar phrases, and irregular clusters of deletions and rewrites that break any fixed-rate pattern. A forensic reviewer looking at the OS-level timing record can distinguish the two not by average speed but by the presence or absence of linguistic pause structure. The auto-typer's record is too clean.

This does not mean OS-level records are unfakeable — it means faking them is substantially harder and produces artifacts that forensic analysis can identify. The adversarial cost is much higher than at lower layers.

What this means for evidence quality

A process record's evidentiary value is bounded by the layer at which it was captured. Two records might both be called "keystroke logs," but if one is OS-level physical events with hardware timestamps and the other is DOM keydown events from a browser extension, they are not equivalent evidence. The OS-level record is harder to fake, richer in timing signal, application-agnostic, and more resilient to the adversarial scenarios that arise in integrity disputes.

This is not to say that browser-extension and add-on records are without value — they provide useful evidence in the contexts where they operate. The layers are complementary: an OS-level record of cross-application activity, combined with a document add-on's content-change log for the specific document, provides more coverage than either alone. But when the question is "which layer is most forensically robust," the answer is consistent across the evidence and biometrics literature: the OS layer.

What this means for choosing a writing evidence tool

The practical implication of the layer analysis is about coverage and corroboration. Any single layer leaves a gap: an OS-level record is application-agnostic and timing-rich but does not carry document-structure context; a document add-on captures the document state precisely but cannot see how characters arrived or what was typed elsewhere; a browser extension sits between those two and inherits the weaknesses of both.

The combination of layers closes the gaps that each has alone. OS-level capture provides the timing fidelity and cross-application visibility that make process fabrication expensive; the browser extension ties those events to specific web documents; the document add-on anchors the keystroke record to the content state of the file as Microsoft or Google's servers saw it. Together, they produce a record where a claim about one layer can be cross-checked against the others — a forger would need to fabricate all three consistently, which is a substantially harder problem than forging any one of them.

The verify page shows what a multi-layer sealed record looks like in practice.

Related reading: what is writing provenance · writing-process evidence vs AI detection · tamper-evident vs tamper-proof · keystroke logging and writing process research · what a writing record cannot prove