Privacy Policy

1. Scope

This policy describes how DigitalFingerprint ("we", "us") processes information when you visit our marketing site (including site-wide visitor identification), use the live demo, create a hosted workspace, or integrate DigitalFingerprint on your own properties.

If you deploy DigitalFingerprint on your website or app, you are the data controller for your end users; we act as a processor on your behalf under your instructions and any applicable Data Processing Agreement (DPA). This policy primarily covers our marketing operations, demo traffic, and account-holder data unless a separate DPA governs your production deployment.

2. Information we collect

When the OriginID SDK (@digitalfingerprintjs/client) runs in a browser, it may collect and transmit the following categories of data to our identify API:

• Device & browser signals — user agent, screen resolution, color depth, timezone, language, platform, hardware concurrency, device memory, touch support, and storage availability (cookies, localStorage, IndexedDB).
• Rendering fingerprints — canvas, WebGL (vendor, renderer, extensions), audio, fonts, math, emoji, DOM rect, CSS and media queries, plugins, speech voices, and related hashes used for visitor matching.
• Integrity signals — incognito/private browsing indicators, bot/automation heuristics, tampering scores, developer tools, privacy settings, and anti-detect browser flags (computed client-side; fraud verdicts are server-side).
• Network context — IP address and derived geolocation (city/region/country), ASN, ISP, and datacenter classification when IP intelligence is enabled on the server.
• Page context — page URL hash (always stored); full URL only when explicitly enabled server-side (ORIGINID_STORE_FULL_URL=true); referrer when available.
• Identifiers you provide — optional linkedId and tags metadata, registration email when using account-link APIs, and first-party clientToken for returning-visitor recognition.
• Account data — if you create a hosted workspace, we collect email, organization name, billing details via Stripe, authentication metadata (email/password or federated login via Auth0), and console activity logs separate from visitor identify payloads.

3. How we use information

• Generate and persist a stable visitor identifier (originId).
• Detect returning visitors and compute match confidence and match path.
• Compute fraud-oriented smart signals, suspect scores, and risk levels on our servers. Production browser responses are slim by default and do not include these fields.
• Score duplicate registrations via the account-link API when you pass registration email at signup.
• Measure marketing-site traffic and returning visitors (for example tags source=marketing_site and the page path visited).
• Provide the live demo, dashboard analytics, visitor timeline, exports, webhook delivery, and management API access to registered customers.
• Enforce rate limits, API key authentication, request signing, usage quotas, and abuse prevention.

4. Marketing site visitor identification

When you browse our public marketing pages, we run the OriginID SDK on page load so we can recognize returning visitors and understand which pages receive traffic. Identify calls are proxied through our dashboard host at https://dashboard.digitalfingerprintjs.com/api/demo/identify — API keys and signing secrets are never exposed in the browser bundle.

Each identify request may include non-sensitive page context tags (for example source=marketing_site and the pathname you visited, truncated to 256 characters) so we can attribute visits in our console. The SDK skips automatic identification on the /demo page because the demo UI identifies separately against the same project.

The public live demo uses the same proxy and project. Demo visitor profiles are minimized by default when DEMO_FULL_SIGNALS=false (the production default):

• Raw IP addresses are omitted from demo profiles; only country-level geolocation is shown.
• Detailed risk breakdowns and extended signal history are not returned.
• Visit history is capped to the five most recent events.

Do not submit sensitive personal information on the marketing site or in the demo. Evaluation and marketing traffic is subject to dedicated rate limits (for example per-IP limits on the demo proxy) separate from customer production API keys.

5. Production trust model

On production API keys, the browser receives only a slim payload (originId, eventId, optional clientToken, timestamp). Smart signals, suspect scores, raw signal blobs, and rule evaluation results are retrieved server-side via the Events API or signed webhooks. Do not make fraud decisions from data exposed to end-user browsers.

If you configure webhooks, we deliver enriched event payloads to your endpoint with an X-OriginID-Signature header for verification. Webhook signing secrets are configured per endpoint in the console.

6. Cookies & local storage

DigitalFingerprint uses first-party cookies and/or local storage to persist a visitor token where permitted (not in all private browsing modes), including on our marketing pages for returning-visitor recognition.

• Visitor token — stored under the key originid_vid in both localStorage and a first-party cookie (1-year, SameSite=Lax) when normal browsing storage is available. The SDK auto-seeds this token on init when storage is empty.
• Dashboard sessions — session cookies on the dashboard subdomain for authenticated console access (email/password or federated login).

You can clear site data at any time in your browser.

7. Retention

• Visit records: default purge after 12 months (VISIT_RETENTION_MONTHS).
• Raw signal blobs: default 30 days when persistence is enabled (PERSIST_RAW_SIGNALS defaults to on; RAW_SIGNAL_RETENTION_DAYS controls duration).
• Inactive visitor profiles may be anonymized before full deletion.
• Hosted workspaces use DigitalFingerprint-managed retention and scheduled purge jobs.

8. Service providers

We rely on a limited set of vetted service providers to operate the hosted platform — covering functions such as payment processing, transactional email, authentication, IP geolocation, and cloud hosting. Each provider processes data only as needed to deliver its function and under contractual data-protection obligations.

Enterprise customers may request our current subprocessor list under a Data Processing Agreement.

9. Security

API keys authenticate identify and Events traffic. Production deployments should require request signing (HMAC via ORIGINID_REQUEST_SIGNING=required), enforce HTTPS, and restrict raw signal access. Webhook endpoints verify X-OriginID-Signature on delivery. Allowed hostnames are enforced per API key. Fraud fields are server-authoritative; production browser responses are slim by default. See integration docs and the production integration checklist.

10. Your rights

Depending on your jurisdiction, you may have rights to access, correct, delete, or restrict processing of personal data. US residents may contact us to request access or deletion of data we hold about them as marketing-site visitors or account holders.

The public demo is for evaluation — do not submit sensitive personal information. If you are an end user of a site that integrates DigitalFingerprint, contact that site's operator (the data controller) for requests about visitor data they process through our platform.

Enterprise customers may execute a DPA covering end-user data processed on their behalf.

11. Children

DigitalFingerprint is not directed at children under 13. We do not knowingly collect data from children.

12. Changes

We may update this policy as the product evolves. Material changes will be reflected in the "Last updated" date above.

13. Contact

Privacy questions: reach us on our contact page or your account support channel for hosted workspaces.