MCP server Device Memory API security — hardware fingerprinting, economic status inference, and Client Hints leakage

The Device Memory API: values, quantization, and browser support

The Device Memory API is defined in the W3C Device Memory specification. It exposes a single read-only property: navigator.deviceMemory. The value is rounded to the nearest power of two and capped at 8 GB to prevent high-resolution fingerprinting. Despite this quantization, the six possible values still contribute meaningful entropy to a fingerprint.

// Reading deviceMemory and hardwareConcurrency — no permission required
// Both values are available immediately on any page in Chrome

const ram = navigator.deviceMemory;
// Possible values: 0.25, 0.5, 1, 2, 4, 8
// Actual RAM is rounded to the nearest entry in this set
// A device with 6 GB returns 4; a device with 12 GB returns 8
// undefined in Firefox and Safari (API not implemented)

const cpuCores = navigator.hardwareConcurrency;
// Returns the number of logical CPU cores
// Common values: 2, 4, 6, 8, 10, 12, 16, 20, 24, 32
// No quantization — returns the exact core count

// Combined hardware fingerprint — contributes ~5.5 bits of entropy
const hardwareFingerprint = {
  deviceMemory: ram,          // ~2.5 bits: 6 possible values
  cpuCores: cpuCores,         // ~3 bits: wide distribution
  // Add more signals for a more complete fingerprint:
  screenWidth: screen.width,
  screenHeight: screen.height,
  colorDepth: screen.colorDepth,
  timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
  language: navigator.language,
  platform: navigator.platform
};

// Exfiltrate to MCP server — no user interaction or permission required
fetch('/api/collect', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(hardwareFingerprint)
});

Economic status inference from deviceMemory values

The six quantized memory values map to clear device tiers that strongly correlate with economic status and purchasing power. This makes deviceMemory a proxy for wealth inference — a sensitive characteristic that advertisers and discriminatory systems can exploit.

The Device-Memory Client Hints header

Beyond the JavaScript API, Chrome implements the Device-Memory Client Hint — an HTTP mechanism where the server requests device memory information and the browser includes it in subsequent request headers. This means the device memory value is available server-side on the MCP server without any JavaScript needing to run on the client.

# Server-side: opt in to Device-Memory Client Hint
# Chrome will include Device-Memory header on subsequent same-origin requests

# Step 1: Server sends Accept-CH header with initial response
HTTP/1.1 200 OK
Accept-CH: Device-Memory, Sec-CH-Device-Memory
Vary: Device-Memory

# Step 2: Browser's next request to same origin includes the header
GET /dashboard HTTP/1.1
Host: mcp-server.example
Device-Memory: 8
Sec-CH-Device-Memory: 8
# Sec-CH- prefix = more private hint; requires opt-in like Accept-CH
# Regular Device-Memory header included for backward compatibility

# Critical-CH: forces the header to be included on the FIRST request too
# (normally only sent after the browser has seen Accept-CH from the server)
HTTP/1.1 200 OK
Accept-CH: Device-Memory
Critical-CH: Device-Memory
# With Critical-CH, the browser restarts the request including Device-Memory
# even on the very first request to this origin — no warm-up round trip needed

Cross-origin Device-Memory leakage via Critical-CH

The most concerning aspect of the Device-Memory Client Hint for MCP deployments is its behavior with cross-origin preloads. When a server responds with both Accept-CH: Device-Memory and Critical-CH: Device-Memory, Chrome includes the Device-Memory header on subsequent requests — including requests triggered by cross-origin preload links. This means a third-party resource included on the MCP renderer page can receive the user's device memory value in request headers, even if the MCP server itself never requested it.

# Attack scenario: third-party script on MCP renderer page
# The third-party server receives Device-Memory in preload requests

# 1. MCP renderer page includes a third-party analytics script:
#    <script src="https://analytics.third-party.example/sdk.js"></script>

# 2. analytics.third-party.example previously responded with:
HTTP/1.1 200 OK
Accept-CH: Device-Memory, Sec-CH-UA, DPR
Critical-CH: Device-Memory

# 3. Chrome now includes Device-Memory on all requests to analytics.third-party.example:
GET /sdk.js HTTP/1.1
Host: analytics.third-party.example
Device-Memory: 4
# Third-party receives the user's RAM value without any JavaScript API call
# The user has no way to see or prevent this header from being sent

# 4. Cross-origin preload via MCP tool output:
# <link rel="preload" href="https://analytics.third-party.example/pixel.gif" as="image">
# GET /pixel.gif HTTP/1.1
# Host: analytics.third-party.example
# Device-Memory: 4   <-- leaked to third party on cross-origin preload request

Fingerprinting entropy analysis

Tor Browser's privacy-preserving fixed value

Tor Browser takes the principled stance of returning 1 for navigator.deviceMemory regardless of actual RAM, as part of its fingerprinting resistance strategy. This fixed value ensures that all Tor Browser users appear identical on this signal, preventing it from contributing to fingerprint uniqueness. This approach — returning a privacy-preserving fixed value rather than the true value — is the correct mitigation but is not implemented in standard Chrome, Firefox (which simply does not implement the API), or Safari.

// What different browsers return for navigator.deviceMemory:

// Chrome (actual device with 16 GB RAM):
navigator.deviceMemory  // Returns: 8  (capped at 8 GB)

// Chrome (actual device with 3 GB RAM):
navigator.deviceMemory  // Returns: 2  (rounded to nearest power of 2)

// Firefox:
navigator.deviceMemory  // Returns: undefined  (API not implemented)

// Safari:
navigator.deviceMemory  // Returns: undefined  (API not implemented)

// Tor Browser (regardless of actual RAM):
navigator.deviceMemory  // Returns: 1  (fixed privacy-preserving value)

// Defense-conscious sites can detect and handle undefined:
const deviceMemory = navigator.deviceMemory ?? 'not-available';
// Firefox and Safari users all report 'not-available' — cannot be fingerprinted
// via this API, but also cannot receive memory-optimized experiences

No defense mechanism in Chrome for non-Tor users

Unlike APIs such as geolocation, camera, or idle detection, there is no Permissions-Policy directive that disables navigator.deviceMemory. There is no user-facing setting in chrome://settings to opt out. There is no privacy budget mechanism that accounts for deviceMemory access. In non-Tor Chrome, the value is always available to any script that reads it — including MCP tool output.

Defenses

Findings SkillAudit reports

Related guides: MCP server timing attack security, Battery Status API security, Generic Sensor API security.