User-Agent and browser memory: some of the key parameters in anti-fraud systems

16.12.24

In today's world of technology, anti-fraud systems are becoming more and more sophisticated. In addition to using Canvas, parameters such as User Agent and browser memory capacity are widely used to uniquely identify users and detect fraudulent activities. Let's take a closer look at them.

#### History and Purpose of User-Agent

User Agent is a string sent by the browser to the server in an HTTP request that contains information about the device type, operating system, browser and its version.
Introduced in the early Internet era, User Agent was used to customize web content for different devices. Today, it is used not only to display web pages, but also in anti-fraud systems.

###### Where User Agent is used

- **Browser main thread:**
The User Agent string is available through navigator.userAgent. It is often parsed for primary device identification.
- **Web-Workers:**
In worker threads, access to User Agent is limited, but APIs like navigator.userAgentData allow platform information to be retrieved.
- **Service Workers:**
Similar to Web-Workers, Service Workers can indirectly work with the User Agent, but a main thread is required for direct analysis.
- **HTTP Requests:**
User Agent server-side processing allows you to identify devices and verify that they match other parameters.

###### Troubleshooting and User Agent spoofing

Attackers can modify User Agent through browser settings or use anti-detect browsers. This creates identification difficulties, but modern antifraud systems use correlation with other parameters (e.g., IP addresses or Canvas and WebGL fingerprints).

Let's look at examples of what the User Agent string looks like, let's open the <a href="https://browserleaks.com/ip/" target="_blank">browserleaks.com/ip</a> page in our browser:

![](/media/mdeditor/1_20241216191751822692.png)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0.0 Safari/537.36

###### What data is used to form the User Agent string?

General format according to the specification:

User Agent: Product/Version (System and Browser Information) Engine/Version (Engine Information) Browser/Version

1. **Product/Version** - identifier of the software product and its version
Example: Mozilla/5.0
1. **Additional platform information**
Example: (Windows NT 10.0; Win64; x64)
- Platform type - operating system identifier
Example: Windows NT 10.0
- Architecture - system architecture information
Example: Win64; x64
3. **Engine/Version** - rendering engine identifier and version.
Example: AppleWebKit/537.36
4. **Compatibility Information** 
Example: (KHTML, like Gecko)
5. **Browser Information** - Browser ID/Version 
Example: Chrome/131.0.0.0.0
6. **Compatibility marker/version** with which compatibility is claimed - Information about compatibility with other browsers 
Example: Safari/537.36

This is what the User Agent string looks like in the Chrome browser on a mobile device:

![](/media/mdeditor/2_20241216192607160068.jpg)

Note that the User Agent string is the main information for Anti-Fraud systems, a large amount of data collected from the user's browser using other APIs is compared for consistency with the obtained information in the User Agent string.

Above we have seen an example of obtaining User Agent from transmitted http headers. Antifraud systems also get browser information using JavaScript. Let's open the <a href="https://browserleaks.com/javascript/" target="_blank">browserleaks.com/javascript/</a> page and look at the information obtained from our browser:

![](/media/mdeditor/3_20241216193415905597.png)

On this page, the site retrieves information about the user's browser and system using two different APIs: the legacy Navigator API and the modern User Agent Client Hints API.

Let's compare the information obtained from Chrome (left) and Firefox (right) browsers:

![](/media/mdeditor/4_20241216193601962957.png)

From this example, we can see that there are significant differences between the two browsers: the amount of information returned, the format of the information, and the limitations of User Agent Client Hints API support in the Firefox browser. We can conclude that antifraud systems can easily detect a mismatch between the User Agent string and the browser engine. Let's consider an example of such a substitution, compare information from Firefox browser (left) and Chromium-based anti-detection browser (right):

![](/media/mdeditor/5_20241216193703498348.png)

After the substitution, the BuildID, oscpu values do not match in the anti-detect browser and unlike Firefox browser there is support for User Agent Client Hints API. Such a substitution will be noticed by antifraud systems very quickly.

Let's open our test page <a href="http://test-webapi.tech/ua/" target="_blank">test-webapi.tech/ua</a> in Chrome browser and see what other ways of getting User Agent can be used by Antifraud systems:

![](/media/mdeditor/6_20241216195315208753.jpg)

