DEV Community: BaffiSan

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

BaffiSan — Fri, 25 Sep 2026 07:28:02 +0000

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.

HOLogram deep dive: the Behavioral Privacy Budget — controlling exposure over time

BaffiSan — Mon, 21 Sep 2026 12:16:00 +0000

This is part 2 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

Obfuscating individual behavioral events is necessary. It's not sufficient.

A sufficiently patient adversary doesn't need to identify you from a single
interaction. They observe you over time — across many events, many sessions —
and build a statistical picture that individual obfuscation can't defeat.

This is the problem the Behavioral Privacy Budget was designed to address.

The core idea

The Privacy Budget tracks the cumulative behavioral exposure of a session.

Every interaction has a cost. The more behaviorally distinctive an interaction
is — the more information it leaks about the real user — the higher its cost.
As the session progresses and the budget is consumed, the protocol
automatically escalates its obfuscation strategy.

When the budget is exhausted, the session is considered fully exposed —
and the user is notified via the Exposure HUD.

The cost formula

The cost of each behavioral event is computed as:

cost = w_type × f_freq × g_geom × h_entropy

Where:

w_type — event type weight
Different event types carry different amounts of behavioral information.
A typing burst is more identifying than a single scroll event.
A precise pointer click is more identifying than a smooth pan.
w_type assigns a base weight to each event category.

f_freq — frequency factor
A single mouse movement reveals little. Ten thousand mouse movements
in a session reveal a lot, even if each individual event is obfuscated.
f_freq scales the cost based on how many events of this type
have occurred in the session — the more frequent, the higher the cost.

g_geom — geometric complexity factor
A straight pointer path is less identifying than a complex, curved trajectory.
g_geom measures the geometric complexity of the event — curvature,
directionality, acceleration — and scales the cost accordingly.

h_entropy — entropy factor
Events with high behavioral entropy — high variability, unpredictability —
carry more identifying information than predictable, regular events.
h_entropy measures the local entropy of the behavioral signal
and scales the cost accordingly.

Three escalation thresholds

The Privacy Budget operates with three escalation levels:

Level 1 — Standard protection
Normal operation. The Persona Mixer and DP Engine apply their
configured parameters. Cost accumulation is tracked.

Level 2 — Enhanced obfuscation
When the budget crosses the first threshold, the protocol automatically
increases the aggressiveness of the Persona Mixer parameters and
the noise magnitude of the DP Engine. The user sees a subtle
indicator change in the Exposure HUD.

Level 3 — Maximum protection
When the budget crosses the second threshold, the protocol applies
maximum obfuscation across all modules. The Exposure HUD displays
a clear warning that the session has reached high exposure.

Budget exhausted
When the budget is fully consumed, the user is notified that the session
has reached its exposure limit. The protocol continues operating at
maximum protection, but the user is informed that further interaction
may be identifiable despite obfuscation.

Regeneration

The budget regenerates over time — during idle periods and across sessions.

The regeneration model ensures that:

Short bursts of high-intensity interaction don't permanently exhaust the budget
Sustained, continuous interaction over long sessions correctly accumulates exposure
The budget starts fresh at the beginning of each new session

What we don't know yet

The Privacy Budget formula is designed but the actual numeric values
are not yet defined. Specifically:

What are the correct values for w_type, f_freq, g_geom, h_entropy?
These need to be calibrated empirically — against real behavioral data
and real classifier performance. Too conservative and the budget is
consumed too quickly, degrading usability. Too permissive and the
budget fails to catch cumulative exposure.

What are the correct threshold values?
The three escalation thresholds need to be set based on empirical
evidence of what level of cumulative exposure allows successful
re-identification.

What is the correct regeneration rate?
Too fast and the budget doesn't meaningfully track exposure.
Too slow and normal browsing sessions hit the limit constantly.

These are among the most important open design questions in HOLogram.

How to contribute

The most impactful contribution for this module is
D-02: Design the Behavioral Privacy Budget consumption model —
proposing concrete values for all parameters and thresholds,
with sensitivity analysis.

