Browser window size is one of the parameters that web applications can use to identify users' devices. Although this information seems insignificant at first glance, its unique characteristics can be a powerful tool in anti-fraud systems. Such systems analyze browser window sizes, including real-time changes, as well as data transmitted in HTTP headers to detect suspicious activity and identify attempts to spoof information. ###### History and Applications of Browser Window Size Analysis Browser window size (viewport) measurement was first made available to developers via the DOM API starting with early versions of JavaScript. This data was used to adapt content to users' screens. As technology evolved, anti-fraud systems began using window size as an additional parameter to create a digital fingerprint of the user. Today, window size data can include: - Viewport dimensions (window.innerWidth and window.innerHeight). - The overall size of the browser window. - Supported screen resolutions. - Display refresh rate. These parameters can vary by device, operating system, and browser, creating a unique set of characteristics. ###### Window sizes in HTTP headers Some browsers convey window size information in HTTP headers, such as User-Agent Client Hints (e.g., Viewport-Width and Device-Width). This allows websites to adapt content to fit the screen size, but also gives anti-fraud systems the ability to use this data to check for spoofing. **Example of data transmitted:** - Viewport-Width: 1920 - Device-Width: 2560 A discrepancy between the reported data and the actual window size may indicate the use of an anti-detect browser. ###### Methods of user identification via window sizes **1. Size stability analysis** Antifraud systems track changes in window size during a session. For example: - Abrupt size changes (especially if they correspond to popular preset resolutions) may indicate spoofing. - Constant window size values that are uncharacteristic of the device may be signs of emulation. **2. Comparison with screen resolution** The system checks if the window size matches the declared screen resolution: - If the screen resolution is 1920×1080 and the window dimensions are 3000×2000, it may be a spoofing attempt. **3.Using anomalies in rendering** Sometimes browsers may report incorrect window sizes due to peculiarities in DOM processing or the graphics environment. These anomalies can be used to detect spurious devices. ###### Methods for spoofing window sizes Fraudsters use the following approaches for disguise: 1. **Fictitious dimensions:** changing window.innerWidth and window.innerHeight values via developer tools or plugins. 2. **Use of preset settings:** emulating the sizes of popular devices to avoid suspicion. 3. **Spoofing HTTP headers:** changing Viewport-Width and Device-Width values. ###### Spoofing detection methods **1. Testing window sizes** An antifraud system may create scripts that require window resizing (e.g., pop-ups). Spoofed browsers may not adequately respond to such requests. **2. Checking for size matching** Comparing data from the DOM (e.g. window.innerWidth) with data from HTTP headers helps to identify mismatches. **3. Analyze user behavior** Window size changes during interaction with the site may be unusually smooth or, on the contrary, overly abrupt in the case of emulation. Let's look at examples of what sizes from a user's browser Antifraud systems may receive. Let's open the browserleaks.com/javascript page in Chrome browser.  On this page, the site determines the monitor size, screen orientation and angle, external and internal dimensions of the browser window. Let's understand more about what sizes and values resources can get. Let's open our test page test-webapi.tech/screen  The test page shows the following parameters: **Orientation Type** Indicates the current screen orientation of the device (e.g. portrait-primary, landscape-primary). **Orientation Angle** Rotation angle of the screen relative to its natural orientation, in degrees. **Avail Width** The width of the screen available for use (excluding system elements such as the taskbar). **Outer Width** The full width of the browser window, including areas outside the visible page, such as scroll bars and frames. **Screen Width** The full width of the device screen in pixels. **Inner Width** The width of the visible content area of the browser window (excluding scroll bars and frames). **Avail Height** The height of the screen available for use (excluding system elements such as the taskbar). **Outer Height** The full height of the browser window, including areas outside the visible page, such as scroll bars and frames. **Screen Height** The full height of the device screen in pixels. **Inner Height** The height of the visible content area of the browser window (excluding scroll bars and frames). **Avail Left** The horizontal position of the available screen area relative to the beginning of the screen (usually 0). **Avail Top** Vertical position of the available screen area relative to the beginning of the screen (usually 0). **Max Touch Points** The maximum number of touch points supported by the device. **Color Depth** The number of bits used to represent the color of a single screen pixel. For example, 24 or 32. **Pixel Depth** The depth of the pixel in bits, usually the same as the Color Depth value. **Device Pixel Ratio** The ratio of physical device pixels to logical pixels. For example, 1.0 for standard screens or 2.0 for Retina displays. **Client Width** The width of the content area inside the html element without scroll bars. **Client Height** The height of the content area inside the html element without scroll bars. **Screen X** The horizontal position of the upper left corner of the browser window relative to the device screen, in pixels. **Screen Y** Vertical position of the upper left corner of the browser window relative to the device screen, in pixels. **Scroll Width** The full width of the page content, including hidden areas that can be scrolled. **Scroll Height** The full height of the page content, including hidden scrollable areas. **Visual Viewport Width** Width of the area displayed to the user, including possible scaling. **Visual Viewport Height** Height of the area displayed to the user, including possible scaling. **Scroll X** The horizontal offset of the page from the beginning, in pixels. **Scroll Y** Vertical offset of the page from the beginning, in pixels. **Height Difference (Outer - Inner)** The difference between the full height of the browser window and the visible height of the content. Presented to determine the size of the browser's administrative panel. Among the presented parameters there are parameters that are rarely changed within one profile, for example: Orientation Type, Screen Size, Color Depth, Pixel Depth, Max Touch Points, there are parameters that can be changed only on certain types of devices, for example: Orientation Angle, Screen X, Screen Y. Let's compare the data obtained from Chrome browser and anti-detect browser:  For the desktop version, the antidetect-browser swaps the screen and browser size parameters quite well, but the Screen X and Screen Y values are 0, which corresponds to the fact that our browser is bound to the top left corner of the screen and this is the location we will get in the antidetect-browser, every time we open the profile, while by default a new window of the real Chrome browser opens in the center of the screen. It should be noted that we will get the same browser size every time we use the profile, while a normal user will often change the size of a browser window opened not in full screen. Let's pay attention to the Height Difference value, in Chrome browser occupying part of the screen the height of the administrative panel is 95px, let's check this value in Chrome browser with bookmarks panel:  The height of the administrative panel in this case is 129px. This way the resource can accurately determine the visibility of the bookmarks panel in the user's browser. Let's open our test page in Firefox browser:  In the Firefox browser, the height of the administrative panel is 91px, so anti-fraud systems can determine whether or not the browser declared by the user in the User-Agent matches the standard dimensions of the original browser. It is important to note that the size of the administrative panel in full-screen browsers is different from the size of the browser that occupies part of the user's screen. Let's repeat the test on a mobile device and an anti-detect browser that tries to present itself as a mobile device:  The anti-detect browser sets the Inner Height value equal to the Outer Height, whereas in a real mobile browser, the Inner Height value is greater than the Outer Height value, and this substitution can be a trigger for anti-fraud systems. Also note that the value of vertical scrolling of the page, in the tested mode of the anti-detect browser, is made only by integer pixel values (parameter Scroll Y). ###### Browser Action Events and Their Role in Anti-Fraud Systems Modern web applications actively use browser events to improve user interaction. However, actions such as clicks, scrolls, and touch events also provide unique data that can be used by antifraud systems to detect suspicious activity. These systems analyze user behavior to detect bots, action emulation, or data spoofing. ###### Basic Browser Action Events Browser events include a wide range of interactions that a user may perform on a web page. The most important of these are: - **Clicks (click, dblclick):** record mouse button clicks on page elements. - **Scroll:** records the shift of the visible area of the page. - **Mouseover (mouseover, mouseout, mousemove):** tracks cursor movement. - **Touch events (touchstart, touchmove, touchend):** records actions on touchscreen devices. - **Text input (keydown, keyup, input):** records text-based user actions. - **Focus (focus, blur):** Determine whether input elements are activated or deactivated. - **Responses to change (resize, orientationchange):** detect changes in browser window size or device orientation. ###### Role of Events in Anti-Fraud Systems Antifraud systems use events to analyze actual user behavior and compare it to expected scenarios. The key aspects of the analysis are: **1. Speed and rhythm of actions** ◦ Bots often mimic user actions, but may exhibit an unnatural rhythm, such as clicking or scrolling too fast. ◦ In the case of scrolling, real users tend to move the page at different speeds, while bots may use linear motion. **2. Characterization of touch events** ◦ Real touch events have unique touch coordinates and may contain force data (if the device supports such sensors). ◦ Emulated touch events are often captured as a fixed value or coordinate pattern. **3. Unnatural Behavior** ◦ Anti-fraud systems track repetitive behaviors, such as the same time between clicks or the same scroll angle. ◦ Cursor immobility for long periods of time can also be a sign of automation. ###### Event spoofing techniques Attackers can use various approaches to emulate events: **1. Automated scripts**. Using automation libraries such as Puppeteer or Selenium to create artificial events (e.g. document.dispatchEvent). **2. Simulating touch events** Developer tools allow you to run simulated touches on non-existent devices. **3. Event Data Substitution** Changing event properties, such as coordinates or execution time, to hide automation. ###### Methods to detect spoofing Anti-fraud systems use different approaches to detect spoofing: **1. Timestamp analysis** Comparing event timestamps to real time: artificial events may exhibit unrealistic speeds. **2. Coordinate verification** Systems analyze the distribution of coordinates of clicks or touch events. Suspicious patterns (e.g., concentrating in one place) may indicate spoofing. **3.Use of captcha** Interactive tests require actions that are difficult to emulate (e.g., dragging and dropping items). **4. Comparison of browser data** Event parameters (e.g., touchpoint or scroll data) are compared to device data to identify inconsistencies. Examples: Let's open the test page test-webapi.tech/touch in the Chrome browser and enter text in the text input box:  Let's click on the button:  Note that the mouse movement coordinates and the event of clicking the button and clicking the input field before typing text are recorded, these values correspond to the mouse movement coordinates. The page scrolling events are also recorded  For anti-fraud systems it will look suspicious to click a button, if before the click, the mouse did not move to the coordinates of the button on the page, or closing a tab in the browser without moving the mouse to the browser bar. Let's check the events on a mobile device and in an anti-detect browser with a simulated mobile browser. Let's compare the text input events in the field:  In this example, we can see significant differences: 1. the Touch event is produced by integer coordinates in the anti-detect browser. 2. The radius of the Touch event in the antidetect browser is 11.5px, which is more than 10 times the actual mobile device. 3. In antidetect-browser, the visible part of the screen is not reduced, it does not simulate the appearance of a virtual keyboard on the device screen, unlike the real device. Note that the size of the visible part of the screen on mobile devices changes not only when the keyboard appears on the device screen, but also at other events, for example, when scrolling down the page, the address bar in the mobile version of the browser is hidden and the size of the visible part of the screen increases. Let's compare the events when scrolling down the page:  In this test, we can see that the log of page scrolling actions in the anti-detect browser is different from the log on the mobile device. In addition to seeing only integer coordinate values, we also get a touch event record after each time the page moves down by a small pixel value. Nowadays many anti-fraud systems track events in the browser, if we open the amazon site we can see that this site tracks a large number of events such as: page load time, page resizing, user actions on the page.  #### Conclusion Browser action events and screen and browser size values of the user's screen and browser provide a large dataset for anti-fraud systems. Browser size analysis allows users to be unique, and user behavior analysis allows detection of bots, emulation, or other deception attempts. To improve accuracy, such systems use combined approaches, comparing event data with device characteristics and expected scenarios. *Bannykh M.V.*
