What we defend. What we don't.
What we defend against, what we don't, what we collect, what we don't, plus the unintuitive case for putting a kernel driver between you and the proctor stack instead of a browser extension. Read this if you are paranoid; it is written for you.
Is Aceloop safe?
Yes: within the surface we defend, and honestly outside it. Inside our surface (browser content scripts, screen-share capture, process enumeration, automated proctor-vendor detection) the four-layer kernel architecture beats every documented detection vector. Outside our surface (a human watching over your shoulder, an interviewer asking you to walk through your reasoning, audio cues on the call) no software answer exists, and we say so. On data: we don't store your interview problem, your code, or your test output.
What we defend against, and what we don't.
We beat the parts of the proctor stack that are software. The parts that are human or audio or in-person, we do not. Anyone selling you software that beats those is selling you a story.
- Browser content scripts that log keystrokes, focus changes, and hotkey events. Our hotkeys are captured at the kernel keyboard hook; no keydown leaks into the tab.
- Screen-share capture (Zoom / Meet / Teams / Chime): our overlay is stripped from the Windows display pipeline before any capture path.
- Process enumeration: no entry in the task list a proctor scan can read.
- Automated proctor-vendor detection queries: answered indistinguishably from a clean machine.
- A human watching over your shoulder or a second in-person observer.
- An interviewer asking you to explain your reasoning out loud, the explain-it-back vector.
- Webcam recording of your eyes and posture, reviewed by a person.
- Any policy question: whether you should use it is your call and your risk.
What leaves the machine.
We don't store your interview problem, your code, or your test output. The model call is stateless on our side: when you press a hotkey, the desktop app extracts text from process memory, sends it directly to the model provider, streams the response back, and forgets the whole transaction.
What we do log: license-key activation events (hardware-ID hash, timestamp), Stripe billing events (customer ID, subscription state), anonymized crash reports, and product-funnel telemetry. Nothing a proctor, employer, or platform could meaningfully request.
The unintuitive case.
A kernel driver from an unknown vendor sounds dangerous; a browser extension sounds safer. The instinct is wrong for this problem. User-mode tools hook user-mode DLLs, and anti-cheat scanners walk those load lists on every interview start. Once a loader pattern is known, the scanner fingerprints it within weeks.
A signed kernel driver goes through Microsoft's WHQL attestation, ships under our EV cert, and carries an immutable per-release hash. Proctoring stacks don't ship signed kernel drivers to candidate machines, so the detection ceiling is "they'd need their own kernel driver to see us", which they don't ship.
Don't trust adjectives. Trust mechanics.
Run the key-event viewer against any AI tool, exhaust the free tier on your real platform, and verify the driver's signature chain before you install.