I work on candidate screening software, so I spend a lot of time on this question from the other side. Here's a plain explanation of what a web page can detect, the code behind it, and the reasons a sensible system treats every signal as a question rather than a verdict.

Signal 1: the tab became hidden

The Page Visibility API tells a page when it stops being visible, for example when the user switches tabs or minimizes the window.

document.addEventListener('visibilitychange', () => {
  logEvent({
    type: document.hidden ? 'tab_hidden' : 'tab_visible',
    at: Date.now(),
  });
});

That's all there is to it. The page learns that it was hidden and when it came back. It doesn't learn which tab you switched to or what you looked at.

Signal 2: the window lost focus

Focus is different from visibility. If you click into another application while the browser window stays on screen, the tab is still "visible" but the window has lost focus.

window.addEventListener('blur', () => logEvent({ type: 'window_blur', at: Date.now() }));
window.addEventListener('focus', () => logEvent({ type: 'window_focus', at: Date.now() }));

This catches things like alt-tabbing to a chat app on a second monitor. It also catches a lot of innocent behavior, which we'll come back to.

Signal 3: text was pasted

Paste events fire on the element receiving the paste. A page can record that a paste happened and how long the pasted text was.

editor.addEventListener('paste', (e) => {
  const text = e.clipboardData.getData('text');
  logEvent({ type: 'paste', length: text.length, at: Date.now() });
});

Note what the browser allows here. The page only sees clipboard contents at the moment you paste into it. It can't read your clipboard in the background. A well-behaved system records the length and timing, not the content.

Signal 4: typing rhythm

Some tools look at keystroke timing. Someone writing code thinks, types in bursts, backspaces and pauses. Someone retyping an answer from another screen tends to type at a steady pace with few corrections. This is a weaker signal than the others and easy to over-interpret, so treat it with care.

What a browser cannot see

This is where a lot of fear (and a lot of vendor marketing) goes wrong. A normal web page cannot:

• see other applications or your screen, unless you explicitly start screen sharing

• see which tab you switched to

• read your clipboard when you aren't pasting into the page

• detect a second device sitting next to the laptop

• detect someone in the room whispering answers

Anything beyond those limits needs extra steps the candidate has to agree to: screen sharing, a webcam, a desktop app that checks for running processes, or a phone set up as a second camera.

Why every signal produces false positives

Here's the part that matters most if you're building or buying one of these systems. Every one of those events has boring explanations.

• Tab hidden: a calendar notification, a password manager popup, a candidate checking the job description in another tab

• Window blur: a Slack ping, a Windows update prompt, a second monitor with the interview instructions open

• Paste: pasting your own code from an earlier step, or a long variable name from the question text

• Steady typing: some people are just fast, careful typists

If a system turns raw events into an automatic "cheating" score, it will flag honest people. That's unfair to candidates, and it's bad for the people hiring too, because they end up rejecting good candidates over a notification sound.

What a reasonable design looks like

From working on this, a few principles hold up:

1. Tell the candidate exactly what's recorded before the session starts. People behave more naturally when nothing is hidden, and in several US states there are legal requirements around AI in hiring that make transparency a good default anyway.

2. Record events, not content. A timestamp and an event type are enough. Avoid storing clipboard contents or keystrokes themselves.

3. Look for patterns, not single events. One blur means nothing. Long pauses before every answer, followed by large pastes, with repeated focus loss, is worth a closer look.

4. Put a human in the loop. A reviewer should look at flagged sessions in context before anything reaches a hiring decision.

5. Show the evidence, not just a score. "3 focus changes, longest 4 seconds, all during question 2" is far more useful than "integrity: 72%."

If you're the candidate

You don't need to be nervous about any of this. Close notification-heavy apps, keep the interview in one window, and if something interrupts you, say so out loud or in the chat. A sensible reviewer will see the context.

Disclosure: I work on Simplehire, which screens candidates for staffing agencies and uses the kind of event logging and human review described above. The examples here are generic and work in any modern browser.