モバイルフィンガープリント：未開拓のベクトル

Desktop anti-detect is a solved problem. Dozens of tools provide reliable fingerprint spoofing for desktop browsers. Mobile is a different story entirely.

Mobile browsers expose device-specific signals that don't exist on desktop: accelerometer data, battery status, touch pressure, gyroscope readings, and screen metrics tied to specific physical hardware. Desktop anti-detect browsers emulating mobile devices fail on these vectors because they can't fake what they don't physically have.

This is the gap, and platforms are aggressively exploiting it.

Mobile-Specific Fingerprinting Vectors

Touch Events

Desktop browsers don't generate touch events (they generate mouse events). When a desktop browser claims to be mobile by spoofing the user-agent, detection scripts fire touch event handlers:

function isTrueTouch() {
  return new Promise(resolve => {
    const el = document.createElement('div');
    el.addEventListener('touchstart', () => resolve(true), { once: true });
    
    const touchEvent = new TouchEvent('touchstart', {
      touches: [new Touch({
        identifier: 0,
        target: el,
        clientX: 100,
        clientY: 100,
        radiusX: 11.5, // Real finger ~11-12px radius
        radiusY: 11.5,
        force: 0.35     // Real touch has variable force
      })]
    });
    
    el.dispatchEvent(touchEvent);
    setTimeout(() => resolve(false), 100);
  });
}

Real mobile touches have characteristics that synthesized events don't replicate:

• Force/pressure — iOS and some Android devices report touch force (0.0-1.0 scale). Desktop emulation either omits force or uses a constant value.
• Touch radius — real fingers have 10-14px radius that varies by pressure. Emulation uses fixed values.
• Multi-touch — real users occasionally make accidental multi-touch contact. Pure automation never does.

Accelerometer and Gyroscope

Mobile devices have motion sensors that browsers can access via the DeviceMotion and DeviceOrientation APIs:

window.addEventListener('deviceorientation', (e) => {
  // Real device: continuous micro-movements even when "stationary"
  // Emulator: perfectly still (0,0,0) or absent
  const isReal = e.alpha !== null && e.beta !== null && e.gamma !== null;
  const hasNoise = Math.abs(e.beta) > 0.01; // Real devices jitter
});

A phone lying on a table still registers micro-vibrations in accelerometer data. A desktop emulator reports either null values or perfectly stable readings. This is one of the most reliable mobile fingerprinting vectors because physical sensor noise is extremely difficult to simulate convincingly.

Battery API

The Battery Status API (navigator.getBattery()) exposes:

• level — battery percentage (0.0-1.0)
• charging — boolean
• chargingTime — seconds until full
• dischargingTime — seconds until empty

Desktop browsers either don't support this API or report synthetic values (always charging, always 100%). Mobile devices report real, varying values. Detection scripts sample battery status over time — a real device shows gradual discharge; an emulator shows static values.

Note: Safari removed Battery API support for privacy reasons. Chrome on Android still exposes it.

Screen Metrics

Mobile devices have precise, hardware-specific screen dimensions:

Device	Screen Resolution	Device Pixel Ratio	Viewport
iPhone 15 Pro	1179 × 2556	3	393 × 852
iPhone 14	1170 × 2532	3	390 × 844
Samsung Galaxy S24	1080 × 2340	2.625	412 × 892
Pixel 8	1080 × 2400	2.625	412 × 915

When a desktop browser claims to be an iPhone 15 Pro but reports a viewport of 390×844 (iPhone 14) with a device pixel ratio of 2 (wrong for any iPhone), the mismatch identifies the emulation.

Detection combines screen.width, screen.height, window.devicePixelRatio, screen.availWidth, and CSS media queries to verify that the claimed device's physical characteristics are internally consistent.

Network Information API

The navigator.connection API on mobile reveals:

• effectiveType — "4g", "3g", "2g"
• downlink — estimated bandwidth in Mbps
• rtt — round-trip time estimate in ms

Desktop browsers either don't support this API or report values inconsistent with mobile network characteristics. A mobile user on WiFi might show effectiveType: "4g" with 50Mbps downlink. An emulator on a datacenter connection might show 1000Mbps — impossible for a real mobile device.

iOS vs Android Detection Differences

iOS (Safari)

Apple's privacy stance limits fingerprinting surface area on iOS:

• No Battery API — removed in Safari
• No Network Information API — not supported
• Limited sensor access — requires user permission since iOS 13
• Consistent WebGL — Apple GPUs are standardized per device model
• Intelligent Tracking Prevention (ITP) — limits cookie and storage persistence

