How PRSN Human Verification works
PRSN Human Verification establishes that a live person is operating a genuine device at the moment of a request. The system rests on two signals: platform attestation of the app instance, and a physical challenge issued by the server whose sensor evidence is evaluated on the server. Neither signal is sufficient alone. Attestation without the challenge proves only that a device exists. The challenge without attestation could be satisfied by a modified client that fabricates sensor data. Together they require that a real device, running the unmodified app, produced a physically plausible motion in response to a challenge it could not have known in advance.
Section 1 describes the system as deployed in the PRSN iOS app. Section 2 describes the proposed extension that offers the same check to third-party sites and apps.
1. The deployed system
1.1 Device attestation
Every verification request carries an attestation token representing a genuine Apple device, backed by Apple App Attest. App Attest generates a key pair in the device's Secure Enclave and has Apple certify that the key belongs to a legitimate installation of the PRSN app on genuine hardware. PRSN's servers enforce the token on every verification and content-write endpoint in production, and a deployment guard refuses any configuration that would weaken it. Emulators, re-signed builds, and scripted clients fail at this layer and never receive a challenge.
1.2 Challenge issuance
Challenges are constructed on the server. When the app requests verification, the server creates a session bound to the context of the request (entry to the app, or creation of a post or comment) and selects a random nonce, a randomized set of cues, and the actions the evidence must meet. The server stores only a hash of the nonce. The session is single-use and expires after a short interval. The app receives the nonce and the schedule; it cannot choose either.
1.3 The physical action
The app delivers each cue as needed and the user responds with the associated action, such as swaying the phone. Throughout the challenge window the app records the device's sensors and creates a pre-verified payload for our servers to validate.
1.4 Server evaluation
The app submits the nonce and verified motion payload and the server consumes the session in a single transaction, confirms that the context and the requesting account match the session, and compares the nonce against the stored hash in constant time. The evidence then passes through an ordered series of forensic checks.
1.5 Outcome
At app entry, a pass returns a short-lived liveness attestation that carries no write authority. At content creation, a pass mints a short-lived, single-use grant scoped to the requesting account, and the endpoints that create posts and comments reject requests without a valid grant. Sessions are stamped with their context, so an entry session cannot be replayed to mint a content grant.
1.6 Data handling
The sensor streams are transmitted for evaluation, held in memory for the duration of the request, and discarded. The server retains the session record (nonce hash, cues, and verdict) and aggregate failure counts. The sway challenge does not use the camera and collects no biometric identifier. The Privacy Policy states the governing terms.
1.7 Cost of attack
Four properties raise the cost of a sustained attack above the cost of a single bypass.
Fresh challenges. Every session has a new nonce and a new schedule, so evidence recorded in one session cannot satisfy another.
Escalating cooldowns. Repeated failures trigger progressively longer cooldowns. Evidence of tampering skips the grace period a genuine user is given to learn the gesture.
Challenge substitution. The challenge type is selected by the server per session. Additional motion challenges are implemented in the app and can be enabled server-side, so a bypass of one challenge is answered by rotating to another.
Device-level blocking. PRSN can enable a durable per-device block through Apple DeviceCheck. The flag is stored by Apple, scoped to the device and to PRSN, and survives reinstallation of the app. A device that has produced physically impossible evidence is then refused on every subsequent attempt. The cost of an attack is paid per device rather than per attempt.
2. Proposed extension: a drop-in captcha alternative
2.1 Goal
Offer the check in Section 1 to any website or app as a replacement for a captcha, with drop-in compatibility with existing captcha integration conventions: a script tag, a container element, a site key, a hidden response field, and a server-side verification call. A partner migrates by changing a small set of strings rather than rewriting form handling.
2.2 Protocol
Session
The partner page embeds a widget. The widget requests a session from PRSN's verification service, which records the requesting origin.
Handoff
The widget renders a QR code or deep link. The visitor opens it in the PRSN app.
Consent and challenge
The app displays the requesting origin and asks for consent. It then runs the challenge in Section 1, evaluated by the same server core.
Proof and token
On a pass, PRSN's backend issues a signed proof bound to the session, the origin, and a single-use identifier, with a short expiry. The verification service validates the proof and mints a single-use, short-lived token.
Validation
The widget places the token in the partner's form. The partner's backend validates it server-to-server. The response states that a human completed a fresh challenge on a genuine device for this origin, and nothing else.
2.3 Properties
Origin binding. The origin is derived from the browser request, shown to the user at consent, bound into the proof and the token, and checked at validation. A QR code relayed to another site fails at validation.
Single use. Proofs and tokens are consumed on first validation. Reuse is rejected.
Server-to-server verdict. The browser holds only an opaque handle. The result travels from PRSN's servers to the partner's servers.
No fingerprinting. The widget collects no behavioral or environmental signals from the browser. The human signal comes from the device and the action.
2.4 Native integration
The verification module in the PRSN app (challenge, session, and cooldown management) is structured for packaging as an SDK, so a partner app can invoke the check in place rather than through a QR handoff.
2.5 Advanced Verification
For most sites, a human action and a signed token is the right shape. Some partners need more, such as those verifying employees or guarding access to systems where the cost of a single bad actor is unusually high. For these cases, an Advanced Verification track can return a verified artifact, such as a photo or a short audio clip, alongside partner-specific signals. Advanced Verification is designed with each partner rather than offered off the shelf.
partnerships@fre-studios.comThe deployed system runs inside PRSN, the human-only social network. Download it to complete the challenge described in Section 1.