Next in the series: [Part 3 — Building HOLogram's Input Vault: browser API survey]

HOLogram deep dive: the Persona Mixer — why random noise isn't enough

BaffiSan — Tue, 15 Sep 2026 11:06:53 +0000

This is part 1 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

Most approaches to behavioral privacy make the same mistake: they add noise.

Random noise injected into mouse movements or keystroke timings seems like
a reasonable defense. It corrupts the signal. It should confuse a classifier.

The problem is that random noise is itself a signal.

A behavioral biometrics classifier doesn't just look at the absolute values
of your timing or trajectory data. It looks at the statistical distribution
of those values over time. Random noise has a characteristic distribution —
flat, uniform, uncorrelated. A trained classifier can distinguish "human +
noise" from "human" with relatively high accuracy, because the noise pattern
doesn't look like any human behavioral pattern ever observed.

This is the problem the Persona Mixer was designed to solve.

What the Persona Mixer does

Instead of adding random noise to your real behavioral signals,
the Persona Mixer generates a session-consistent synthetic behavioral
signature — a stable set of behavioral parameters that define a
plausible synthetic human for the duration of the session.

The output doesn't look like noise. It looks like a specific person —
just not you. And not the same synthetic person across sessions.

The five parameters

The Persona Mixer operates on five parameters:

`pointerJitterRange`

The magnitude of synthetic micro-movements added to pointer coordinates.
Human pointer movement is never perfectly smooth — there's always a small
amount of biological tremor and motor noise. The jitter range defines
the amplitude of this synthetic tremor.

The key constraint: the range must be within human plausibility bounds.
Too small and it's indistinguishable from no jitter. Too large and it
looks like a hardware malfunction, not a human.

`scrollPauseProbability`

The probability of inserting a micro-pause during a scroll event.
Humans naturally pause while scrolling — to read, to process, to hesitate.
This parameter controls how often the synthetic persona "hesitates"
during scroll interactions.

`typingLatencyOffset`

An offset applied to inter-keystroke intervals. Rather than replacing
the natural timing distribution of your keystrokes, this parameter
shifts the entire distribution by a consistent amount — making the
synthetic persona type slightly faster or slower than the real user,
but with a pattern that remains internally consistent.

`smoothingAggressiveness`

The degree of trajectory smoothing applied to pointer paths.
Some people move their mouse in smooth arcs; others in jagged, direct lines.
This parameter controls where on that spectrum the synthetic persona falls.

`curvatureSoftening`

A reduction of sharp angular changes in pointer movement. Humans rarely
make perfect right-angle movements — sharp angles get softened into curves.
The aggressiveness of this softening varies between individuals.

Session consistency: the critical property

All five parameters are stable for the duration of a session — they
don't change between interactions.

This is what makes the Persona Mixer fundamentally different from noise
injection. A real human has consistent behavioral traits across a session.
Their typing rhythm is recognizable. Their pointer style is stable.

The synthetic persona must have the same property: a classifier observing
the session should see a consistent behavioral identity, just not the
real user's identity.

At the start of each new session, a new set of parameters is sampled —
creating a different synthetic persona. This breaks cross-session correlation
even if an adversary has a full session recording.

What we don't know yet

The Persona Mixer is designed but not yet implemented or empirically validated.

Several open questions remain:

What are the actual human plausibility ranges for each parameter?
We need empirical data on human behavioral variance to set the bounds.
A synthetic persona that falls outside human plausibility bounds is
detectable as synthetic — exactly what we're trying to avoid.

How does the Persona Mixer interact with anti-bot systems?
reCAPTCHA, hCaptcha, Cloudflare — these systems also model "human" behavior.
A Persona Mixer parameter set that defeats a behavioral biometrics classifier
might still trigger an anti-bot system. We need to understand the overlap.

Can the parameter distribution itself become a fingerprint?
If all HOLogram users sample their Persona Mixer parameters from the same
distribution, that distribution might become detectable. The sampling
strategy matters as much as the parameters themselves.

These are active open questions in our GitHub Discussions and research issues.

How to contribute

If you have experience with behavioral biometrics research, HCI, or
statistical analysis of human motor behavior, we need your input.

The most impactful contribution right now is
D-01: Define human plausibility ranges for Persona Mixer parameters —
researching the empirical bounds for each of the five parameters.

Next in the series: [Part 2 — How we designed the Behavioral Privacy Budget]

Why JavaScript can read your behavioral identity — and what HOLogram does about it

BaffiSan — Thu, 10 Sep 2026 12:27:26 +0000

Every page you visit runs JavaScript.

And that JavaScript is reading you — not just what you type,
but how you type it. The rhythm between keystrokes. The trajectory
of your pointer. The micro-pauses in your scroll. The way your hand
hesitates before clicking.

These signals are called behavioral biometrics. And they are today
one of the most powerful identification tools available to tracking systems,
AI classifiers, and fraud detection platforms.

They work without cookies.
They work across VPNs.
They work even on Tor.
Because they happen inside the page, before anything leaves your browser.

The threat no privacy tool addresses

Most privacy tools protect the network layer:

VPNs hide your IP address
uBlock Origin blocks known trackers
Privacy Badger stops cross-site tracking cookies
Tor anonymizes your traffic

None of them protect your behavioral signals — because those signals are
collected by JavaScript running inside the page you're visiting,
before any network request is made.

A classifier trained on behavioral biometrics can identify you with
high accuracy across sessions, across sites, and across devices —
using only the way you interact with a keyboard and a mouse.

This isn't theoretical. Behavioral biometrics systems are commercially
deployed today for fraud detection, user tracking, and cross-site
identity correlation. Companies like BioCatch, ThreatMetrix, and others
offer this as a service to banks, e-commerce platforms, and publishers.

What HOLogram is

HOLogram is an open protocol that introduces a local obfuscation layer
between the user and the page.

It intercepts behavioral signals at the browser layer — before JavaScript
can read them — and replaces them with a synthetic behavioral profile
that is functionally identical but behaviorally unidentifiable.

The page receives correct input. It just doesn't receive your input.

The protocol is MIT licensed, local-only, zero-retention, and designed
as a formalizable open standard — not a proprietary tool.

How it works: six independent modules

1. ShadowDOM Input Vault

Intercepts native keyboard events (keydown, keyup, keypress) before
page scripts can read them. Removes micro-timing information —
the inter-keystroke intervals that are the primary feature used by
keystroke dynamics classifiers. Re-emits functionally identical
synthetic events with timing information removed.

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

2. Pointer & Scroll Normalizer

Applies downsampling, coordinate quantization, and trajectory smoothing
to mouse movement and scroll events. Reduces the granularity of pointer
data to the level where individual identification becomes infeasible,
while keeping movements natural-looking.

3. Persona Mixer

This is the key differentiator from naive noise injection.

Instead of adding random noise — which is statistically detectable as noise —
the Persona Mixer generates a session-consistent synthetic behavioral
signature. Each session gets a stable set of synthetic behavioral parameters:

pointerJitterRange — magnitude of pointer micro-movements
scrollPauseProbability — probability of micro-pauses during scroll
typingLatencyOffset — offset applied to inter-keystroke intervals
smoothingAggressiveness — degree of trajectory smoothing
curvatureSoftening — reduction of sharp angular changes

The output looks like a specific, plausible human — just not you.
And not the same synthetic human across sessions.

4. Behavioral DP Engine

Applies calibrated noise inspired by differential privacy principles
to the real-time event stream. Reduces the sensitivity of the output
to individual behavioral variations without making the output
statistically implausible.

Note: this is explicitly inspired by differential privacy, not
formal DP on static datasets. The whitepaper documents this distinction
openly and considers it an area for future formalization.

5. Behavioral Privacy Budget

Tracks the cumulative behavioral exposure per session. Every interaction
has a cost — computed as a function of event type, frequency, geometric
complexity, and entropy. When the budget approaches defined thresholds,
the protocol escalates its obfuscation strategy automatically.

6. Exposure HUD

A minimal, non-intrusive interface that shows the user their current
protection level and which modules are active. Transparency as a feature.

Prior art: how HOLogram differs

Kloak (used in Whonix) is the closest existing tool. It operates
at the OS/kernel level on Linux, requires root, and introduces random
delays between physical events and their delivery to applications.
It's a solid tool — but it's OS-level, not browser-native, requires root,
doesn't generate session-consistent synthetic personas, and isn't a
formalizable open standard. Kloak itself acknowledges it doesn't protect
writing style, high-level cognitive behavior, or scroll patterns.

MouseFaker (Leiva et al., CHIIR 2021) is a research Chrome extension
that applies adversarial noise to mouse coordinates. Mouse only, no
session consistency, not actively maintained.

These tools and HOLogram are complementary. None of them defines a formal
open protocol with compliance tests and a community governance model.

Where we are — and what we need

The whitepaper v1.0 is complete and notarized (SHA-256 + IPFS).
The architecture is defined. The governance model, RFC process, and
compliance test specification (HCT) are in place.

The reference implementation doesn't exist yet.

This is where you come in.

We're looking for contributors with experience in:

Browser extension development (Chrome/Firefox/Safari)
Privacy engineering
Differential privacy applied to event streams
Behavioral biometrics research

Research and design contributions are equally welcome — not just code.
Good first issues are open and ready to be picked up:

[R-01] Survey browser APIs for input event interception
[R-02] Survey pointer and scroll event APIs across browsers
[R-03] Behavioral biometrics classifier survey
[R-04] DP libraries for real-time event streams
[R-05] Anti-bot system behavior analysis
[D-01] Define human plausibility ranges for Persona Mixer parameters

Links

HOLogram is an independent open project. No company, no VC, no advertising interest.
Community-driven from day one.