Screen Orientation and Device Motion: How Mobile APIs Work on the Desktop Through Emulation

[BadB]

How anti-detect browsers imitate sensors – and where they go wrong

Introduction: The Illusion of Mobility​

You set up a profile in Dolphin Anty to emulate an iPhone. You enable Device Motion, Screen Orientation, and Accelerometer. The website displays "Sensors active". You're confident, "Now I look like a real iPhone user".

But the first time you interact with it, you're instantly blocked.

Why?
Because emulating sensors on a desktop is a shadow play. Anti-detection browsers generate static or template data that doesn't correspond to the physics of real motion. And fraud engines (Forter, Sift, Cloudflare) have long since learned to read device body language.

In this article, we'll examine how the Screen Orientation and Device Motion APIs work, how browsers emulate them, and where exactly they produce fake data.

Part 1: What is the Screen Orientation and Device Motion API?​

Screen Orientation API​

Allows the site to determine:

• Screen rotation angle: 0° (portrait), 90° (landscape),
• Orientation type: portrait-primary, landscape-secondary.

Code example:
js:

screen.orientation.angle // → 90

Device Motion API​

Provides data from three sensors:

• Accelerometer: acceleration along the X, Y, Z axes (in m/s²),
• Gyroscope: angular velocity (in rad/s),
• Orientation: absolute rotation angle (in degrees).

Code example:
js:

window.addEventListener('devicemotion', event => {
  console.log(event.acceleration.x); // → -2.34
});

Key fact:
These APIs are only available on mobile devices with physical sensors.
On desktop, they always return null or emulated data.

Part 2: How Anti-Detect Browsers Emulate Sensors​

Emulation methods​

Anti-detect browsers (Dolphin Anty, Linken Sphere) use three approaches:

1. Static values

• Set fixed parameters:
  • acceleration.x = 0,
  • orientation.angle = 0°.
• Problem: Real devices are never static - even when at rest there are microvibrations.

2. Pattern Movements

• Generate "natural" sine wave oscillations:
  • acceleration.x = sin(t) * 0.5.
• Problem: Real motion is chaotic, not periodic.

3. Random noise

• Add random values in the range:
  • acceleration.x = random(-1.0, 1.0).
• Problem: Violates physical laws (eg. acceleration without cause).

Truth:
None of these methods simulate real-world physics.

Part 3: How Fraud Engines Detect Counterfeiting​

Analysis through physical laws​

Modern systems check the data for compliance with Newton's laws:

1. The law of inertia

• If the device is lying on the table, the acceleration along Z ≈ 9.8 m/s² (gravity),
• Emulators often set Z = 0 → physics violation.

2. Correlation between sensors

• When rotating the device:
  • The gyroscope shows the angular velocity,
  • Accelerometer changes the gravity vector.
• Emulators do not link this data → inconsistency.

3. Noise profile

• Real sensors have a unique noise profile (thermal noise),
• Emulators use pure noise → too perfect.

Field data (2026):
Profiles with emulated sensors have a fraud score of 90+, even with a perfect Canvas.

Part 4: Where exactly do emulators go wrong?​

Mistake 1: Lack of gravity​

• Real device: acceleration.z = 9.8 (at rest),
• Emulator: acceleration.z = 0 → instant flag.

Mistake 2: Zero angular velocity​

• Real device: Even at rest, the gyroscope shows micro-oscillations (±0.01 rad/s),
• Emulator: rotationRate.gamma = 0 → suspicious.

Mistake 3: Inconsistency with Orientation​

• If screen.orientation.angle = 90°, then the acceleration vector must be rotated by 90°,
• Emulators do not recalculate the vector → anomaly.

Example:
The user "holds" the iPhone in landscape, but the acceleration is still downwards → physically impossible.

Part 5: How to Test Your Vulnerabilities​

Step 1: Use test sites​

• https://amiunique.org — shows the entropy of sensors,
• https://browserleaks.com/sensors — detailed analysis.

Step 2: Run a local test​

js:

// Gravity test
window.addEventListener('devicemotion', e => {
if (e.accelerationIncludingGravity) {
const z = e.accelerationIncludingGravity.z;
console.log(`Gravity in Z: ${z}`);
// Actual value: ~9.8 or ~-9.8
}
});

Rule:
If |z| < 8.0 → you 've already been given away.

Part 6: How to Set Up Emulation Properly​

B Dolphin Anty / Linken Sphere​

Parameter	Recommended value	Why
Screen Orientation	portrait-primary	Most common orientation
Accelerometer	Enable + Gravity = 9.8	Simulation of gravity
Gyroscope	Enable + Noise = 0.01	Microoscillations at rest
Motion Profile	"Natural Handheld"	Chaotic movements

But: Even with these settings, the emulation remains fake.

Part 7: The Best Strategy is to Avoid Emulation​

When to use sensors:​

• Only if you are simulating a mobile device,
• Only on sites where a mobile version is required (for example, TikTok).

When to disable:​

• On desktop sites (Steam, Razer) - sensors are not needed,
• If you use Windows RDP, the emulation will still be exposed.

Rule:
The fewer APIs you emulate, the more trusted the system is.

Conclusion: You can't fool physics​

Screen Orientation and Device Motion aren't just "another API". They're a window into the physical world, where every movement obeys Newton's laws.

Anti-detect browsers try to cheat these laws—and always fail.

Final thought:
True camouflage isn't about imitation, but about eliminating unnecessary features.
Because in the world of fraud engines, even gravity can give you away.

Stay minimal. Stay physical.
And remember: in the world of fingerprinting, the laws of physics are the final judge.