Fingerprinting Without Invading Privacy: Our Minimal Approach to Device Identification

Device fingerprinting has a bad reputation - and deservedly so. Companies like Facebook and Google collect hundreds of data points to track users across the web. We take a different approach: minimal fingerprinting that serves legitimate purposes without invasive surveillance.

Why Any Fingerprinting?

We need some form of device identification for two legitimate purposes:

Fraud Detection

Bots often have fingerprints that dont match real devices - impossible screen sizes, missing browser features, inconsistent data. Comparing fingerprints helps catch this.

Frequency Capping

Advertisers want to limit how often the same user sees their ad. Without some identifier, we cant enforce this. Cookies are dying; fingerprinting is one alternative.

What We Dont Collect

First, lets be clear about what we refuse to collect:

Canvas Fingerprinting

Drawing hidden images and hashing the result. Extremely identifying, completely unnecessary for our purposes. We dont do it.

WebGL Fingerprinting

Extracting GPU information through WebGL rendering. Another highly unique identifier we skip.

Audio Fingerprinting

Processing audio signals to identify hardware. Invasive and not useful for ad fraud detection.

Font Enumeration

Listing all installed fonts. Very identifying, not relevant to our needs.

Battery Status

Battery level and charging state. Was briefly used for tracking; we never touch it.

Hardware Enumeration

Detailed CPU, memory, and device specifications. More than we need.

Our Minimal Fingerprint

We collect only what serves legitimate purposes:

User-Agent String

Standard HTTP header that every request includes anyway:

• Browser name and version
• Operating system
• Device type indication

Why: Essential for targeting and basic fraud detection. Already transmitted in every HTTP request.

Viewport Dimensions

The visible browser window size:

• window.innerWidth
• window.innerHeight

Why: Bots often have anomalous viewport sizes. Also useful for ad size selection.

Screen Dimensions

Physical screen resolution:

• screen.width
• screen.height

Why: Validates device type claims. A mobile claiming 2560x1440 is suspicious.

Device Class

Derived categorization: desktop, mobile, tablet:

• Based on User-Agent and screen size
• Cross-referenced for consistency

Why: Core targeting parameter. Mismatches indicate spoofing.

Platform

Operating system from navigator.platform:

• Win32, MacIntel, Linux, iPhone, etc.

Why: Should match User-Agent OS. Discrepancies flag fraud.

Language

Browser language setting:

• navigator.language

Why: Targeting parameter. Also useful for detecting geographic mismatches.

Timezone Offset

Difference from UTC in minutes:

• new Date().getTimezoneOffset()

Why: Should roughly match geographic location. Major mismatches indicate VPN/proxy.

ASN (Autonomous System Number)

Network identification from IP address:

• Identifies ISP or hosting provider
• Distinguishes residential from datacenter traffic

Why: Datacenter ASNs are red flags. Residential ASNs suggest real users.

What This Data Cannot Do

Our minimal fingerprint is deliberately weak for cross-site tracking:

Not Unique Enough

Millions of users share the same User-Agent + screen size + timezone combination. We cannot identify individuals.

Not Persistent

User-Agent changes with browser updates. Timezone changes with travel. The fingerprint drifts over time.

Not Cross-Site

We only see data on our ad requests. We cannot correlate with other sites like Facebook/Google can.

How We Use This Data

Fraud Scoring

We check for internal consistency:

• Does User-Agent match reported platform?
• Does screen size make sense for device type?
• Does timezone roughly match IP geolocation?
• Is ASN residential or datacenter?

Inconsistencies raise fraud scores. Consistent data lowers them.

Frequency Capping

We create a non-unique bucket identifier:

• Hash of IP + User-Agent + screen dimensions
• Good enough to limit repeated impressions
• Not precise enough to track individuals

Targeting Validation

We verify targeting claims:

• Campaign targets mobile? Check device class.
• Campaign targets Germany? Check timezone and language.
• Campaign targets Chrome? Check User-Agent.

Privacy by Design

Our approach follows privacy-by-design principles:

Data Minimization

Collect only what serves a stated purpose. If we dont need it, we dont collect it.

Purpose Limitation

Data collected for fraud detection isnt repurposed for building user profiles or sold to data brokers.

Storage Limitation

Fingerprint data is transient. Used for real-time decisions, then discarded or aggregated into non-identifying statistics.

No Third-Party Sharing

We dont share fingerprint data with advertisers, publishers, or external parties. They see aggregate statistics, not individual fingerprints.

The Tradeoff We Accept

Our minimal approach means:

Less Precise Frequency Capping

Multiple users might share a bucket identifier. Some users might see ads slightly more than intended. We accept this imprecision to preserve privacy.

Less Fraud Signal

Sophisticated fraudsters can spoof our minimal data points. We rely on behavioral signals and external providers to fill gaps.

No Cross-Session Tracking

We cant recognize a returning user across sessions without cookies. Fine - thats not our business model anyway.

We believe advertising can work without surveillance capitalism. Our minimal fingerprinting proves it.