Architecture

Privacy by Design Exam Proctoring

Integrity monitoring built on an architecture that makes privacy violations structurally impossible — not just contractually prohibited.

privacy by design proctoringprivacy first exam monitoringno video upload proctoringWASM exam integrity
Zero raw data upload

No video, no audio, no screenshots leave the device during detection. The architecture enforces this — it is not a policy setting.

Rust/WASM detection engine

Face, gaze, and voice analysis compiled to WebAssembly and executed client-side. Vendor cannot intercept what never reaches the server.

Tenant-owned cryptography

Each tenant holds their own ECDSA P-256 private key. ProctorSafe cannot forge or tamper with session payloads.

Minimal signal transmission

Network monitoring logs only the domain name and timestamp of a suspect request — never the URL path, request body, or query parameters that could expose exam content or PII.

The difference between policy and architecture

Most online proctoring tools handle privacy through policy: they promise not to share your data, retain it only for a defined period, and process it in compliant data centres. These are real commitments — but they are enforced by contracts and audits, not by code.

ProctorSafe takes a different approach. The architecture is designed so that the most sensitive data — raw video, audio, facial geometry — is never transmitted to ProctorSafe's servers in the first place. A policy violation requires a bad actor with access; an architectural constraint has no such requirement.

The detection engine: Rust compiled to WebAssembly

ProctorSafe's detection capabilities run in a Rust codebase compiled to WebAssembly (WASM). The WASM module is downloaded once and executed inside the candidate's browser — the same security boundary as any other browser script, but with native-level performance. What the WASM module does:

Face detection

identifies face presence, multiple faces, and face disappearance using a convolutional model running at adaptive frame rates

Gaze / look-away detection

the GazeEngine estimates whether the candidate is looking at the screen, with debounce logic to suppress transient movements

SIMD executon

on browsers that support WebAssembly SIMD, the engine selects a SIMD-optimized build at runtime for higher throughput

What stays on-device: every frame analyzed. No pixel data is transmitted to ProctorSafe.

Voice analysis without audio upload

Second-speaker detection uses the browser's getUserMedia API to access the microphone. The audio pipeline runs entirely in the browser:

  1. The preflight step captures a voice sample and computes a log-mel spectral profile and median F0 (fundamental frequency) for the candidate's voice.
  2. During the exam, the same pipeline computes the spectral distance between current audio and the enrolled profile.
  3. If the distance or F0 delta exceeds a configurable threshold, a SECOND_SPEAKER_SUSPECTED event is emitted — containing only the timestamp, confidence score, and evidence metrics.

What reaches ProctorSafe: a structured event with numeric evidence. No audio samples, no voice recordings.

Network detection without URL surveillance

AI extension detection intercepts outbound network requests at the browser API level. ProctorSafe patches fetch and XMLHttpRequest to check the request hostname against a domain blocklist (ChatGPT, Claude, Gemini, Copilot, and similar services).
  • If no match: the request proceeds normally, nothing is logged.
  • If a match: a `NETWORK_SUSPECT` event is emitted containing the hostname, HTTP method, and timestamp — never the full URL (which may contain exam content or PII).
What ProctorSafe receives: a domain name and timestamp. Not the URL path, not the request body, not any query parameters.

Tenant-owned cryptography

Every tenant generates their own ECDSA P-256 key pair. The public key is uploaded to ProctorSafe; the private key never leaves the customer's infrastructure. Session payloads are signed with the tenant's private key before transmission. ProctorSafe's server verifies the signature but cannot forge one — because the private key is unknown. This means:
  • A ProctorSafe employee cannot inject false integrity events into a session
  • A malicious actor with access to ProctorSafe's database cannot retroactively alter session evidence

What this means for your DPIA

Under GDPR Article 35, a Data Protection Impact Assessment is required when processing is "likely to result in a high risk to the rights and freedoms of natural persons." Biometric processing — including facial analysis — typically triggers this requirement. ProctorSafe's architecture changes the DPIA scope significantly:
Processing activityTraditional proctoringProctorSafe
Facial analysisCloud: vendor's AI systemIn-browser WASM: candidate's device
Data subject of analysisCandidate's biometric data at vendorCandidate's local device only
Video storageVendor cloud (months/years)Not stored (never transmitted)
Third-party AI processingYes (video → AI service)No (WASM runs locally)

Get started

Frequently Asked Questions

Common questions about privacy, compliance, and integration.

It means the system architecture prevents unnecessary data collection — not just prohibits it in a policy document. ProctorSafe's WASM engine processes biometric signals in the candidate's browser. There is no code path that sends raw video or audio to ProctorSafe's servers.

Ready to Get Started?

Try the interactive demo in your browser, or contact us for a walkthrough tailored to your program.