Counts vs. content: why the distinction decides your exposure

A keystroke count is a number: this person produced 4,120 keystrokes during this hour. A keystroke log is content: this person typed these characters in this order. The first is an activity signal. The second is a transcript of everything an employee wrote, including the things they wrote in a personal message, a password field that did not mask correctly, or a message to a lawyer.

The legal exposure is a different category

Capturing content pulls a deployment into rules that activity counting usually avoids. Depending on jurisdiction, recorded content can implicate interception and wiretap statutes, attract heightened consent requirements, and create obligations around data that was never meant to be collected — a password, a health disclosure, a union conversation.

The practical problem is that content capture is indiscriminate. You cannot promise a client that a keylogger will not capture privileged or sensitive material, because it captures whatever was typed. A count cannot capture any of it, which is a promise that survives contact with counsel.

Requirements vary by location and this is not legal advice — see the notice and consent checklist for the questions to put to your client's counsel.

Antivirus treats the two differently, and it is right to

The technical mechanism for capturing typed content — low-level input hooks that intercept keystrokes before the target application sees them — is the same mechanism credential-stealing malware uses. Endpoint protection vendors flag that behavior because flagging it is correct nearly all of the time.

An agent that counts input events does not need to see or retain the key identity, which keeps it out of the behavioral pattern that gets software quarantined. In practice this is the difference between an agent that deploys cleanly across a client base and one that requires per-vendor exclusions on every endpoint, each of which is a small permanent hole in the client's security posture.

What you lose by not capturing content

Honestly: very little of what the buyer actually wanted. The questions people ask of monitoring data are almost entirely about time and attention.

Only the last row requires content, and it is the row that turns an operations tool into an investigation tool. If a client's problem genuinely is the last row, they are describing a workplace investigation, and that is a matter for their counsel and HR rather than a setting in a monitoring product.

The deployment argument

Employees hear "monitoring" and assume the worst version of it. A specific, verifiable boundary — input volume is counted, typed content is never recorded, and here is the software running visibly in Task Manager — is a far better answer than a reassurance. It is also one you can put in writing, which is what a notice requires.

The honest limitation

Not capturing typed content does not make a monitoring deployment privacy-safe. Screenshots, window titles, and website addresses can still reveal a great deal, including things nobody intended to share. That is true of every product in this category, including ours. What you actually control in SnitchOS is a short list of named people who may view detailed activity, and whether a given person is monitored at all — cadence and retention are fixed by the platform rather than set per client. See screenshot monitoring without creating a liability.