## General product behavior

Does Digital Intelligence collect and maintain device-based or hardware-based identifiers like IMEI, MAC address, or SIM card numbers?

Digital Intelligence SDKs do **not** collect or expose hardware identifiers such as IMEI, SIM, or eSIM information.

- **No IMEI or SIM/eSIM identifiers:**  
Modern iOS and Android platforms restrict access to these identifiers. As a result, our SDKs neither collect nor expose SIM/eSIM details, and IMEI is not collected.

- **No hardware MAC address:**  
Mobile operating systems and modern browsers obfuscate or block access to hardware MAC addresses. Our SDKs therefore do not collect or expose a device’s hardware MAC. Instead, our signals rely solely on OS-permitted attributes to ensure privacy compliance and reliable device intelligence.

## Cross-platform field availability

Why are some Digital Intelligence response fields only available on certain platforms?

Each SDK platform (iOS, Android, Web) has access to different operating system APIs and browser capabilities. For example:

- **Native mobile SDKs** (iOS and Android) can access GPS, battery status, VPN state, and CPU architecture through OS-level APIs.  
- **The Web SDK** collects browser-specific signals such as WebRTC IPs, user agent strings, WebGL renderer details, and HTML form submission events.

Because these capabilities are inherent to each platform, certain fields are only populated when the session originates from a compatible SDK. Server-side fields (network analysis, history, entity profiling, and velocity metrics) are always available regardless of the client platform.

Why don't I see webRtcPublicIp or webRtcInternalIp in mobile SDK sessions?

WebRTC is a browser API that enables peer-to-peer communication and can reveal the user's real IP address even behind a VPN or proxy. Native mobile SDKs for iOS and Android do not use WebRTC, so these fields are only populated for sessions captured by the Web SDK.

For mobile sessions, use the `device.network.connectionIp` and `device.network.realIp` fields, which are available on all platforms.

Why is vpnStatus not available on Web?

The `device.attributes.network.vpnStatus` field relies on native OS APIs that report whether a VPN connection is active. Browsers do not expose this information to web applications.

For web sessions, use the server-side network analysis fields (`device.network.isVpn`, `device.network.isProxy`, `device.network.isConsumerPrivacy`) to detect VPN and proxy usage through IP reputation analysis. These fields are available on all platforms.

Why is isTamperedAndroidBuild only reported for Android?

The `device.computed.isTamperedAndroidBuild` field detects whether the Android OS build differs from the manufacturer's original version (for example, custom ROMs). This check is specific to the Android operating system and has no equivalent on iOS or Web.

For iOS, jailbreak detection is available through `device.attributes.iOSAttributes.isRooted`. For web sessions, use `device.computed.isVirtualMachine` and behavioral signals to assess session integrity.

Why are location and battery fields sometimes missing from mobile sessions?

Location and battery data require specific conditions to be collected:

- **Location** requires explicit user permission. If your app hasn't requested location access or the user has denied it, these fields are omitted. You can suppress location collection by setting `omitLocationData` to `true` in `SigmaDeviceOptions`.
- **Battery** data depends on device state and OS-level access. In rare cases, the OS may restrict battery information.

Missing fields do not indicate an SDK error. Design your workflows to handle optional fields gracefully.

Why is submissionCount only populated for Web sessions?

The `behavioral.aggregations.submissionCount` field counts HTML form submission events, which are specific to browser-based environments. Native mobile apps do not use HTML form submissions.

For mobile sessions, use other behavioral aggregation fields (`clickCount`, `inputChangeCount`, `focusCount`) to assess user interaction patterns. These fields are available across all platforms.

Why are many Digital Intelligence fields showing high null rates in my data?

High null rates are common when analyzing Digital Intelligence data in aggregate across all platforms. There are three main causes:

1. **Platform-specific fields return null on non-matching platforms.** For example, `androidAttributes.isRooted` is null for every iOS and Web session. If your traffic is 80% Web and 20% Android, this field is null 80% of the time — by design. Filter your analysis by `device.attributes.platform` to see accurate null rates per platform.

2. **Permission-dependent fields are null when permissions are denied.** Location fields (`device.attributes.location.*`) require the user to grant location access. If most users deny the permission, these fields have high null rates on mobile. Battery fields have similar behavior.

3. **Input-dependent fields are null when data isn't provided.** Velocity metrics (such as `velocityMetrics.historicalCount.surName`) require the corresponding PII fields (surname, email, mobile number) in the Evaluation API request. `deviceContext` requires passing a context string to `processDevice()`. `customerUserId` and `userId` are optional fields that must be explicitly provided.

