Cipher on phones and tablets

How Cipher keeps response quality honest across desktop, phones, tablets, and hybrids — by scoring the signals each device actually produces.

Most of Cipher's behavioral checks were built for a mouse and a keyboard. A phone or tablet has neither, so a naive system simply sees "no mouse movement, no keystrokes" and either flags an honest person or, worse, waves a bot through. Cipher takes a different approach: it first works out what kind of device the respondent is on, then scores the response on the signals that device actually produces — not the ones it can't.

Why this matters

Roughly half of survey traffic is mobile. Without a touch-native pipeline, that half of your data is graded on signals that were never collected. Cipher closes that gap rather than guessing — and a respondent on an iPhone is judged as fairly as one on a laptop.

Which device is it, exactly?

Before scoring anything, Cipher classifies every respondent into one of five device classes. This is the decision everything else branches on, because the absence of a signal only means something once you know whether that signal was ever possible.

Class	What it is	How Cipher grades it
Desktop	Mouse + keyboard, no touch	Mouse dynamics, keystroke timing, scroll, hover
Mobile	A phone (coarse pointer, touch)	Touch, swipe, pressure, device motion, on-screen keyboard
Tablet	An iPad or Android tablet	Same touch-native signals as mobile, with a larger surface
Hybrid	A touch laptop / 2-in-1 (both a fine and a coarse pointer)	Whichever the person actually used — mouse and touch
Unknown	Class couldn't be determined	Scored conservatively; never auto-passed on thin evidence

A couple of cases are deliberately handled rather than guessed:

iPads that pretend to be desktops. Since iPadOS 13, Safari on an iPad reports itself as desktop Safari on a Mac. Cipher catches the tell — a "Mac" that also reports multiple touch points is an iPad — and classifies it as a tablet so it gets the touch pipeline, not the desktop one.
Hybrids and 2-in-1s. A Surface or a touch-screen laptop can produce both mouse and touch input. Cipher recognizes it as hybrid and reads whichever signals the respondent actually generated, instead of assuming one and missing the other.

What each device gives us — and what it can't

Cipher's guiding principle is to score on the data a device produces, not mourn the data it doesn't. Each device class populates a different column, and Cipher grades on the column that's actually full.

Signal	Desktop	Phone / Tablet	Hybrid
Mouse path, velocity, curvature	✓	—	if used
Keystroke dwell / flight timing	✓	partial¹	✓
Scroll dynamics	✓	✓ (touch fling)	✓
Touch pressure & contact area	—	✓²	if touched
Swipe shape & velocity	—	✓	if touched
Device motion (hand tremor)	—	✓³	—
Orientation / tilt	—	✓³	—
On-screen keyboard lifecycle	—	✓	sometimes

¹ On-screen keyboards don't expose per-key timing the way a hardware keyboard does. ² Only on hardware that measures force (e.g. many iPhones); Cipher treats "no force data" as a missing sensor, not as suspicious. ³ Motion and orientation are sensor-gated on iOS — see coverage below.

So a phone never loses points for having no mouse trail, and a desktop is never expected to report hand tremor. The score is always built from evidence that fits the device in the respondent's hand.

The touch-native signals

When a respondent answers on a touch device, Cipher captures things a desktop session never produces:

Touch pressure and contact area. How firmly each tap lands and how much of the screen the fingertip covers. Real fingers vary; synthetic touch injection does not.
Swipe shape. The curve, speed, and wind-down of each scroll. A human flick arcs and decelerates; a scripted one is a straight line at constant speed.
Device motion. The tiny, constant tremor of a device held in a hand. A real phone is never perfectly still. An emulator or a device driven on a bench reports flat, identical motion.
Orientation. The tilt of the device as it is held and turned.
The on-screen keyboard. Whether it actually opened, and whether a long answer appeared gradually (typing or dictation) or all at once (a paste).

These run in the background while someone answers. They never interrupt the survey, and they add no visible step for the respondent.

Honest about what it cannot see

A touch device will not always give Cipher everything. iOS, for example, gates the motion sensor behind a permission prompt, and Surbee chooses not to surprise respondents with that prompt by default. So Cipher records a coverage profile for every response:

Full. Touch and motion were both available.
Partial. Touch was available but motion was not.
Unavailable. No touch signals were produced.

Coverage is not cosmetic. On partial coverage Cipher leans less heavily on the touch signals it does have and lowers its own confidence, so a thin reading is never presented as a confident clean pass. A low score on partial coverage surfaces for review rather than being auto-accepted.

Built to not cry wolf

A false accusation against a real respondent is worse than a missed bot, and touch devices are full of innocent behavior that looks odd at first glance. Cipher is tuned around the obvious traps:

A phone resting flat on a table reads as almost motionless. Cipher does not treat stillness as fraud; it looks for the constant, bit-identical motion of an emulator, which a real device on a desk never produces (a real phone's sensor noise always keeps it just above that floor), and it stands down the moment it sees genuinely human swipes and taps.
Some devices report a fixed touch pressure for every tap. Cipher treats that as "this hardware does not measure pressure," not as suspiciously uniform input.
A fast flick through a long survey is normal, not a scripted gesture.
Voice dictation and autofill produce text with no keystrokes. Cipher only reads a paste when a large block of text appears in a single moment, not merely because no keys were pressed.

Part of the same learning loop

The touch pipeline is not a static set of rules bolted on the side — it feeds the exact same continuous-learning loop that improves Cipher on desktop. Every scored response, on any device, makes the next model a little better.

Here's how a mobile response travels through the loop, step for step with desktop:

Features. Cipher distills the raw touch, swipe, pressure, and motion streams into a fixed set of mobile features and appends them to the desktop feature set. The device class is itself a feature — that is what lets the model learn that "no mouse" means bot on a desktop but is perfectly normal on a phone.
Correct labels. The automatic labels that seed training are device-aware. The desktop "no mouse, no keyboard" fraud rule is never applied to a phone; mobile responses are labeled instead by touch-native signals — a rigid (emulator) device, synthetic touch, taps on a single point, a paste with no keyboard. This is the critical part: without it, every honest phone respondent would be mislabeled as fraud and the model would learn the wrong thing.
Your verdicts. When you confirm or reject a flagged response in the dashboard, that human judgment becomes the highest-confidence label of all and re-enters the training set.
Retraining. On a schedule, Cipher retrains on the growing, device-balanced pool of real labeled responses (mixed with synthetic examples of both desktop and mobile fraud and legitimate behavior), and only promotes the new model if it genuinely scores better than the current one.
Automatic rollout. A promoted model is served to every survey immediately — no redeploy — so the improvements from real mobile traffic reach your next response.

The result is a single engine that watches mouse dynamics on a laptop and finger pressure, swipe physics, and hand tremor on a phone — grading each response on evidence that fits the device, telling you per response which device it was and how much it could see, and getting measurably better at both as more people respond.