Data
Privacy.

GrayPass is built on one architectural rule: the system must work without ever holding data an attacker would want. Privacy here is not a policy layered over the product; it is the reason the pipeline is shaped the way it is.

This document explains, in plain language, exactly what data exists at each stage, where it lives, and what control you have over it. The Privacy Policy governs; this document adds product-level precision.

With consent, the SDK observes three timing channels while a person uses an application:

• Pointer dynamics: the velocity, curvature, and pause structure of cursor or touch movement - as timings and geometry, never screen contents.
• Typing cadence: the intervals between key events. The keys themselves are never read; there is no code path that receives the character, only the clock.
• Reaction and scroll rhythm: how quickly a person responds to what appears, and the tempo of their scrolling.

These are “timings only.” The SDK cannot reconstruct what you typed, what you read, or what you saw. It measures how you move, not what you do.

The raw timing stream is processed in the browser, in-session. It is reduced to a compact statistical vector on the device, and the raw series is discarded. The raw behavioral stream is not transmitted, not logged, and not recoverable after the session ends.

On this website specifically, the live demonstration goes further: everything runs locally in your tab, nothing is transmitted at all, and the page shows you its own counters to prove it.

The vector that leaves the session is folded with a per-user random salt into a “salted print” - a small template that can confirm a match but cannot be run backwards into behavior.

• Per-user salts mean the same behavior produces different prints in different applications: nothing is portable between accounts or sites.
• A stolen print scores nothing without its salt, so a spilled database row has no value.
• Prints are cancelable: rotating the seed re-issues the template in minutes and invalidates everything derived from the old one. A face or fingerprint cannot do this; a print can.

Stored, encrypted at rest:

• The salted behavioral print (a small vector) and its helper data.
• Decision logs: accept/deny, calibrated confidence, and a human-readable reason code.
• Per-user salts, held separately from the prints they belong to.

Never stored, by construction:

• Raw behavioral streams.
• Typed content, of any kind, ever.
• Static biometric identifiers: no photographs, no face geometry, no fingerprints, no voiceprints.

You can erase your print on request, and customers can erase any end user's print through the API. Deletion destroys the template and its helper data; because raw behavior was never kept, there is nothing else to remove.

Seed rotation is available on demand and after any suspected exposure: identity continues, the template behind it is replaced, and prior artifacts stop matching. Erasure requests sent to hello@graypass.org are honored within thirty (30) days; API-driven deletion is immediate.

By default, no research dataset exists. If you explicitly opt in to improving the matcher, the contributed session data is pseudonymized, double-encrypted, held apart from production, and deleted when you withdraw - which you can do at any time, from the same place you opted in.

Production runs on U.S. cloud infrastructure with encryption in transit (TLS 1.3, HSTS, per-request nonces) and at rest (envelope encryption). Sub-processors are limited to hosting, storage, and transactional email, each under a data-processing agreement. The current list is available on request at hello@graypass.org, and customers with a DPA are notified before any addition.

If anything here is unclear, or you want the deeper technical walkthrough (threat model, control set, data-flow diagrams), email hello@graypass.org - security questions land with the people who built the pipeline. Region-specific rights live in the GDPR document and the BIPA policy.