Castle offers client-side SDKs for web and native mobile, with the goal to collect device information in order to determine uniqueness of devices. This allows Castle to reliably identify devices for future events, as well as monitor user interactions for anomalies.
The fingerprinting allows detection of, for example, a single device being used to access or register for multiple accounts. It also allows Castle to detect attempts to falsify device information, which is frequently a sign of malicious intent. It is also required for generating a risk score.
The data collected by Castle's fingerprinting varies between platform and SDK used. The reason for this variance is that different platforms expose different device properties. In general, the properties include things like screen resolutions, pixel density, video and audio capabilities, installed plugins, and any exposed hardware properties such as number of CPU cores.
Castle does not intentionally collect any sensitive or personal identifiable information, for instance no text strings are collected from the client.
Below is an overview of collected parameters based on SDK. Please note that Castle is continuously improving this fingerprinting with new parameters.
|Timezone information||Unique device identifier||Unique device identifier|
|User Agent||Memory information||Memory information|
|Operating system||Storage, used and available||Storage, used and available|
|CPU information||Location (if permission)||Location (if permission)|
|System languages||Screen resolution||Screen resolution|
|Mouse and keyboard interactions||Device orientation||Device orientation|
|Screen size||Carrier information||Carrier information|
|Installed plugins||CPU Information||CPU Information|
|Canvas fingerprinting||Emulation detection||Emulation detection|
|WebGL information||Jailbreak status||Root status|
|Headless browser checks||Timezone information||Timezone information|
|System and keyboard languages||System and keyboard languages|
|Battery information||Battery information|
|Sensor data||Sensor data|
Most of the parameters above are available:
When generating the fingerprint, Castle tries to minimize the chance of "collisions", so that two different physical devices cannot be merged together to produce a single fingerprint. Because our risk models rely on so much more than just device fingerprints, we would rather miss a fingerprint sometimes than merge two separate devices by mistake. The reason behind this optimization is so your team will be able to confidently block or contact an individual seen using multiple accounts on the same device, without risking customer backlash due to a false positive.
In the case where two users buy the same computer and both install Google Chrome at the same time, even though their configurations are nearly identical, our device fingerprinting would see them as different devices after we account for other pieces of context, such as when, how, and from what location a new user account was created.
Despite clearing cookies and opening incognito windows in your browser, our device fingerprinting will continue to attempt to resolve to the same fingerprint, and on mobile devices, the fingerprints are designed to survive app uninstalls and memory wipes. Having said that, there will be times when we will prefer to create a new fingerprint rather than attempt to resolve an existing one, using the same optimization as described previously. This can happen when a fingerprint hasn't been seen for over a month, then returns after having reset the storage on their device or updated it to a new version, and then creates a brand new account. However, as long as the user logs into the same account that they have previously used, we will very likely resolve it to the same device.
Fingerprinting is available for the browser (Castle.js) and for various mobile application development platforms, including native iOS, native Android, React Native, and Flutter.
The fingerprinting data is represented by a variable called request token which is designed to be generated fresh before each server-side request to Castle's APIs. Tokens are meant to be used only once per server-side request and will expire after 120 seconds. If a request token generated for a specific device is copied and used for a different device, we apply spoof detection in order to detect such tampering.
Castle's mobile SDKs are open-source repositories on Castle's GitHub account. We welcome the creation of issues and pull requests from the community
Updated 3 months ago