Reviewed 2026-09-23 against the repository and current official product documentation. Janitor remains a prelaunch library with experimental scores. This review is an engineering assessment, not an independent security audit or accuracy certification.
Recommended position
First-party identity context for humans and their agents, with Jev-assisted browser continuity and risk. Keep the runtime small and the data in the implementer’s database. Integrate with analytics and authentication products rather than reproducing their infrastructure.
Separate five things in the product and API: browser continuity, verified account identity, credential-backed actor attribution, explicit delegation, and inferred risk. An authorized agent can be automated; a valid human credential can be stolen. Neither browser behavior nor an AI score proves who is physically at the keyboard.
Comparison
| Product | Documented role | Implication for Janitor |
|---|---|---|
| Segment | Unify joins identifiers from multiple sources into customer profiles, with configurable resolution rules and merge protection. identify supplies a stable ID and traits. |
Segment is stronger at customer-data integration and activation. Janitor should supply application-authorized identity/risk events to it, preserving uncertain guesses separately from verified IDs. |
| RudderStack | SDK identity resolution associates anonymous IDs with later known IDs; its open-source dbt model also resolves identifiers in a warehouse. | Use the existing event pipeline. A Janitor adapter can emit a compact event without building destinations, warehouse jobs or queues. |
| PostHog | identify joins an anonymous session’s prior events to a person profile; consistent IDs connect authenticated activity across devices. Reset creates a fresh anonymous identity after logout. |
Account stitching after login is established functionality. Janitor’s opportunity is runtime identity/risk context, while PostHog handles analytics and experimentation. |
| Fingerprint | Visitor identification plus device-risk Smart Signals. Its agent detection verifies signed requests using Web Bot Auth and returns agent identity metadata. | This is the closest comparison for browser/risk intelligence. Agent detection alone is not a unique differentiator. Janitor offers a small inspectable, self-hosted composition; accuracy parity is unproven. |
Sources: Segment identity resolution, Segment Identify spec, RudderStack SDK identity, RudderStack dbt model, PostHog official people documentation, PostHog anonymous/reset documentation, Fingerprint Smart Signals, Fingerprint signed AI agents.
These are documented capabilities, not head-to-head measurements. We have not run competitors on Janitor’s benchmark or compared costs at a production workload.
Changes made in this review
| Finding | Change | Verification |
|---|---|---|
| Zero risk was indistinguishable from evaluator failure | riskStatus: "evaluated" | "unavailable" | "disabled" accompanies risk. Numeric fallback remains zero. |
Evaluated zero, missing evaluator, exceptions and browser response validation. |
| Future learning could accidentally treat fuzzy browser matches as verified people | Dedicated opt-in short session cookie; labels require a server-verified self-person login. | Both SQL backends: cookie restoration cannot label an account; post-login snapshots stay frozen. |
| Predictions could reinforce themselves or leak accounts to anonymous clients | Shadow predictions use only verified examples, omit prior predictions, and stay in server reports. | Cold-start abstention, output limits, timeout/malformed/unknown-ID fallback, no response leakage. |
| Shared devices and conflicting logins can contaminate examples | Exclude known conflicting labels, agents and delegated actors; no automatic subject merge. | Concurrent conflicting accounts, unknown actor, agent and family scenarios. |
| Optional collection needs independent erasure and bounds | Per-request server permission, fixed expiry, 30-day default, 20 examples/subject, bounded reports, cleanup and cascades. | Real D1/Postgres retention, permission withdrawal, deletion and isolation tests. |
| A slow streamed request could hold the handler indefinitely | Overall body-read deadline, default five seconds; sanitized HTTP 408 and stream cancellation. | Never-ending request body terminates without creating an identity. |
Remaining gaps, in priority order
- Accuracy and calibration are not established. The controlled dataset already shows identical-profile false matches after cookie loss. Jev and anonymous cross-device predictions need consented, labeled holdouts before claims about fraud or human identification. Prioritize false associations over maximizing recovery. Keep an explicit abstention path and compare deterministic-only, Jev-assisted and custom-classifier baselines.
- Client measurements and continuity cookies are not security proof. Payloads can be fabricated and cookies replayed. Add optional short-lived server result receipts bound to an application operation, with audience, expiry and a nonce consumed by the application. A signature protects the receipt, not the truth of a browser claim. Keep authorization in existing authentication. Fingerprint’s server integration guidance documents the same general trust boundary.
- Consent and logout ergonomics need a simpler integration. The new learning gate is explicit; browser tracking still starts at client creation. A future consent-aware client wrapper and reset/rotate recipe should make stopping collection, clearing pending learning flows and account switching straightforward. Never let a fuzzy restored browser ID reconnect an opted-out account.
- Inference cost and failure visibility need workload evidence. Add bounded provider response decoding, model/prompt version tags, structured fallback reasons, and metrics for timeout rate, p95 latency, evaluations per identification and cost. Application rate limits and a small circuit breaker can bound abuse without introducing Redis or queues. The configured timeout does not forcibly cancel arbitrary custom evaluator code.
- Identity links need operational provenance before richer merges. Store who/what verified an association and when, support revocation, and make any future merge reversible. The current verified-key uniqueness checks deliberately reject account collisions. Do not add automatic probabilistic account merging.
Features worth building next
| Priority | Feature | Smallest useful scope |
|---|---|---|
| First | Evaluation runner | Replay exported consented feedback with chronological/device holdouts; compare false-match rate, abstention, calibration and latency. Generate a static report, not a dashboard. |
| First | Signed agent credential recipes | Verify an existing provider’s credential or signed HTTP request, map it to a Janitor actor, then assess scoped delegation. A recognized agent vendor is distinct from a user’s grant to access one account. |
| Next | Segment/PostHog bridge | A callback/example emitting verified account/actor, visitor continuity and risk status. Export no full fingerprints and never identify a user using a shadow prediction. |
| Next | Action-specific context | Optional application-verified action categories such as sign-in or payment; separate unusual activity from malicious intent and leave step-up policy to the app. |
| Next | Explicit device pairing | QR/link or passkey-authenticated association for two devices where the application verifies possession, giving stronger cross-device evidence than behavioral resemblance. |
| Later | Revocable learning export | Versioned datasets and deletion lineage for separately trained classifiers; deleting database rows alone does not untrain a model trained elsewhere. |
Keep Jev prominent as the replaceable evaluator with bounded typed outputs. Do not market it as a self-training identity oracle. Learn from verified outcomes, publish uncertainty, and preserve the small-library design.