Darwinium Profiling

This article describes the nature, purpose and considerations of Darwinium's profiling. Suggested next pages:

• Javascript profiling overview: Javascript Profiling
• Javascript profiling via CDN, see Inserting Darwinium JS Profiling
• Javascript profiling via Tag, see Tags Deployment.
• Mobile SDK profiling, see Mobile SDK Deployment

Darwinium Profiling Overview

Darwinium Profiling collects client side information about the device, behaviour and certain connection. It is performed on:

• Javascript profiling via CDN: JavaScript inserted dynamically into GET request via an Edge worker (automatic)
• Javascript profiling via Tag: JavaScript Tag added to page
• Mobile Application: Native mobile SDK

The data collected is essential input to rules and models, contributing to determining risk indicative of fraud or the recognition of a good user.

Profiling Flow

1. Profiling Start
   When a user loads a page, activity or view, the start() method is invoked to begin profiling:

• JS CDN: Automatically triggered
• JS Tag & Mobile SDK: Your application must explicitly call start()

2. Profiling Collect
   When the user submits a form or triggers an action, the collect() method is invoked to create a base64-encoded profileBlob.

• JS CDN: Automatically triggered (controlled by an allow_list in profiling step configuration, Darwinium journey file)
• JS Tag & Mobile SDK: Your application must call collect() within the submit handler

3. Attach profileBlob to request
   The profileBlob is included as header: dwn-header of the submit request

• JS CDN: Automatically attached. Controlled by an allow_list in profiling step configuration, Darwinium journey file
• JS Tag & Mobile SDK: Your application must add this header directly wihtin the submit handler

4. Darwinium Processing
   Darwinium processes the profileBlob to resolve all collected profiling attributes. The handling differs based on step type

• Proxy Step (CDN) Events: Darwinium automatically removes the profileBlob from the request directly
• API Step Events: Your backend must take the profileBlob it receives, and include as dwn-profiling header when making the Darwinium API call

Proxy Step (CDN) Events

API Step Events

Consideration: CORS

Darwinium attaches collected profiling (as a base64 encoded blob) to the request as a header named:

dwn-profiling

If a CORS policy is in place and enforced, this header name will need to be added to list of allowed and expected headers.

Consideration: HTTPS Profiling

Darwinium initiates a call to perform packet connection fingerprinting (eg. VPN detection).

Example:

POST https://aps.wowscale.com/V5HSFNGGQR2fA.jpg?pid=7e8cd81814284baabbafee7c8d1ee62a

If you are using the connect-src directive, the following domains should be permitted for outbound calls

aps.wowscale.com
ats.wowscale.com
*.dxf.wowscale.com

If using manual Tags deployment, the subdomain which is hosting profiling tags should be added to both connect-src and script-src.

aps.yourdomain.com (example, replace with yours)
aps.yourdomain.net (example, replace with yours)

Consideration: Permissions Policy

Darwinium uses the following that may be restricted if a Permissions-Policy is being enforced. They should be given self, * or similar permission. Failure to give permission will result in those attributes not being profiled and throw a browser console permission error.

accelerometer
ambient-light-sensor
battery
gyroscope
magnetometer*
geolocation*

*only if geo toggle is actively enabled in journey config, disabled by default. Causes a permission popup