Skip to content

Device Fingerprinter (DFP) v2 (Active after 2026 February 25 10:00 UTC)

Overview

Device Fingerprinter (DFP) v2 is a high-precision challenge focused on device identity consistency and uniqueness. Participants must develop a browser SDK capable of generating a "fingerprint" string that remains identical for the same physical device across multiple browsers while remaining unique between different devices.

The challenge evaluates your SDK's ability to resist browser-level variations (like user agents or window sizes) and extract hardware-level or deeper software signals that uniquely identify the hardware.

For general information and technical setup, please refer to the Main README.

Mandatory Requirements

  1. Use the template provided in the templates/commit/src/fingerprinter/ directory.
  2. Implement your logic within the fingerprinter.js file.
  3. Your SDK must:
  4. Generate a single string (the "fingerprint").
  5. Report this string to the evaluator when executed within a browser environment.
  6. Be self-contained and not rely on external API calls or non-standard browser features that require user permissions (e.g., Camera/Microphone).

Browsers

Your SDK will be evaluated across multiple mobile and desktop browsers, including:

  • Chrome
  • Brave
  • Firefox Focus
  • DuckDuckGo
  • Safari

All browsers are run in incognito mode. Each device will be tested in multiple "batches" across these browsers to ensure consistency.

Key Guidelines

  • Fragmentation (Internal Consistency): Your SDK must produce the same ID for a device even if the browser changes. If the ID changes between Chrome and Brave, you will be penalized for "Fragmentation."
  • Collision (External Uniqueness): Your SDK must produce different IDs for different physical devices. If two devices share the same ID, you will be penalized for "Collision" via the Two-Strike Rule.
  • Hardware Focus: Avoid using volatile signals (like window size, battery level, or IP address) as they vary between browsers and sessions, leading to fragmentation penalties.

Technical Architecture (Challenger & Proxy)

DFP v2 utilizes a two-tier architecture to ensure a realistic evaluation environment:

  1. Challenger API: The "Brain" of the operation. It receives your submission, manages the test session, notifies physical devices via SMTP, and calculates the final score based on the data received.
  2. DFP Proxy: The "Gateway." It hosts your fingerprinter.js script and acts as the collection point for device reports. This prevents direct communication between the test devices and the main Challenger, ensuring security and isolation.

The Lifecycle of a Fingerprint

  • Submission: You send your fingerprinter.js to the Challenger.
  • Distribution: The Challenger automatically pushes your script to the Proxy.
  • Collection: Physical devices visit the Proxy, execute your script, and send the results back to the Proxy.
  • Scoring: The Proxy forwards the collected results to the Challenger for the final calculation.

Mandatory Functions

Participants must implement and export two specific async functions in their fingerprinter.js script. These are the entry points used by the evaluation environment.

1. runFingerprinting()

This function is responsible for gathering device signals and generating the fingerprint hash.

  • Miner Requirement: Miners must capture the exact 32-character string returned by this function and submit it unmodified.
  • Goal: Collect hardware/software data and return a unique, consistent hash.

Evaluation Criteria

  • High Consistency: Maintain the same fingerprint for a single device across all 5+ target browsers.
  • High Uniqueness: Ensure no other physical device generates the same fingerprint.
  • Minimum Participation: At least 2 physical devices must successfully report fingerprints for a session to be valid.
  • Stability: The script must execute quickly and reliably within the evaluator's fp_timeout window.

Scoring System

The final score is an average of the points earned by each physical device in the session, normalized between 0.0 and 1.0.

1. Fragmentation Penalty

Each device starts with 1.0 point.

  • For every unique fingerprint string generated by the same device beyond the first, a penalty of -0.3 is applied.
  • Max Fragmentation: If a device generates 3 or more different IDs across browsers, its score for the session is automatically 0.0.

2. Two-Strike Collision Rule

This rule ensures your ID is unique across the network.

  • Strike 1: If a fingerprint generated by a device is shared by any other physical device in one browser batch, a penalty of -0.25 is applied.
  • Strike 2: If the same collision happens in 2 or more batches, that device's score becomes 0.0.

Scoring Example

Imagine a session with 2 devices across 5 browsers (10 batches total with n_repeat=2):

  • Device 1 (Perfect): Reports "ID-AAA" in all 10 batches.
  • Unique IDs: 1 (Penalty: 0)
  • Collisions: 0 (Penalty: 0)

  • Points: 1.0

  • Device 2 (Fragmented): Reports "ID-BBB" in 8 batches and "ID-CCC" in 2 batches.

  • Unique IDs: 2 (Penalty: -0.3)
  • Collisions: 0 (Penalty: 0)

  • Points: 0.7

  • Device 3 (Collided): Reports "ID-AAA" (Collides with Device 1) in 2 batches.

  • Unique IDs: 1 (Penalty: 0)
  • Collisions: 2 batches (Strike 2 triggered)
  • Points: 0.0

Final Session Score: (1.0 + 0.7 + 0.0) / 3 = 0.567

Submission

After local validation using the Testing Manual, package your script into a submission container. Ensure your fingerprinter.js is correctly placed in the miner template.