Refer to the [Data Dictionary](https://help.socure.com/riskos/docs/data-dictionary) platform availability section for a per-field breakdown of which platforms support each field.

Which fields depend on input data in the evaluation request?

Several Digital Intelligence response fields are only populated when specific data is included in the RiskOS™ Evaluation request:

- **Velocity metrics** (`velocityMetrics.historicalCount.*`) — Requires the corresponding PII fields: `firstName`, `surName`, `email`, or `mobileNumber`. If you omit `surName` from the request, `velocityMetrics.historicalCount.surName` is null.
- **Entity profiler** (`entityProfiler`) — Populated based on the PII entities (phone, email, nationalId) included in the request.
- **`customerUserId`** — Optional. Only populated if provided in the evaluation request.
- **`userId`** — Optional. Only populated if provided in the evaluation request.
- **`deviceContext`** — Only populated if a context string is passed to `processDevice()` on the client.

## SDK blocking and ad blockers

We've previously had trouble with a similar vendor's SDK being blocked by ad blockers. Are there any known issues or best practices we should be aware of to prevent this with your SDK if needed?

Mainstream ad blockers (using default settings) typically **do not block** the Digital Intelligence (DI) Web SDK.

However, most SDK failures we observe are caused by:

- Enterprise firewalls
- VPN configurations
- Strict Content Security Policies (CSPs)
- Network restrictions that block SDK scripts or ingestion endpoints

### Required endpoints

The DI SDK requires access to the following endpoints from the browser or application:

| Endpoint | Purpose |
| --- | --- |
| `https://ingestion.dv.socure.io` | Device and behavior data ingestion |
| `https://network.dv.socure.io` | Network telemetry collection |
| `https://analytics.dv.socure.io` | Analytics and session data |

### Best practices to prevent blocking

#### 1. Allowlist Socure DI endpoints in your Content Security Policy (CSP) and network egress

Add Socure DI endpoints to your CSP allowlist:

```undefined
CSP connect-src: https://ingestion.dv.socure.io https://network.dv.socure.io https://analytics.dv.socure.io
```

If loading the SDK via script tag, also allowlist the SDK host:

```undefined
CSP script-src: https://sdk.dv.socure.io
```

#### 2. Use NPM package installation (recommended)

Installing the Web SDK via NPM (instead of script tags) provides several advantages:

- Avoids content filters targeting third-party script hosts
- Improves load reliability in JavaScript frameworks (React, Angular, Vue)
- Reduces dependency on external CDNs

#### 3. Optional: Use a reverse proxy (advanced)

For highly restrictive environments, configure the SDK to route through a customer-owned reverse proxy using the `configBaseUrl` parameter. This makes traffic appear as first-party requests.

Please coordinate with Socure before enabling this setup.

#### 4. Implement graceful fallback and retry

**Retry mechanism**: Add retry logic with exponential backoff for session initialization

- **Timeout handling**: Handle transient network issues (DNS resolution, mobile network hiccups)
- **Fallback strategy**: Ensure your application continues to function when session tokens are unavailable

This approach ensures other verification checks can proceed even if the DI SDK encounters issues.

## Field availability by platform

The Digital Intelligence SDK collects different signals depending on the platform (iOS, Android, or Web). The following table summarizes key differences. For a complete list of all fields, see the [Digital Intelligence data dictionary](https://help.socure.com/riskos/docs/data-dictionary).

| Signal category | iOS | Android | Web | Notes |
| --- | --- | --- | --- | --- |
| Network (IP, ISP, ASN, geolocation) | ✓ | ✓ | ✓ | Available on all platforms |
| VPN / proxy / Tor detection | ✓ | ✓ | ✓ | Network-level detection works on all platforms |
| `vpnStatus` (on-device VPN detection) | ✓ | ✓ | ✗ | Requires OS-level network interface inspection |
| Root / jailbreak detection (`isRooted`) | ✓ | ✓ | N/A | Not applicable to web browsers |
| Tampered build detection (`isTamperedAndroidBuild`) | ✗ | ✓ | N/A | Android-specific integrity check |
| Emulator / virtual machine detection | ✓ | ✓ | ✓ | Detection methods differ by platform |
| Device model / manufacturer | ✓ | ✓ | ✓ | Web infers from user agent; native reads hardware APIs |
| GPS location | ✓ | ✓ | ✓* | Web uses the Geolocation API (requires user permission and HTTPS) |
| Battery state and level | ✓ | ✓ | ✗ | Requires native battery APIs |
| Mobile carrier information | ✓ | ✓ | ✗ | Requires native telephony APIs |
| Browser and user agent details | ✗ | ✗ | ✓ | Web-only: `userAgent`, `browser`, `browserVersion`, `pixelDepth`, `hardwareConcurrency`, `colorDepth`, WebGL renderer |
| Low-entropy User-Agent Client Hints (`hasLowEntropyUserAgentClientHints`) | ✗ | ✗ | ✓ | Web-only: computed from browser User-Agent Client Hints |
| WebRTC IP detection | ✗ | ✗ | ✓ | Browser-only: `webRtcPublicIp`, `webRtcInternalIp` |
| Behavioral aggregations (`submissionCount`) | ✗ | ✗ | ✓ | Web-only metric |
| Device history (first/last seen, days seen) | ✓ | ✓ | ✓ | Available on all platforms |
| Velocity metrics | ✓ | ✓ | ✓ | Available on all platforms; uses a 90-day rolling window |
| Entity profiler | ✓ | ✓ | ✓ | Available on all platforms |

Why are some Digital Intelligence fields not available on all platforms?

Field availability differs across iOS, Android, and Web because each platform exposes different OS-level APIs and enforces different privacy restrictions:

- **Operating system restrictions:**  
Mobile platforms (iOS and Android) provide access to native APIs for telephony, battery, VPN interface inspection, and hardware integrity checks that are not available in browser environments. Conversely, browsers expose web-specific APIs (WebRTC, WebGL, user agent parsing) that native SDKs do not use.

- **Privacy and permission models:**  
Each platform enforces its own permission model. For example, GPS location requires explicit user permission on all platforms, but the mechanism differs — native SDKs use `CoreLocation` (iOS) or `LocationManager` (Android), while the Web SDK uses the browser Geolocation API. Some signals (for example, carrier name) require permissions that only exist on mobile.

- **Platform-specific security signals:**  
Certain fraud signals are inherently platform-specific. Root/jailbreak detection applies only to mobile devices. Tampered build detection applies only to Android. Browser attributes (WebGL renderer, hardware concurrency) apply only to web.

- **All platforms share core signals:**  
Network-level intelligence (IP analysis, ISP, ASN, proxy/VPN/Tor detection), device history, velocity metrics, and entity profiling are available across all platforms because they rely on server-side analysis rather than client-side APIs.