What an app sees and a page does not

The same account can be read from two places. One is the platform's own application on a handset, the other is a page in a browser.

They do not see the same amount, and effort has nothing to do with it. The application may ask the system it was installed into, and the page may ask the browser.

A page reads what the browser exposes to it: the browser signature, the client hints, the screen, the pixel ratio, the graphics string, the cores, the memory, the pointer.

All of that arrives as answers to questions. Every one of those answers is something a profile can be given before the first line of page script runs.

• Signature and client hints

  The reduced Android form modern Chrome sends, with the handset model carried in the hints.

• Screen and pixel ratio

  The values of one real handset, not a screen picked apart from the device.

• Graphics string

  Vendor and renderer in the form Android reports them.

• Touch and pointer

  The touch points a phone reports, a coarse pointer and no hover.

• Connection numbers

  Latency and throughput in a phone's range instead of a laptop's.

An installed application lives inside the system and can ask it things a page is never handed. A browser cannot reach that from the other side of the glass.

A phone profile has no answer to those questions and does not invent one. An invented answer is a signal of its own.

A phone profile is an ordinary profile whose fingerprint template is a phone. The handset arrives whole, so the screen, the pixel ratio, the graphics, the cores, the memory and the vendor fonts all belong to one model.

The window is then brought down to that screen, touch is switched on and the pointer becomes coarse. A new tab and a frame from another origin are dressed before their first line of script.

Not every profile can take the template. One created on an older generator does not know a phone, and the app declines instead of handing over another machine silently.

A desktop window will not go as narrow as a phone screen on its own, so it is brought down to the handset size over the debugging protocol. A window wider than the screen it claims is a device that exists nowhere.

That arrives about a second after launch, so a phone profile opens the start page first and the destination after it. If the window could not be brought down, the app names the profile and says so.

A handset carries fonts of its own, and this computer does not have them. A site that measures fonts by drawing them can see that.

The app states it under the template picker rather than in a manual. The profile is also shown a few fonts of this machine on purpose, because without them pages would come out blank.

The connection values are read early by the sites that care about them. A phone whose network numbers match a laptop is an environment disagreeing with itself.

So a phone profile gets phone latency and phone throughput, rounded the way the browser itself rounds them. The kind of connection follows from those numbers rather than being picked apart from them.

An account that lives on a handset has a handset's history behind it. Opening it in a browser adds a device to that history, whatever the page is told.

A profile that answered as a Mac last week and as a Samsung today has changed machine under a live login. That reads louder than any single value on the page.

If a check reads a value, a phone profile answers as a phone. If a check needs the handset itself to act, to take a picture, to feel a tilt, to receive a message, there is nothing underneath to act.

So the work gets planned around what a page can do, and the rest stays on a real device. A browser profile does not pretend to be an application.