Spoofing a mobile device from a desktop
Somebody sent me a profile export to look at because their mobile accounts kept dying and they could not work out why.
The user agent named a current Android handset. The screen dimensions had been copied off that exact model, portrait, down to the pixel. Genuine effort, and more effort than most people put in.
The device pixel ratio was 1. That handset ships at 3. It took me longer to open the file than to find it.
That is the shape of this whole problem. The mobile claim is the one spoof where the easy part and the hard part are separated by a cliff, and every tool in the category ships the easy part in a dropdown.
Two fields are declared and everything else is produced
A settings panel gives you a user agent string and a screen size. Both are assertions. The browser says what it is told to say and nothing downstream verifies either one.
That is why the mobile toggle exists in almost every one of these products. It is cheap to build, it demos beautifully, and the profile really does receive the mobile version of any page you point it at.
Everything else that makes a phone a phone comes out of the machine underneath. The panel does not reach it, because the panel sits above it.
I run mobile lines on carrier SIMs out of Singapore and a rack of Android handsets that people rent by the hour, so I read real device values fairly often. The gap between a real handset’s readings and a desktop wearing a handset’s name is not subtle, and it is not one value.
Touch is the four second check
The browser reports how many simultaneous touch points the hardware supports. A desktop with no touchscreen says 0. A handset says 5 or 10.
Alongside that, a stylesheet can ask whether the primary pointer is coarse or fine and whether the device can hover at all. A mouse is fine and hovers. A finger is coarse and does neither.
A desktop answers both honestly unless the entire stack below the browser is in on the act. So the common result is a phone with a mouse, findable in three lines of script, and I have written those three lines more times than I would like.
There is a real exception. A Windows laptop with a touchscreen reports touch points and a coarse pointer quite genuinely, so touch alone was never proof of a handset. It rescues nothing, because that same laptop still reports a laptop screen, a laptop pixel ratio and a laptop graphics chip. It will admit it can be poked. It will not agree that it fits in a pocket.
The ratio is arithmetic and the numbers are public
Device pixel ratio is how many physical pixels sit behind each layout pixel. Desktops report 1, or 2 on a high resolution panel. Handsets report values like 2.625 or 3, and the value belongs to the specific model in the way its camera does.
So the check is a lookup. Read the model out of the user agent, find the ratio that model ships with, compare. A profile claiming a flagship and reporting 1 is describing hardware nobody ever built.
This is the one I find broken most often, and it is free to get right. Whoever exported that profile did the difficult part by hand and skipped the field that takes two seconds.
The chip does not change its mind
A page can ask which graphics hardware is drawing it and receive a string naming the actual silicon. A desktop card does not become a mobile one because a panel says it has.
Some tools will overwrite that string. Now there is a claimed mobile chip attached to a machine whose rendering behaviour belongs to a desktop card, which is a worse position than the honest one, since the disagreement is itself the finding. I have written about the graphics layer on its own and the mechanism there applies here without modification.
Silence where a sensor should be
A phone carries an accelerometer, a gyroscope, usually a magnetometer, and an ambient light sensor. A desktop carries none of them.
That leaves three outcomes and each one is readable. The interfaces are missing. Or they exist and never fire. Or a tool is synthesising values and the values look synthesised.
A handset lying flat on a desk still emits a slow drift of small numbers, because buildings vibrate and the chip notices. Perfect motionless zeroes forever describe a phone nobody is holding. Clean sine waves describe a phone nobody manufactured. The sensor layer has its own piece here and this is one line item from it.
Heat is a signal
A flagship handset from last year is fast, and it is still slower than a desktop with a proper processor and a fan bolted to it. Time a heavy loop in JavaScript and the two separate.
The second difference matters more. A phone thermally throttles. Push it for ninety seconds and it slows down, because it is a slab of glass with nowhere to send the heat. A desktop with a heatsink holds its clock all afternoon.
So a page can run the same work twice a minute apart and ask whether the device got tired. A desktop pretending to be a phone stays fast and stays flat, permanently. I know this one from the hardware side rather than the browser side. Throttling on my rack is an airflow problem I pay for, not a theory I read.
The pixels nobody asked for
Everything above is checkable in a few lines and, in principle, fixable by a determined vendor with enough engineering behind it.
Underneath there is a layer that does not behave that way.
A real phone renders differently. Different font stack, different rasteriser, different graphics hardware, different rounding. Draw identical text into a canvas on a handset and on a desktop and the resulting pixels disagree, in ways that are stable and characteristic of the class of machine. Measure the width of a string in a given font and each one hands back a different number.
Nobody declared those values. They fell out of doing the work, which is exactly why they are hard to talk over. Canvas fingerprinting has its own explainer and the mechanism is the same one. What changes here is the size of the gap. You are trying to look like a different class of hardware, not a slightly different desktop, so the distance the fake has to cover is much larger.
Things a real phone does that a spoof never does
A handset rotates. Width and height swap, the layout reflows, an orientation event fires, and it all arrives together because it was one physical movement.
A handset opens a keyboard. Tap a text field and the viewport height collapses by a few hundred pixels, then returns.
A handset receives touch events with the imprecision of a finger sitting in the coordinates.
A desktop claiming to be a phone does none of this, ever. Not once across six weeks. It is a device that has never been rotated and never been touched, and it has been awake the entire time.
The part I get argued with about
I think the mobile profile toggle should not be in these products at all. It ships because it is easy to build and it photographs well on a feature page, and it hands people a false position while feeling like a real one.
The argument against me is that a partial disguise is better than none, and for the layout use case that is fair. For anything with money on the other side I still think it is backwards, because a desktop wearing mobile strings is more identifiable than an honest desktop. You started as one of several hundred million ordinary Windows machines. Now you are a Windows machine insisting it is a handset, and that is a very small room to be standing in.
What I got wrong on my own setup
I ran a batch of these for about two months and read a checker’s green score as evidence they were fine. Checkers mostly read declared values, which was the one layer I had correct.
When the accounts started going I could not say which signal did it. I still cannot, and I want to be honest that nobody selling you a tool can either.
I was also running mobile claiming profiles over a home fibre line, so the address and the story disagreed before any of the browser detail mattered. I sell mobile lines for a living and I still got that backwards on my own machines.
If it has to look like a phone, use a phone
An Android emulator on a desktop is a real mobile stack. It answers most of these questions the way a handset does because it is executing rather than asserting. A physical device answers all of them without being asked.
Both cost more than a checkbox. An emulator eats memory, and a real handset costs money and needs somewhere with power and airflow to sit. I rent Android phones by the hour precisely because plenty of people would rather pay a few dollars a day than run a rack in a spare room.
And if the work does not genuinely need a phone, do not claim one. Wanting to see a mobile layout, a mobile ad, or what a site serves to a small screen is completely fine on a desktop with mobile strings, because nothing on the other side is scoring you. The trouble starts when something has money at stake and a reason to look properly. At that point the two fields you set are the two fields it was never interested in.
Full reviews and the tools I actually keep installed are at Anti-Detect Review.
Get new guides and videos first — join the Telegram channel.