In this example, we get User Agent information and user browser information from http headers, in the main browser stream, in the Web Worker and in the Service Worker and compare the results:

![](/media/mdeditor/7_20241216195349681464.png)

Together with User Agent from the user's browser, Antifroad systems can get information about whether the device is mobile, the number of logical processor cores, the amount of RAM on the device and the number of simultaneous touch points supported by the device. Let's take a closer look at these parameters on our test page:

![](/media/mdeditor/8_20241217181209378089.jpg)

In the Main Thread Data section, let's pay attention to:

**“sec-ch-ua-mobile”**: “?0” - information derived from http headers, indicating that we are using a desktop browser
“maxTouchPoints": 0 - indicates that our device does not support Touch

**"hardwareConcurrency ”**: 12 - indicates the number of logical processor cores available for the browser

**"deviceMemory ”**: 8 - approximate amount of RAM in Gigabytes.

**"mobile ”**: false - information obtained through the User-Agent Client Hints API indicates that our device is not mobile.

#### Browser memory.

###### Allocated memory and its measurement

Browser memory parameters (deviceMemory, performance.memory) provide information about the available memory of the device. For example:

- navigator.deviceMemory returns the amount of memory in gigabytes.
- performance.memory in the main thread gives accurate information about current memory usage.

###### How memory is used in antifrod

1. **Device Identification:**
Different devices allocate memory differently. For example, mobile devices often have less memory than desktops.
2. **Swap test:**
Comparing claimed memory with actual usage helps to identify parameter spoofing.

###### Memory spoofing methods

- **Hiding real values:**
Attackers can use browser extensions to change the deviceMemory value.
- **Distorting performance data:**
For example, returning values that look plausible but do not match the actual device parameters.

Let's check our test page for information about: 
- **jsHeapSizeLimit** - Maximum memory size that can be allocated for JavaScript
- **totalJSHeapSize** - Total size of allocated memory
- **usedJSHeapSize** - The size of the memory actually used.

![](/media/mdeditor/8_20241216200315231723.png)

In Main **Thread Data - memoryAnalysis** section we check the memory size in the browser and this test is requested 3 times at small intervals.

Let's try to pass this test on a mobile device:

![](/media/mdeditor/9_20241216200419463523.jpg)

We may notice that the mobile browser rounds up the values given.

Let's repeat the test in the anti-detect browser using the mobile device profile:

![](/media/mdeditor/10_20241216200634149299.png)

The anti-detect browser correctly substituted only the values for one jsHeapSizeLimit property, the format of the values of the other properties remained similar to that of the desktop browser. Such a set of values can be a trigger for antifraud systems. It should be noted that the performance.memory property is not supported in all browsers, and the successful detection of such properties when substituting User Agent for a browser that does not support these properties, also raises suspicion among antifraud systems.

###### User Agent on the example of Amazon

Using amazon.com as an example, let's consider what information about User Agent the site receives.

Let's consider the information passed in http headers:

![](/media/mdeditor/11_20241216200733865891.png)

The site gets the following information about the user's device from http headers:
device-memory: 8
sec-ch-device-memory: 8.
sec-ch-ua: “Google Chrome”;v=“131”, “Chromium”;v=“131”, “Not_A Brand”;v="24”
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: “Windows”.
sec-ch-ua-platform-version: “10.0.0”.
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0.0 Safari/537.36

Now let's check what information related to User Agent the site got using JavaScript:

![](/media/mdeditor/12_20241216200833955147.png)

The site gets detailed information about the browser, browser version, browser manufacturer, platform, memory size, Touch support on the device, number of CPU cores using different APIs.

#### Conclusion

User Agent and browser memory are key parameters for user uniqueness in anti-fraud systems. Their use in combination with other factors such as Canvas fingerprinting and other APIs allows to create reliable algorithms to detect fraudulent activity.

*Bannykh M.V.

Antidetect

Graph of browser window size changes and their use in antifraud systems.

Browser window sizes and browser events, anti-fraud systems and user identification techniques

Analyzing browser window sizes and events helps anti-fraud systems detect data spoofing and action emulation.

Bannykh M.V.

05.01.25

User-Agent and browser memory: some of the key parameters in anti-fraud systems

Related posts

Browser window sizes and browser events, anti-fraud systems and user identification techniques