MCP server Screen Wake Lock API security — wake lock as user behavior oracle, battery drain DoS, lock release on page visibility change, and permission model

Wake lock release as a user presence oracle

The WakeLockSentinel returned by navigator.wakeLock.request() fires a release event whenever the OS releases the lock. The browser releases screen wake locks automatically when the document becomes hidden — when the user switches tabs, minimizes the browser window, or locks the device screen. The release timestamp is observable:

// Wake lock as user presence oracle — observable by any script on the page
const sentinel = await navigator.wakeLock.request('screen');

sentinel.addEventListener('release', () => {
  const releaseTime = Date.now();
  // User switched tabs or locked screen at releaseTime
  // This is a behavioral signal: the user was present until this timestamp
  // ... can be logged, can be exfiltrated, no additional permission required
  logUserPresence({ event: 'screen_hidden', at: releaseTime });
});

// Pair with visibilitychange for confirmation
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'visible') {
    // User returned — re-request wake lock
    navigator.wakeLock.request('screen').then(s => { /* ... */ });
  }
});

Battery drain DoS via multiple wake locks

A single screen wake lock is released automatically when the page becomes hidden. But a malicious MCP tool can trigger a large number of concurrent wake lock requests. While the browser OS prevents the screen from turning off for each lock, holding many locks simultaneously consumes battery. On mobile devices, continuous screen-on prevents the CPU from entering deep sleep states, significantly increasing power consumption:

// Dangerous: MCP tool response triggers multiple wake lock requests in a loop
// (via injected script in tool output rendered without sanitization)
async function maliciousWakeLocks() {
  const locks = [];
  for (let i = 0; i < 50; i++) {
    try {
      locks.push(await navigator.wakeLock.request('screen'));
    } catch {}
  }
  // 50 active screen wake locks — screen stays on permanently, battery drains
  // locks are not released until page is closed
}

// Safe: MCP UI acquires at most one wake lock; releases when tool completes
let activeLock = null;

async function acquireWakeLockForTool() {
  if (activeLock) return; // already have one — don't acquire another
  try {
    activeLock = await navigator.wakeLock.request('screen');
    activeLock.addEventListener('release', () => { activeLock = null; });
  } catch {}
}

async function releaseWakeLock() {
  if (activeLock) {
    await activeLock.release();
    activeLock = null;
  }
}

Re-acquisition on visibilitychange as focus tracking

The standard pattern for wake locks is to re-acquire the lock when the page becomes visible again after being hidden. This pattern is documented in the W3C spec. Legitimate use case: the MCP tool is still running and should keep the screen on when the user returns. But combined with an event log, re-acquisition on visibilitychange creates a tab-focus tracking mechanism — the script knows exactly when the user returns to the tab and how long they were away:

// This pattern is used for user tracking — log each re-acquisition
document.addEventListener('visibilitychange', async () => {
  if (document.visibilityState === 'visible') {
    const returnTime = Date.now();
    const absentDuration = returnTime - lastHiddenAt;
    // absentDuration reveals user's away time — can be exfiltrated
    trackUserBehavior({ event: 'returned', absentMs: absentDuration });
    // ... re-acquire wake lock for legitimate purpose
  } else {
    lastHiddenAt = Date.now();
  }
});

Defense: MCP UIs that use wake locks should not log re-acquisition events for analytics. If the tool execution is complete when the user returns, do not re-acquire the lock. Limit wake locks to the duration of the active tool execution and release promptly on completion.

Security comparison: Screen Wake Lock patterns for MCP UIs

SkillAudit findings

See also: MCP server PerformanceObserver security (other user-behavior timing side channels) · MCP server IntersectionObserver security (element visibility as user presence signal)