Browser history can help reconnect visits, but it cannot prove who is using an account. This page summarizes research and product approaches that inform Janitor’s design: keep a small history, expect signals to change or be spoofed, and use verified credentials for people and permissions.
This is background reading. For a working integration, start with your first visitor ID. For Janitor’s own measured results, use testing and limitations. Research results from another population or product are not accuracy claims for Janitor.
What the studies establish
| Primary source | Finding | Implication for Janitor |
|---|---|---|
| FP-STALKER, IEEE S&P 2018 | Evaluated changing fingerprints using 98,598 observations from 1,905 browser instances. History can link some browser changes over time. | Maintain multiple observations and allow drift. This historical study does not establish accuracy for today’s browsers or this library. |
| Long-Term Observation on Browser Fingerprinting, PoPETs 2020 | Three-year study of over 1,300 people, with user-level ground truth and multiple browsers/devices. Highlights dataset representativeness and ground-truth limitations. | Evaluate people, browsers and devices separately. Do not label Janitor’s own fuzzy matches as verified people. |
| Gummy Browsers, 2021 | Demonstrates targeted spoofing against fingerprint-based tracking systems. | A plausible matching browser profile is not possession of a credential. More browser attributes alone cannot solve impersonation. |
| FP-Inconsistent, revised September 2025 | The authors tested half a million requests from 20 evasive bot services. They found substantial evasion and showed that inconsistencies between attributes and across time improved detection in their experiment. | Study consistency and temporal evidence, not just webdriver or a user-agent string. These results are not current vendor ratings or Janitor performance claims. |
These papers describe different populations, collection periods, feature sets and threat models. Their headline rates cannot be combined into a Janitor accuracy estimate. Old desktop-heavy datasets are especially weak evidence for modern mobile, privacy-focused and agent-operated browsers.
What major systems document
| System | Documented approach | What to adopt without copying the platform |
|---|---|---|
| Cloudflare Bot Management | Multiple detection engines use request, session and browser evidence and a large network’s traffic. | Accept optional trusted edge evidence. A small self-hosted library does not have Cloudflare’s training corpus or network reputation. |
| Cloudflare JA4 | TLS client characteristics and aggregate signals can group traffic beyond IP addresses; fields may be unavailable and require eligible plans. | Treat JA4 as a client/network cohort signal, never a person ID or unforgeable credential. Gracefully handle absent data. |
| Fingerprint Smart Signals | Separate device intelligence includes automation/tampering, network-related assessments and velocity across visitors/linked IDs. | Maintain distinct evidence categories and short-window action/account counts. Avoid copying unavailable provider outputs into made-up local probabilities. |
| Fingerprint AI agent detection | Web Bot Auth verifies signed requests and returns agent identity metadata. | Cryptographic actor evidence is different from behavioral automation. User delegation still needs an independent grant. Janitor’s JWT helper is not a Web Bot Auth implementation. |
| Sift Account Defense | Login, verification and account events include session/user context, plus outcome feedback. | Evaluate the whole login/recovery/action sequence; learn from independently verified outcomes. |
| Auth0 Adaptive MFA | Combines new-device, travel and IP-risk evidence around an authenticated account’s login. | New device is a reason to assess context, not an accusation. Janitor currently has no IP/geolocation component. |
| Segment Identity Resolution | Persistent profiles link multiple known identifiers with configurable identity rules and merge protection. | Use verified application keys for cross-device joins and protect against shared-device/account collisions. Funnel analytics is not authentication. |
Vendor documentation establishes advertised mechanisms, not comparative detection accuracy. We have not purchased these services, tested their paid tiers, or run a head-to-head benchmark.
IP and user-agent changes
User agents and JavaScript payloads are client claims. An attacker can forge them. Changing a public egress IP through a proxy/VPN is different from forging a source address on an established connection; residential proxy traffic can resemble ordinary user traffic. Browser, HTTP and transport inconsistencies may provide evidence, but consistent-looking automation still exists. Network addresses also change for legitimate people, and many people share one address.
For Janitor, keep IP out of the continuity key. If network intelligence is added, make it opt-in, server-sourced, short-lived, and separate from identity. Prefer a vetted provider’s derived classifications over adding raw IP retention. Hashed IPs are still linkable data and do not solve NAT, proxy rotation or identity. Do not reconstruct browser-hidden values or penalize privacy protections by themselves.
Model the journey with separate entities
| Stage | What can be established | Current implementation / next work |
|---|---|---|
| Anonymous arrival | First-party browser continuity, technical risk, uncertainty | Implemented: cookie plus bounded history, deterministic matching and optional Jev. No account access. |
| Pre-login exploration | A session’s aggregate behavior; application-specific funnel events | Implemented: counts/optional summaries and optional short learning sessions. v0.7.0: allowlisted server events, without raw URLs/form data. |
| Signup/login | A verified application account, if authentication succeeds | Implemented: server-only updateSubject / identify_user, verified identity keys and analytics bridges. v0.7.0: verification provenance, expiry and device-association revocation. |
| Another device | Same verified account after login or approved pairing | Implemented: distinct visitor IDs can share a verified subject. Anonymous cross-device guesses remain optional shadow experiments, never authentication or automatic merges. |
| Recovery/payment/profile change | Whether this actor may perform this particular operation | Implemented: scoped/revocable delegation and encrypted action-bound evidence receipts. v0.7.0: account/session/action counts and verification outcome events. The app still verifies MFA/payment policy. |
| Authorized agent | Authenticated actor plus a user’s scoped grant | Implemented: pinned-issuer JWT verification and delegation checks. Proposed: audited Web Bot Auth/provider integrations, with request signatures and replay checks. |
| Shared account/family | A separately authenticated actor if the application has one | Implemented: actor/principal separation. Without actor authentication, report unknown; no fingerprint can prove which family member is typing. |
| Confirmed abuse | Independent review or authentication/business outcomes | Implemented: learning export/revocation and held-out evaluation tools. Proposed: typed outcome feedback, quarantined labels and monitored recalibration. |
Think of an account/device/session relationship model, not a requirement for a graph database. Postgres tables, foreign keys and scoped indexes are enough for these direct relationships. Probabilistic links must remain distinct from verified associations, carry provenance, expire, and be revocable. A trusted login can label the current session; it must not retroactively claim every past user of a shared browser.
Database and runtime decision
Keep Postgres as the recommended large-deployment backend. It already supports native Phoenix and Node/Vercel, transactional uniqueness, indexed history and application-owned connections. D1 remains a lightweight option with documented size/concurrency limits. See measured scale and migrations.
Do not introduce a graph database, vector search, Redis or queues to fix coarse candidate lookup. First use selective B-tree probes and a fixed retrieval budget, then rank before invoking Jev. A later warehouse can receive explicit exports through the implementer’s analytics infrastructure; it need not sit in the request path.
What Janitor implements and what still needs testing
- Trusted evidence envelope (v0.7.0): implemented separate
client,edge,authentication, andapplicationsources with timestamps and availability. Never accept a browser’s claim to be trusted edge/auth evidence. The optional Cloudflare helper reads the inbound Worker metadata; standalone Web Bot Auth verification is still future work. - Funnel events and velocity (v0.7.0): implemented narrow server categories, indexed bounded time-window counts, retention and idempotency. Saturated results are explicit lower bounds. Shared measurement quotas and inference budgets use the existing database.
- Verified relationship provenance (v0.7.0): implemented verifier, hashed proof reference, expiry and irreversible revocation. Separate accounts can share a browser without merging. The application still performs authentication and authorizes every association.
- Evaluation before automatic inference: chronological and device holdouts, adversarially copied signals, common profiles, NAT/VPN changes, privacy browsers, accessibility/touch-only behavior, human-operated attacks and delegated agents. Measure false merges, false positives, abstention and provider cost separately.
- Jev ablation: compare deterministic-only, deterministic + Jev and a custom classifier on the same independently labeled data. Version prompts/models and keep risk and identity objectives separate. A model-generated
0.96is not automatically a calibrated probability.
Items 1–3 are implemented and tested in v0.7.0; see configuration and boundaries. GitHub release artifacts include them; application integration remains separate. Items 4–5 still require independently labeled evaluation data. No release claims account-takeover detection or automatic cross-device model training. Browser lookup uses selective indexes and batched history reads; cleanup is paged; scores stay private; result receipts are encrypted. The security review covers feedback-oracle and replay limitations.