iOS fingerprinting relies more heavily on: screen metrics (precise per device model), canvas/WebGL rendering (consistent per GPU generation), font availability (iOS has a limited, known font set), and AudioContext fingerprinting.

The advantage for operators: fewer vectors means less to spoof. The disadvantage: the vectors that exist are precisely tied to specific hardware, making inconsistencies more detectable.

Android (Chrome)

Android's open ecosystem creates more fingerprinting surface:

• Battery API — available
• Network Information API — available
• Sensor access — available without permission in some browsers
• Diverse GPU hardware — thousands of GPU models across manufacturers
• Diverse screen configurations — thousands of resolution/DPI combinations

Android is both easier to fingerprint (more data points) and easier to spoof (more variety makes inconsistencies harder to detect in a sea of legitimate variation).

Mobile Anti-Detect Solutions

The mobile anti-detect market is immature compared to desktop. Current approaches:

Mobile Emulators with Modification

Android emulators (Android Studio, Genymotion, BlueStacks) with modified system properties. These can change device model, screen resolution, and IMEI/serial numbers.

Detection problem: Emulators are detectable through: missing sensor data (or synthetic sensor data), emulator-specific system properties (ro.hardware=goldfish, ro.product.model=sdk_gphone64_arm64), missing baseband/radio firmware, and performance characteristics that don't match real hardware.

Cloud Phone Services

Services like WeTest, AWS Device Farm, and various Chinese cloud phone providers offer real mobile devices in the cloud accessible via remote control.

Advantages: Real hardware, real sensors, real fingerprints. The device is physically a phone — nothing to detect. Disadvantages: High cost ($10-50/day per device), limited device selection, shared infrastructure, and the remote control adds latency that affects behavioral biometrics.

Modified Android ROMs

Custom Android ROMs with fingerprint spoofing at the system level (Xposed Framework, Magisk modules). These modify system properties, sensor readings, and hardware identifiers.

Advantages: Runs on real hardware, comprehensive spoofing capability. Disadvantages: Requires rooted devices, root detection is widespread (SafetyNet/Play Integrity), and maintaining custom ROMs across Android updates is a significant engineering burden.

Desktop Browsers Emulating Mobile

The weakest approach — setting a mobile user-agent on a desktop browser. This fails on every mobile-specific vector: no real touch events, no sensors, wrong screen metrics, no battery data.

Only viable for targets that check user-agent and nothing else. Increasingly rare.

The Mobile Fingerprinting Arms Race

Platforms are investing heavily in mobile fingerprinting because mobile traffic now exceeds desktop traffic, and mobile anti-detect is less mature — it's the easier place to catch operators.

Trends to watch:

Hardware attestation. Google's Play Integrity API (replacing SafetyNet) and Apple's App Attest provide cryptographic proof that the device is genuine, unmodified hardware running a genuine OS. Apps (not browsers) can verify device integrity server-side. This is currently app-only but browser-based attestation proposals exist.

Sensor-based continuous authentication. Platforms are moving from one-time fingerprinting to continuous behavioral analysis of sensor data. How you hold the phone, how you walk while using it (accelerometer gait analysis), and your typing pressure patterns create ongoing identity verification that's extremely difficult to fake.

Cross-app fingerprinting. On Android, apps can detect what other apps are installed (with limitations). The combination of installed apps creates a fingerprint that persists across browser sessions. iOS has largely blocked this through App Store privacy requirements.

FAQ

Can app-level fingerprinting identify my device when I use a browser? On Android, apps and browsers share some device identifiers (advertising ID, if not reset). On iOS, apps and Safari are siloed — an app can't access browser data and vice versa. The risk is primarily Android-specific and applies when you use both apps and browsers for the same operations.

Does SIM-based identification affect browser operations? Indirectly. Your SIM determines your mobile IP address (via CGNAT), which identifies your carrier and approximate location. Platforms don't access SIM data directly through browsers, but they correlate mobile IP ranges with carrier information. Using mobile proxies mitigates this.

How do mobile proxy networks work? Mobile proxies route your traffic through real mobile devices connected to cellular networks. The exit IP is a real carrier IP with high trust scores. The devices are either dedicated hardware (SIM farms) or volunteer devices (via SDK installations in apps). Quality varies dramatically — carrier-grade NAT means the IP is shared with real users, providing excellent cover.

Can platforms track me across devices? Yes, through: shared account logins (logging into the same Google/Facebook account on phone and desktop), IP correlation (same WiFi network), behavioral similarity (typing patterns, browsing habits), and cross-device tracking pixels (advertising networks). True cross-device separation requires separate accounts, separate networks, and separate behavioral patterns.