HOLogram deep dive: the Input Vault - intercepting keystrokes before JavaScript reads them

Series context

This is part 3 of "Building HOLogram", a series on the open protocol for behavioral biometrics protection in the browser. Part 0 - introduction | Part 1 - Persona Mixer | Part 2 - Privacy Budget | Part 3 - Input Vault

The ShadowDOM Input Vault is HOLogram's first module - and arguably its most technically constrained. Its job sounds simple: intercept keyboard events before page scripts can read them, remove the timing information that identifies the user, and re‑emit synthetic events that are functionally identical but behaviorally anonymous. In practice, implementing this correctly requires navigating a minefield of browser API differences, timing attack surfaces, and semantic preservation requirements.

What the Input Vault must do

The threat model is specific. Keystroke dynamics classifiers extract inter‑keystroke interval (IKI) timing - the time between consecutive keydown and keyup events - as their primary feature. These intervals, measured across a typing session, produce a timing signature that is highly individual and stable across time.

The Input Vault must:

• Intercept native keyboard events at the earliest possible point - before any page script can observe the real timestamps
• Remove the timing information - specifically, the high‑resolution timestamps that make IKI measurement possible
• Re‑emit synthetic events that carry the correct semantic content (which key was pressed) but not the real timing
• Preserve all other aspects of the interaction - the key identity, the event sequence, the modifier keys - so the page functions correctly

The semantic content of what you type must be preserved exactly. The temporal pattern must not.

The browser API challenge

This is where the implementation gets complicated. Browser extensions operate in a layered security model. Page scripts run in the page context. Extension content scripts run in an isolated world that can access the DOM but is separate from the page's JavaScript. The extension background runs in yet another context.

The question for the Input Vault is: at which layer can we intercept keyboard events before the page sees them?

Option A: Content script event listener

A content script can register an event listener on document with useCapture: true - which fires during the capture phase, before the event reaches the page's own listeners. This gives us early access to the event, but not before the page. The capture phase fires before the target and bubble phases, but a page script that also registers a capture‑phase listener on document would still receive the real event with the real timestamp.

Option B: Event interception at the window level

Some browser APIs allow intercepting events at the window level before they propagate to document. Whether this provides true pre‑page interception depends on the browser and the specific API.

Option C: Shadow DOM isolation

The "ShadowDOM" in "ShadowDOM Input Vault" refers to using Shadow DOM's encapsulation to isolate input handling. Input elements inside a closed Shadow DOM are not directly accessible to page scripts - events dispatched from within the shadow root can be re‑emitted as synthetic events to the page without exposing the original. This approach has promise but comes with significant constraints: it requires that input elements be inside a Shadow DOM we control, which is not always the case for arbitrary web pages.

Option D: Browser‑native input interception API

Some browsers provide extension APIs that allow intercepting input at a level below the page context entirely - before the event enters the DOM at all. The availability, behavior, and permissions required for these APIs vary significantly across Chrome, Firefox, and Safari.

The semantic preservation requirement

Whatever interception approach is used, the re‑emitted synthetic event must be semantically identical to the original - or the page breaks. This means the synthetic event must correctly carry:

• The key identity (key, code, keyCode, charCode)
• The modifier state (shiftKey, ctrlKey, altKey, metaKey)
• The event type sequence (keydown → keypress → keyup)
• The bubbles and cancelable properties
• The composed property (for Shadow DOM scenarios)

The only thing that must be different is the timestamp - or more precisely, the high‑resolution timing information that IKI classifiers extract.

IME: the unsolved problem

Input Method Editors (IMEs) are used to type characters in non‑Latin scripts - Chinese, Japanese, Korean, Arabic, and others. IME input doesn't follow the standard keydown / keypress / keyup sequence. It uses composition events: compositionstart, compositionupdate, compositionend.

How the Input Vault handles IME input is an open question. Getting it wrong means HOLogram breaks input for a significant portion of the world's users.

What we need to find out

The Input Vault design is specified. The implementation requires answers to questions that only empirical browser API research can provide:

• Which API gives us the earliest interception point in each browser?
• Does any approach give us true pre‑page interception, or are we always racing?
• What permissions does each approach require in the extension manifest?
• How do Chrome, Firefox, and Safari differ in their event timing behavior?
• How do we handle IME composition events without breaking non‑Latin input?

This is exactly the scope of R‑01: Survey browser APIs for input event interception - the most foundational research issue in the project. If you have experience with browser extension development, especially with input event handling, this is where your contribution would have the highest impact.

How to contribute

• 📋 R‑01: Browser API survey for input event interception - foundational research
• 📋 D‑03: HCT compliance test spec for the Input Vault - define what "correct" means
• 💻 GitHub
• 💬 Discussions
• 📄 Whitepaper v1.0

This concludes the "Building HOLogram" series - for now. The next articles will be written by contributors as they work through the research issues. If you pick up R‑01 or D‑03 and want to write about your findings, we'd love to publish it here as part of the series.