A phone profile on a computer: what makes it a whole phone

A page reads your machine with ordinary questions, and asks permission for none, and it is the platform that adds the answers up, not you. The answers arrive separately and add up to one device.

Let any pair disagree, and the platform stops watching the account and starts watching the machine. A phone is the agreement of every answer, not one of them.

On a desktop people assemble different machines, and one maker's screen beside another's graphics card surprises nobody. A handset is not like that: the model settles everything.

So your profile gets a whole handset, not a bag of values, and hand edits do not apply to separate parts of a handset. The pool holds 22 handsets and 7 tablets, each a model that really shipped.

• Screen and density

  From 360 by 780 to 412 by 919 layout points, density 2.625 to 3.75. Eight distinct screens.

• Graphics card

  Vendor and renderer arrive as a pair, and the pool holds twelve pairs.

• Cores and memory

  Eight cores everywhere, memory 4 or 8: a browser never names more than eight.

• Maker fonts

  Google Sans on a Pixel, SamsungOne on a Samsung, MiSans on a Xiaomi. Alongside them the backing for drawing holds fonts of your own machine: without it no letters are drawn at all, and that list is not handed to the page.

A page that has been allowed to record reads the number of capture devices: how many microphones, how many speakers, how many cameras. A handset has two or three cameras and more often one microphone and one speaker, and the profile answers the same way.

A desktop machine answers differently: one camera, while microphones and audio outputs come in twos and threes because of headsets and monitors. A phone with one camera and three microphones is one more pair that does not exist.

A page gets device names and their number with the same permission, and before it only the kinds. So the number is matched to the handset in advance rather than at the moment a platform asks.

Besides the memory size a page reads the script heap limit, and on a phone it is figured differently: a quarter of the memory against a half on a desktop. Eight gigabytes of memory give a phone two gigabytes of heap, and a desktop machine four.

It is figured inside the profile rather than the engine, by one rule for every handset in the pool. A phone with a desktop heap limit would give itself away the same way as a phone with a desktop window.

Chrome on Android stopped putting the model and system version in its signature, and hands the model out only on a site's request rather than in the first header: every handset says Android 10; K. The real model lives only in the client hints.

So a signature reading Android 14; Pixel 7 gives the forgery away in the first header. Your profile puts the model where a live Chrome does, nowhere else.

A platform asks three questions in a row: is there ontouchstart, does (pointer: coarse) match, does (hover: none) match. A handset says yes to all three, a desktop no to any.

No live machine gives a mixed answer, and the check costs one line, and the profile answers all three the phone way. A handset reports five touch points, the number Chrome on Android gives.

A desktop Chromium build cannot go under five hundred points: ask for 360 and you get 500, which never happens to a handset in the hand. The profile declares 360, so the window is wider than its screen.

On a page that declares a handset viewport no such machine exists, and a platform sees it in one comparison. Without that declaration a live Android lays out at 980 points on a 360 screen, and the window is honestly wider than the screen. A phone window is brought to handset size after launch, new tabs included.

Chrome on a tablet leaves Mobile out of its signature and calls itself not mobile, so sites hand it the desktop layout. A tablet carrying Mobile contradicts its own header.

A tablet screen lies long side across, and its density is one and a half or two, below any handset. The pool holds 7 tablets, never a handset density.

Chrome on Android carries three fields a desktop lacks: type, downlinkMax and ontypechange. A platform asks for them in one line about navigator.connection.

Opening the fields is not enough: unreplaced, they hand over your own computer's numbers, and an endless speed ceiling stands out more than missing fields. So the ceiling matches the speed and comes from the browser's own table: 11, 54 and 600 for Wi-Fi, 42 and 100 for fast cellular. Forty-two is HSPA+, a hundred is LTE, and they are drawn where the browser declares a fourth generation link.

The promise «a whole handset» is checked by execution rather than reading: forty phone profiles are derived from their seeds, and for all forty the screen, density, graphics card, cores, memory and fonts are matched against a single row of the handset pool.

A profile with even one part from a neighbouring model turns the check red. Tablets go through the same round, and a phone density in a tablet row fails it just as badly.

Open the developer console inside the profile and read four answers in a row, and there is no need to look further after the first mismatch. A live machine answers consistently, a forgery breaks on the first.

If any reading argues with the one beside it, the profile reads as a desktop calling itself a phone. Where your machine sits makes no difference.

1. 1

   Screen and window

   screen.width and window.innerWidth: on a page that declares a handset viewport the window is not wider than the screen.

2. 2

   Touch and pointer

   navigator.maxTouchPoints, ontouchstart, (pointer: coarse) and (hover: none): all four phone-shaped, or none.

3. 3

   Signature and hints

   Android 10; K in the signature, Android, arm and the model in the hints.