Help · How it works

Spotting one phone checking in several people

LiteEntry gives every phone a server-issued id and records which people check in from it, so a shared device shows up as a pattern. It never blocks anyone.

LiteEntry gives every phone that checks in an identifier issued by the server, and records which people have used it. When the same phone checks in two different people, LiteEntry flags that and shows you who — and it never refuses a check-in because of it.

There is nothing to switch on. Device recognition watches every check-in at every location, which is why it sits apart from the checks you configure per location.

Why it watches rather than blocks

A shared phone is the clearest signal of one person checking in for another there is, and it is also completely normal in some buildings. A warehouse with one work phone on the floor, a colleague with a flat battery, a tablet in a clinic reception — all of them look identical to a rule, and a rule would turn away real people every week to catch something an administrator can simply be shown.

So LiteEntry records the pattern and puts a name to it. Buddy punching is a habit rather than a heist, and habits stop when somebody might notice.

Where the device id comes from

The identifier is a random value generated by the server and kept in a signed, HttpOnly cookie on the phone, for up to two years. It is never accepted from the page: JavaScript cannot read it, and a browser that sends a tampered one is given a fresh id rather than believed.

That matters because the person this signal exists to catch is exactly the person who would rotate an identifier between check-ins if the phone were allowed to choose it. The cookie carries no name, no number and nothing about the handset — it is an id that means “this browser, again”.

What you see when a phone is shared

The Review queue lists it as Shared device, with the sentence that actually helps: Same phone also used by and the other names. There is no device id in the row, because a random identifier is not something anybody can look up or act on — the names are the fact.

In the attendance report the day’s row carries a Shared device note, and the same note travels in the CSV export. Marks stay on a row for good: red until an administrator has seen them, then green. LiteEntry records that somebody noticed — it never records a judgement, and it never decides anybody was cheating.

A device that gains a new person comes back. Reviewing a shared device clears it from the queue, and the moment a third name checks in from it the flag is raised again, because that is new information rather than the thing you already looked at.

The honest limits

Somebody who clears their cookies, uses a private window, or swaps browsers gets a new id, and their next check-in looks like a new phone. That is the cost of not fingerprinting the handset, and it is a cost worth paying: LiteEntry keeps nothing about the device itself.

The flag also cannot tell you why a phone is shared. Two names on one device is a question, not an answer, and the usual answer is a flat battery.

Remote check-ins do not feed device recognition at all, along with every other check — a check-in made without a display is a different kind of evidence, and it is labelled Remote everywhere it appears.

What to do about a flag

Look at whether it repeats. One person turned up on a colleague’s phone once is noise; the same two names on one device every Monday is a pattern, and it is the kind of thing a manager can ask about in a sentence.

The usual outcome of running device recognition is not catching anybody. It is that everybody knows the record exists.

See does a QR code stop buddy punching for what the other controls do about the same problem, or what each check does for the two you configure per location.

Still stuck? Try the demo — most questions here are quicker to answer by pressing the thing than by reading about it.