Why this topic matters to me now
Private mode, tracking protection, reduced UA — everyday life. People use private mode. If my detector confuses privacy with a bot — that is my design mistake, and I write about it openly.
If antifraud thinking puts nuclear weight on privacy, it is fighting users.
Public frame (links)
Chrome privacy / security docs and UA-CH explain shrinking identifiers as product normality. This is literature for protecting people, not a bot manual.
What I observe in the lab, in plain words
User scenarios
A person opens incognito because they share a laptop. A person cuts tracking because they are tired. A person turns on a VPN in a café. That is not a prologue to automation.
The junction with reduced UA / CH
Fewer details in claims → more uncertainty. Uncertainty ≠ guilt. If I call a reduced UA “suspicious by default”, I am punishing the browser’s product policy.
A lesson for antifraud authors
Do not blow up everyday life. Look for hard integrity contradictions, do not punish privacy defaults. Accumulating soft noise until a verdict is bad ethics and bad engineering.
What this changes in detect and/or in the build (without specifics)
In detect I explicitly mark privacy noise as soft. In the build I do not treat “incognito mode” as an achievement of profile consistency.
What I will not say and why
No instructions on how to mask automation as privacy.
Short first-person takeaway
Privacy is a right and everyday life. In my lab it does not serve as a bot label. Whoever confuses these things calibrates the detector against people.
