maxTouchPoints coheres with pointer media
Check id touch-pointer-coherence
What an ordinary browser yields
maxTouchPoints > 0 is accompanied by a matching (any-pointer: coarse); maxTouchPoints = 0 imposes no requirement.
What a detector infers
A one-directional coherence test: if navigator.maxTouchPoints is greater than zero, matchMedia("(any-pointer: coarse)") is expected to match. It passes automatically when maxTouchPoints is 0, since a mouse-only machine legitimately has no coarse pointer. The two signals describe the same fact from different layers — maxTouchPoints is a navigator property, any-pointer: coarse is answered by the layout engine from the platform's input devices. Claiming touch support while the engine reports no coarse pointer tells a detector that the touch count was written onto the navigator object without a touch digitizer behind it, a signature of a persona applied only at the JS surface. This most often shows up when a mobile or touch-laptop identity is layered onto a desktop host. Severity is warn.
How to resolve it
Set touch support at the browser level rather than by overriding navigator.maxTouchPoints — enable touch emulation at launch so the engine registers a coarse pointer and both signals derive from one source. If touch emulation isn't available in the environment, leave maxTouchPoints at 0 rather than claiming touch the input layer cannot corroborate.
Read in the wild by
Kasada
Collects navigator.maxTouchPoints from both the main window and a nested iframe, and separately probes the pointer and any-pointer media features and touch-event support.
probes.txt: window_max_touch_points (line 385), iframe_max_touch_points (line 157), pointer (line 259), any_pointer (line 10), touch_event_check (line 298) — all in the same decoded probe dump; blog.txt line 667 shows touch_event_check written at batch 1 slot 323 as fn_134582.
PerimeterX / HUMAN
Collects touch and pointer capability as separate fields in its EV2 payload: navigator.maxTouchPoints (with an msMaxTouchPoints fallback), whether 'ontouchstart' exists on window, and matchMedia pointer readings including (pointer:fine) and (any-pointer: coarse).
main.min.js (collector-a.px-cloud.net) `BF(){return hR(hU[hQ(708)])===ic?hU.maxTouchPoints:hR(hU.msMaxTouchPoints)===ic?hU.msMaxTouchPoints:void 0}` where hQ(708)='maxTouchPoints' → EV2 `t["fy9KZTpKQFc="]=BF()` (number, 0); `t["OkpPAHwqSTo="]=hS.hasOwnProperty(hQ(817))||"ontouchstart"in hS` where hQ(817)='ontouchstart' (boolean, false); `t["X08qRRkvLHc="]=hS.matchMedia&&hS.matchMedia(hQ(815))[hQ(816)]` where hQ(815)='(pointer:fine)' (boolean, true); and `Cy(){if(hS.PointerEvent&&"maxTouchPoints"in hU){if(hU[hQ(708)]>0)return!0}else{if(hS[hQ(889)]&&hS.matchMedia(hQ(890))[hQ(816)])...}}` where hQ(890)='(any-hover: none), (any-pointer: coarse)' → EV2 `t["fg4LRDhtDn4="]=Cy()`
Every attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Screen & display
- screen.colorDepth decomposes into the CSS color media feature
color-depth-vs-media-colorscreen.colorDepth and the CSS color media feature describe one display in two different units: total bits per pixel, and bits per colour… - screen has an OS chrome inset (avail < screen on either axis)
taskbar-presentscreen.availWidth/availHeight describe the area left over after the OS reserves space for its own chrome — a Windows taskbar, a macOS dock… - the outer window fits within the screen
window-boundsThe check asserts only the zoom-invariant bound: window.outerWidth/outerHeight must be non-zero and must fit within the screen. - a non-touch desktop has a fine pointer + hover
pointer-hover-desktopThis check applies only when the UA identifies a desktop platform (Windows, Macintosh, Mac OS X, X11, Linux, CrOS, and not Android/Mobile)… - screen dimensions resolve via native prototype getters
screen-descriptorsFor width, height, availWidth, availHeight, colorDepth and pixelDepth this asks two questions: does the screen instance carry an own… - screen.orientation agrees with the screen's own dimensions
orientation-vs-screen-dimsscreen.orientation.type and screen.width/height are both device-space values sourced from the same display metrics, so they must agree: a… - a mobile UA has a real touch stack
touch-createevent-coherenceThis check asserts in one direction only: if navigator.userAgent matches iPhone, iPad, iPod or Android, then the environment must also have… - visualViewport agrees with innerWidth/innerHeight
visual-viewport-vs-windowwindow.innerWidth and visualViewport.width are two independent readings of one viewport, and they are related by exactly one thing: the…
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Screen & display checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Screen & display — the family touch-pointer-coherence belongs to.