8 June 2026 · 8 min read
Why we're not a keylogger: our privacy architecture
When people first hear that Learnaway analyses how a student types, a reasonable worry follows: does that mean you're logging every key they press? It's the right question to ask of any tool that watches the writing process, and the answer is no. We never record the characters a student types or pastes. Not by policy alone, but by design: the system is built so the content physically can't reach it.
The distinction between 'what was typed' and 'when and how much was typed' might seem minor, but it's the difference between surveillance and signal. Here's exactly what we capture and what we don't.
What Learnaway captures vs what it never sees
| Data type | Captured? | Why / Why not |
|---|---|---|
| The text a student types | Never | Keystroke events trigger a counter increment only - the character never enters our code |
| The text in a paste | Never | Paste handler receives only the length integer; the clipboard content is not accessed |
| Event type (keystroke, paste, focus change) | Yes | This is the core signal - the behaviour pattern, not the content |
| Timestamps of each event | Yes | Needed to compute session duration, typing cadence, and pause patterns |
| Paste size (character count) | Yes | A 2,400-character paste is the signal; what those characters say is not |
| Window focus / blur events | Yes | Tab-switches and idle gaps are part of the behavioural picture |
| Session duration | Yes | Ratio of session time to word count is one of the most reliable signals |
| The submitted final text | Yes - if the assignment uses submission | Teachers need to read the work; this is the same text they'd have received by email |
Timing, not text
Our capture code receives the timing and type of each event - a keystroke happened, a pause of 800ms occurred, a paste of 420 characters, the window lost focus - and nothing else. When a paste fires, the function that handles it takes a single number: the length. The pasted text is never passed in, so there's nothing to store or leak.
A keylogger records what you wrote. We record only the rhythm of writing it. These are fundamentally different things, and the architecture enforces that distinction rather than just asserting it.
The most important privacy property is that the guarantee is structural, not procedural. We couldn't accidentally log content even if we tried - the code path doesn't exist.
We store the least we can
Minimising collection is only half the story; the other half is retention. By default, we don't even keep the timing timeline after scoring. The writing process is scored on our server in memory to produce the signal a teacher sees, then the process stream is discarded. What's saved is the final text (so the teacher can read the work) and the analysis results.
Schools that want to replay how a piece was written can turn on Process Replay per assignment. Even then, the replay is content-free: it shows the rhythm of writing - typing bursts, pauses, paste sizes - never the words appearing. Students are always told what's recorded before they write.
Protecting what remains
For the data we do keep, the safeguards are concrete: encryption in transit and at rest, Row-Level Security in the database so teachers can only read their own classes' work, EU data residency for licensed European schools, configurable retention policies, and a Data Processing Agreement on request. The institution is the data controller; we're the processor, acting only on its instructions.
- Encryption in transit (TLS) and at rest
- Row-Level Security: a teacher sees only their own classes' submissions
- EU data residency available for licensed European schools
- Configurable data retention - schools set their own deletion timelines
- Data Processing Agreement available on request
- No data sold or shared with third parties for training or advertising
Why this matters for fairness
Not being a keylogger isn't just a privacy nicety: it's what makes the signals fair. Because we never see the words, we can't penalise a student for an unusual or non-native writing style - the exact failure mode that got text-based AI detectors pulled from universities. Reading the process, not the prose, is better for privacy and better for students.
Try Learnaway with your next homework
Related articles
Why AI detectors flag ESL students as cheaters - and how teachers can avoid itText-based AI detectors are systematically biased against non-native English writers. Here's the research, the legal risk, and a fairer detection approach.
- How Learnaway works: behavioural AI detection explained
Learnaway detects AI-assisted shortcuts by analysing how students write, not what they write. Here's a clear explanation of the process from assignment creation to teacher review.
- How to detect AI writing in student work: a practical guide
Text-based AI detectors are unreliable and unfair to ESL writers. A better approach examines how work was written, not what it says - here's a method that holds up.