Device Intelligence Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for fraud/risk signals. This package covers the "cheap tier" of device intelligence: a collect endpoint, probabilistic device matching (fuzzy re-identification across sessions even when identifiers rotate), and a risk score. That is enough to answer "is this the same device we saw last week?" without paying per-call fees to FingerprintJS/Castle/Sardine-class vendors. The decision it unlocks: self-host the baseline signal layer now, reserve vendor spend for the high-stakes flows.
• Risk-based authentication and step-up gating. A per-request risk score lets you branch policy instead of applying blunt rules: silent allow → email/SMS OTP → manual review → block. PMs can scope a roadmap item like "step-up auth on suspicious device" without first buying an identity platform.
• Abuse-funnel prioritisation. Concrete use cases to size against: multi-accounting and referral/promo farming, trial and free-tier abuse, account-takeover attempts, credential-stuffing triage, card-testing patterns, chargeback precursors. If your signup or checkout funnel has a named abuse metric, this package is a candidate instrument for it.
• Trust & Safety tooling. Device history and risk scores give support agents context ("this account has shared a device with 4 flagged accounts") and give you a durable signal store you own, rather than one locked inside a vendor dashboard.
• Privacy/compliance architecture decisions. The package's own framing — "Device IDs are not credentials" — is the key product constraint. It positions device identity as a signal, never an authentication factor. That supports a defensible posture: fingerprinting is treated as personal data (GDPR/ePrivacy), requires a DPIA, disclosure, and a consent/lawful-basis decision, and cannot be the sole reason a user is denied access or locked out. Deciding this early is a product decision, not an engineering one.
• Roadmap sequencing on identity. Because it's MIT and self-hosted, it's a low-commitment way to validate demand for device-level signals before committing budget to a vendor contract, a data-processing agreement, and an annual minimum.
• Platform scope decision (Symfony vs. Laravel). The bundle is Symfony-native (DI extension, compiler passes, Twig/asset integration, PHP ≥8.1, Symfony 6/7/8). For a Laravel estate, adoption means wrapping it or rebuilding the collect endpoint and scoring service — a real cost line that belongs in the build-vs-buy comparison, not an afterthought.

When to Consider This Package

Consider it when:

• You run a Symfony 6/7/8 application on PHP ≥8.1 and want risk signals inside the monolith rather than as a network hop to a third party.
• You need first-party data residency — device signals, IP, and risk history stay in your database, no sub-processor, no new DPA, no cross-border transfer review.
• Volumes are low-to-moderate and per-call vendor pricing is disproportionate to the fraud loss you're actually seeing, or you're pre-revenue and can't justify a platform contract.
• You want a pluggable baseline: an adapter interface in front of device scoring so a vendor can be swapped in later for high-value flows only.
• Your team has PHP/Symfony capacity to own a small bundle, and you're comfortable reading the source because that's the only documentation.
• You can pilot behind a feature flag with a defined success metric (e.g., measurable reduction in duplicate-account signups, or fewer OTP challenges per legitimate user) and a kill criterion.

Look elsewhere when:

• Any of the maturity signals matter to your risk function. This is a 0-star, 0-dependent repository with a single maintainer and a future-dated last release (2026-10-25) — treat that as a data-quality flag and verify the actual cadence before planning around it. There is no community, no third-party production evidence, no security disclosure process, and no support SLA. For a fraud control that gates revenue, that is a material operational risk.
• You need accuracy guarantees. Probabilistic matching without a large labelled dataset has unquantified false-positive and false-negative rates. If a wrong block costs a paying customer or a missed block triggers a chargeback threshold, you need a vendor with published accuracy, tuning support, and accountability.
• You need breadth beyond web. No evidence of mobile SDKs, native app signals, or email/phone/identity-graph correlation. Modern fraud stacks need multiple dimensions; device signals alone invite evasion by determined actors.
• You're Laravel-first. Non-trivial integration work; the Symfony coupling (services, config keys, Twig/assets) buys you nothing.
• Privacy review is likely to say no. If your user base, regulators, or app-store policies treat fingerprinting as unacceptable, no amount of engineering mitigates that; pick a consent-based or privacy-preserving alternative.
• You need 24/7 support or an indemnity. Look at commercial vendors.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can add a first-party device risk signal to our platform for effectively zero licence cost, using an MIT-licensed Symfony bundle that stays entirely inside our infrastructure — no new vendor, no data-sharing agreement, no per-request fees, and our users' device data never leaves our systems. It gives us a risk score per session that we can use to decide when to ask for extra verification, and it starts building a device history we own. The honest caveat: this is an early-stage, unproven package with no adoption and no support. So I'm not proposing we make it a control — I'm proposing a four-to-six week, flag-gated pilot on one funnel with clear success and exit criteria, plus a parallel shortlist of commercial vendors in case the pilot doesn't clear the bar. Worst case we spend engineering time and learn exactly what we'd be paying a vendor for.

For engineering: Small, conventional Symfony bundle — DI extension, compiler-pass wiring, a collect endpoint, and a scoring service, targeting PHP ≥8.1 / Symfony 6-8 with strict types, final classes, and constructor injection. The repo's own conventions commit to backward compatibility and minimal patches, which is good hygiene but also means we should not expect rapid upstream fixes. Plan to wrap it: our own interface for "get device risk for this request," an adapter that delegates to this bundle, and a second adapter we can point at a vendor later. Persist the raw signal plus score and model/config version so we can backtest and explain decisions. Treat the collect endpoint as untrusted input — rate-limit, validate, and log. Feature-flag everything, shadow-mode the score before it influences any user-visible decision, and add one focused test at the decision boundary (score → policy outcome).

Risks to table openly: zero adoption and a single maintainer (bus factor); no published accuracy or benchmarking; unquantified false positives that could block legitimate users; privacy exposure requiring DPIA, disclosure, and a documented lawful basis before any collection begins; and the future-dated release, which means we verify release history and open issues ourselves rather than trusting the metadata. Success criteria for the pilot should be stated up front — a specific abuse-metric reduction, an acceptable false-positive rate on known-good accounts, and a clean legal sign-off — with a pre-agreed decision to either harden it, replace it with a vendor for high-value flows only, or stop.