Forem: Savannah Copland 👋

Why Browser Anti-Fingerprinting Techniques Are Not Effective

Savannah Copland 👋 — Wed, 14 Sep 2022 19:55:10 +0000

In this article, we will discuss why the existence of privacy-focused browsers doesn’t necessarily affect the effectiveness of fingerprint-based browser identification to prevent online fraud.

We start with a technical dive into how today’s anti-fingerprinting solutions work, focusing on uniformity and privacy-through-randomization techniques and their specific implementations. We list multiple examples from popular browsers, including one of the more popular privacy-focused browsers, Brave. We then elaborate on why device identification remains a valuable tool to prevent online fraud. Let’s dive right in.

Anti-fingerprinting

There are two common approaches when it comes to preventing browser fingerprinting. The more commonly implemented method makes all browser instances across all devices look as similar as possible. In theory, any fingerprinting should result in a single identifier or a very small number of different identifiers distributed across all devices, making the fingerprints useless.

This is typically achieved by making functional changes to web APIs known to be good sources of entropy. As a result, some APIs are completely disabled because most websites don’t rely on them. Others are revised to return a dummy value regardless of the actual real value. As you can imagine, these practices dramatically change users’ web experience for the worse.

However, some implementations hide the original functionality behind permission prompts. So the user can choose to let a website use a specific API in its original form, even though it might be used for fingerprinting (for example, the privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPromptsadvanced preference option in Firefox, which prevents websites from reading canvas data).

However, permission prompts are still not user-friendly, and most users do not understand the associated risks. Making a reasonable decision is, therefore, very hard. A good case in point is Chrome’s decision to handle some permission requests automatically without even notifying the user.

The second approach aims to make every browser instance as distinct as possible through randomization. As a result, every browser gets a random fingerprint that changes between websites and browsing sessions or between page refreshes. This additional randomness makes it impossible to use fingerprints for reliable identification. The Brave browser, a mainstream privacy-focused Chromium fork, was the first popular browser to implement privacy-through-randomization protections. One strongly voiced advantage of this approach is that sufficient randomization to prevent reliable fingerprinting can be done in a way that does not affect the web user experience. To better understand both approaches, let’s explore some examples.

Uniformity

Gecko’s (the browser engine behind Firefox and the Tor Browser) fingerprinting protection is a prominent example of the uniformity approach in the real world. The feature is controlled by the privacy.resistFingerprinting flag in the browser’s advanced preferences (about:config). At the time of writing, this feature is still considered experimental and disabled by default in Firefox because, as mentioned in the official documentation: “It is likely that it may degrade your Web experience.” Unlike the Tor Browser, which enables this feature for all security levels (the default being the “Standard” level).

Under the hood, this flag controls what values are returned from various web APIs. In some cases, these values are fixed across all platforms:

The prefers-color-scheme CSS media feature will always match “light.”
The navigator.hardwareConcurrency read-only property is set to 2.
The navigator.maxTouchPoints read-only property is set to 0.
The screen.colorDepth read-only property is set to 24.
The default time zone obtained by calling window.Intl.DateTimeFormat() is always UTC.

However, sometimes the spoofed, fixed values are platform-dependent. A comment in Gecko’s source code explains why this is the case:

As a result, calling navigator.platform will return either Win32, MacIntel, Linux aarch64, or Linux x86_64, still concealing the actual platform but placing users into different buckets nonetheless. Similarly navigator.userAgent, navigator.appName, navigator.appVersion and the Gecko-specific navigator.oscpu will return spoofed values.

Another good example of the uniformity approach to minimize fingerprint-able browser surface is the recent changes made to the deprecated navigator.plugins and navigator.mimeTypes features. The WHATWG HTML Standard was updated to reflect Flash deprecation and specified that browsers should always return a fixed list of supported plugins and mime types (depending on a new read-only navigator.pdfViewerEnabled property). Gecko and Chromium have already adopted the change.

Randomization

One common technique used for browser fingerprinting is based on the internals of the Canvas API. A developer needs to create a canvas, draw a specially crafted image on it, then extract the image data and hash it into a short identifier. Subtle differences in the video card, graphics driver versions, and system-level properties like installed fonts, usually result in the hash representing a simple, stable, high-entropy browser fingerprint.

The code can look like this:

const canvas = document.createElement('canvas')
const context = canvas.getContext('2d')

canvas.width = 122
canvas.height = 110
context.globalCompositeOperation = 'multiply'
for (const [color, x, y] of [['#f2f', 40, 40], ['#2ff', 80, 40], ['#ff2', 60, 80]]) {
    context.fillStyle = color
    context.beginPath()
    context.arc(x, y, 40, 0, Math.PI * 2, true)
    context.closePath()
    context.fill()
}

context.fillStyle = '#f9c'
context.arc(60, 60, 60, 0, Math.PI * 2, true)
context.arc(60, 60, 20, 0, Math.PI * 2, true)
context.fill('evenodd')

const result = canvas.toDataURL()

Please see this file from our open-source FingerprintJS library, for a production-ready example.

The last step, calling the HTMLCanvasElement.toDataURL() method, is when Brave’s anti-fingerprinting protections add randomization. The raw canvas data is passed through a method called PerturbPixels().

Source

The method uses a per-eTLD+1 session key to change randomly selected bytes in the image data deterministically. This means that on different websites and whenever you restart the Brave browser, the data changes in a new way, meaning that the fingerprint based on this data changes, too. It is also worth calling out that the image data changes in an invisible way to humans, but because of how hash functions work, typical fingerprinting approaches yield different fingerprints.

Here you can see how the image produced by the code above changes between Google Chrome and Brave:

However, looking at the first 255 bytes of the underlying data, we can see the images are vastly different:

Needless to say, Brave does the same thing in three other methods that are used to serialize raw canvas data: CanvasRendering2dContext.getImageData, HTMLCanvasElement.toBlob, and OffscreenCanvas.convertToBlob.

Brave uses a similar approach for other sources of entropy, namely for the Web Audio APIs, when serializing data using the AnalyserNode and AudioBuffer interfaces and various WebGL APIs.

Randomization is considerably simpler for simple sources of entropy, such as navigator.hardwareConcurrency or the prefers-color-scheme CSS media future. For hardware concurrency, depending on the fingerprinting protection mode, which can be either “default” or “max,” Brave chooses a number randomly between 2 and the true value or 8. The preferred color scheme is always reported as “light” if the protection mode is “max.”

Brave’s wiki pages show that the User-Agent, Plugins, and values returned by the Enumerate Devices APIs are also randomized. The Client Hints, Battery Status, Web Bluetooth APIs, and “HSTS fingerprinting” and “WebRTC IP leakage” are meant to be blocked instead.

Interestingly, however, this wiki page is currently not fully up-to-date as WebRTC has dedicated settings. Instead, the Client Hints JavaScript API’s getHighEntropyValues method returns accurate information, and the Battery Status API returns fixed values in all cases.

Prevention Challenges

As demonstrated in the examples above, using uniformity significantly reduces web experience. This can also be confirmed by looking at the relevant bug trackers, where users ask for options to disable anti-fingerprinting features, such as spoofing the timezone. As a result, browsers that implement this approach tend to have a limited user base and do not represent a mainstream alternative to browsers without custom anti-fingerprinting features. Using randomization has its challenges and, in many cases, still affects the web experience negatively, especially for entropy sources that return a simple value, like a number or a boolean flag. For this reason, most users still have to choose between using a “standard” protection or “maximum” protection.\
More importantly, the algorithms for randomization are prone to several errors:

Websites can detect artificial randomization by calling the affected APIs twice, finding anomalies in the randomized data, or simply assuming that values are randomized by identifying the browser. Websites can afterward either ignore these values or process them in a way that aids fingerprinting.
The original entropy from the raw source data still exists, and implementations adding additional randomness to the underlying data might be reversible in practice.
When other potentially indirect methods exist of learning about the raw source data, the original entropy can still be used without using one of the obvious ways to serialize the original data.

Both previously mentioned approaches, making all browser instances as similar as possible or as distinct as possible, fail to be effective unless they cover a significant number of potential entropy sources, which is quite hard to accomplish in real-world settings. And that proves to be very hard to do in real life.

Generating reliable fingerprints depends on the kind of traffic a website has and the effectiveness of anti-fingerprinting features. For example, if most users use a popular browser like Google Chrome, you need more entropy sources to differentiate and identify different Chrome instances reliably. On the other hand, browsers with a smaller user base are more easily fingerprint-able. In those cases, ignoring randomized entropy sources is also feasible.

wpoven.com and kinsta.com report that Brave has a market share of 0.05% for 2022. ctrl.blog mentions a 1.02% share amongst its readers in 2020. In addition, brave reports 50.2 million active monthly users in 2021.

For Firefox, statscounter reports a market share of 3.15% as of August 2022. Wikipedia mentions claims from different sources as of October 2021, varying from 2.18% to 4.4%. Firefox’s figures show around 200 million monthly active users.

Based on our internal information from August 2022, traffic originating from Brave on Desktop and Android accounts for 1.57% of all identification events. For Firefox, it’s 1.997%. Interestingly, Firefox traffic matches the values spoofed by the privacy.resistFingerprinting preference accounts for only 0.48% of all Firefox traffic we see. The Tor Browser accounts for 0.017% across all events.

Entropy sources are also not limited to just inherent browser characteristics. It’s important to acknowledge that system-level and network-level characteristics are just as effective. Additionally, fingerprinting can be supported via storing client-side identifiers too.

All this context is important to keep in mind when reasoning about the effectiveness of browser identification in the context of preventing online fraud.

You might have noticed that when exploring Brave’s implementation of the privacy-through-randomization technique earlier, we ignored the per-eTLD+1 aspect of it. It prevents third-party cross-site fingerprinting, which is especially important for web tracking and advertising companies. However, it does not prevent a site from fingerprinting its visitors in the same-site (or first-party) context (that’s what the per-session aspect of the randomization tries to do).

Preventing online fraud

Spamming comment sections, fake product reviews or coupons, cashback fraud, and abusing password reset and registration forms are all examples of online fraud that every big or small online service has to deal with inevitably. Even though all of these are very common, effective and scalable solutions prove to be very difficult to implement.

A simple solution often comes to mind is to put the affected functionality behind authentication. This is a good strategy as long as the functionality wasn’t explicitly designed for unauthenticated visitors. Moreover, with authentication in place, you have to deal with a new problem; automated account creation and verification. At this point, many services think about using a CAPTCHA, whether it is to stop the automated account creation or the original form of abuse.

Inevitably, CAPTCHAs will lead to a worse user experience and reduce conversion rates. However, more often than not, the abuse returns through other means. For example, when native mobile APIs expose the same functionality, CAPTCHAs won’t help, as their native apps support is essentially non-existent.

Online services need reliable web browsers and native mobile device identification in these situations. In our experience, when done right, browser fingerprinting works wonders to prevent online fraud. Furthermore, because it happens in the background, it does not introduce additional friction unless a user is deemed fraudulent. To learn more about specific examples, you can read through our case studies, use case guides, or contact us and get hands-on guidance on incorporating Fingerprint Pro’s high accuracy identification API into your fraud prevention stack.

Exploiting IndexedDB API information leaks in Safari 15

Savannah Copland 👋 — Mon, 17 Jan 2022 17:14:53 +0000

DISCLAIMER: FingerprintJS does not use this vulnerability in our products and does not provide cross-site tracking services. We focus on stopping fraud and support modern privacy trends for removing cross-site tracking entirely. We believe that vulnerabilities like this one should be discussed in the open to help browsers fix them as quickly as possible. To help fix it, we have submitted a bug report to the WebKit maintainers, created a live demo, and have made a public source code repository available to all.

Watch our Youtube overview

In this article, we discuss a software bug introduced in Safari 15’s implementation of the IndexedDB API that lets any website track your internet activity and even reveal your identity.

We have also published a demo site to see the vulnerability in action:

Try the demo

The leak was reported to the WebKit Bug Tracker on November 28, 2021 as bug 233548.

Update (Monday January 17th 2022): Apple engineers began working on the bug as of Sunday, have merged potential fixes, and have marked our report as resolved. However, the bug continues to persist for end users until these changes are released.

A short introduction to the IndexedDB API

IndexedDB is a browser API for client-side storage designed to hold significant amounts of data. It’s supported in all major browsers and is very commonly used. As IndexedDB is a low-level API, many developers choose to use wrappers that abstract most of the technicalities and provide an easier-to-use, more developer-friendly API.

Like most modern web browser technologies, IndexedDB is following Same-origin policy. The same-origin policy is a fundamental security mechanism that restricts how documents or scripts loaded from one origin can interact with resources from other origins. An origin is defined by the scheme (protocol), hostname (domain), and port of the URL used to access it.

Indexed databases are associated with a specific origin. Documents or scripts associated with different origins should never have the possibility to interact with databases associated with other origins.

If you want to learn more about how IndexedDB APIs work check out the MDN Web Docs or the W3C specification.

The IndexedDB leaks in Safari 15

In Safari 15 on macOS, and in all browsers on iOS and iPadOS 15, the IndexedDB API is violating the same-origin policy. Every time a website interacts with a database, a new (empty) database with the same name is created in all other active frames, tabs, and windows within the same browser session. Windows and tabs usually share the same session, unless you switch to a different profile, in Chrome for example, or open a private window. For clarity, we will refer to the newly created databases as “cross-origin-duplicated databases” for the remainder of the article.

Why is this leak bad?

The fact that database names leak across different origins is an obvious privacy violation. It lets arbitrary websites learn what websites the user visits in different tabs or windows. This is possible because database names are typically unique and website-specific. Moreover, we observed that in some cases, websites use unique user-specific identifiers in database names. This means that authenticated users can be uniquely and precisely identified. Some popular examples would be YouTube, Google Calendar, or Google Keep. All of these websites create databases that include the authenticated Google User ID and in case the user is logged into multiple accounts, databases are created for all these accounts.

The Google User ID is an internal identifier generated by Google. It uniquely identifies a single Google account. It can be used with Google APIs to fetch public personal information of the account owner. The information exposed by these APIs is controlled by many factors. In general, at minimum, the user's profile picture is typically available. To learn more, refer to Google's People API documentation.

Not only does this imply that untrusted or malicious websites can learn a user’s identity, but it also allows the linking together of multiple separate accounts used by the same user.

Note that these leaks do not require any specific user action. A tab or window that runs in the background and continually queries the IndexedDB API for available databases, can learn what other websites a user visits in real-time. Alternatively, websites can open any website in an iframe or popup window in order to trigger an IndexedDB-based leak for that specific site.

How many websites are affected?

We checked the homepages of Alexa’s Top 1000 most visited websites to understand how many websites use IndexedDB and can be uniquely identified by the databases they interact with.

The results show that more than 30 websites interact with indexed databases directly on their homepage, without any additional user interaction or the need to authenticate. We suspect this number to be significantly higher in real-world scenarios as websites can interact with databases on subpages, after specific user actions, or on authenticated parts of the page.

We also saw a pattern where indexed databases named as universally unique identifiers (UUIDs) are being created by subresources, specifically ad networks. Interestingly, loading of these resources seems to be in some cases blocked by Safari’s tracking prevention features, which effectively prevents the database names from leaking. These leaks will also be prevented if the resources are blocked by other means, for example when using adblocker extensions or blocking all JavaScript execution.

Does Safari private mode protect against the leak?

Firstly, when followed, the same-origin policy is an effective security mechanism for all window modes. Websites with one origin should never have access to resources from other origins regardless of whether a visitor is using private browsing or not unless it’s explicitly allowed via cross-origin resource sharing (CORS).

In this case, private mode in Safari 15 is also affected by the leak. It’s important to note that browsing sessions in private Safari windows are restricted to a single tab, which reduces the extent of information available via the leak. However, if you visit multiple different websites within the same tab, all databases these websites interact with are leaked to all subsequently visited websites. Note that in other WebKit-based browsers, for example Brave or Google Chrome on iOS, private tabs share the same browser session in the same way as in non-private mode.

Demo

We created a simple demo page that demonstrates how a website can learn the Google account identity of any visitor. The demo is available at safarileaks.com. If you open the page and start the demo in an affected browser, you will see how the current browsing context and your identity is leaked right away. Identity data will only be available if you are authenticated to your Google account in the same browsing session.

Moreover, the demo detects the presence of 20+ websites in other browser tabs or windows, including Google Calendar, Youtube, Twitter, and Bloomberg. This is possible because database names, which those websites interact with, are specific enough to uniquely identify them.

The supported browsers are Safari 15 on macOS, and essentially all browsers on iOS 15 and iPadOS 15. That is because Apple’s App Store guidelines require all browsers on iOS and iPadOS to use the WebKit engine.

Try the demo

Reproducing the leak

To reproduce the leak yourself, simply call the indexedDB.databases() API. In case websites opened in other frames, tabs, or windows interact with other databases, you will see the cross-origin-duplicated databases.

Based on our observations, if a database is deleted, all related cross-origin-duplicated databases are also deleted. However, there seems to be an issue when developer tools are opened and a page refresh happens. On every page refresh, all databases are duplicated once again and seem to become independent from the original databases. In fact, it’s not even possible to delete these duplicated databases by using the regular indexedDB.deleteDatabase() function.

This behavior makes it very difficult to use the developer tools to understand what exactly is happening with the databases that a website interacts with. It is therefore recommended to use other means of debugging (for example rendering output into the DOM instead of using console logs or the JavaScript debugger) when trying to reproduce the leaks described in this article.

How to protect yourself

Unfortunately, there isn’t much Safari, iPadOS and iOS users can do to protect themselves without taking drastic measures. One option may be to block all JavaScript by default and only allow it on sites that are trusted. This makes modern web browsing inconvenient and is likely not a good solution for everyone. Moreover, vulnerabilities like cross-site scripting make it possible to get targeted via trusted sites as well, although the risk is much smaller. Another alternative for Safari users on Macs is to temporarily switch to a different browser. Unfortunately, on iOS and iPadOS this is not an option as all browsers are affected.

The only real protection is to update your browser or OS once the issue is resolved by Apple. In the meantime, we hope this article will raise awareness of this issue.

Demo: Disabling JavaScript Won’t Save You from Fingerprinting

Savannah Copland 👋 — Thu, 21 Oct 2021 18:08:06 +0000

Fingerprinting is a way to identify website users without using cookies or data storage. Instead, device properties like language and installed fonts are used to create highly accurate, unique identifiers that work even if the browser has incognito mode turned on.

A common misconception is that disabling JavaScript can prevent fingerprinting. Since advertisers and bad actors use it for ad targeting and tracking your online activity, it’s a natural (albeit incorrect) assumption that disabling JavaScript will protect you against fingerprinting. In this article, we will demonstrate that fingerprinting can occur even in the absence of JavaScript.

Check out the demo to see it in action:

https://noscriptfingerprint.com/

The demo should show the same fingerprint, even if visitors attempt to conceal their identities using the following methods (among others):

Requesting desktop mode in mobile browsers
Spoofing the user agent
Using incognito mode
Changing the internet connection

These are just a handful of the many use cases where fingerprinting can uniquely identify devices, even as other methods fail.

How the demo works

When you open the main page of the demo, your browser sends several HTTP requests to the demo’s server automatically. The list of requests and the request contents depend on your specific device and browser (more on this later). The server extracts meaningful pieces of data — or signals — from the HTTP requests and stores them in a database. Your device signals stay the same as you visit different websites and subsequently can be used to reliably identify and track you over time.

The server links the requests of a single visitor together using a unique random token by inserting this token into the main page’s HTML code. As a result, all HTTP requests from the main page contain the token, and different visitors requesting the main page receive unique pieces of HTML code.

Here’s a simplified example of how this works:

function getMainPageHTML() {
  const token = makeRandomString()
  return `<html>
  <body>
    <img src="/image/${token}" />
    <iframe src="/frame/${token}"></iframe>
    <a href=”/result/${token}”>See the fingerprint</a>
  </body>
</html>`
}

Your fingerprint is shown on a separate page. The URL contains the token as well. The server finds your signals using this token, calculates a hash sum using all of the signals, and returns the result to the browser (the hash sum is the fingerprint).

In our demo, the page is placed inside an iframe to make the fingerprint viewable on the main page, but keep in mind that the server can access the fingerprint behind the scenes, at any moment.

No-JavaScript signal sources

The following is a list of signal sources that don’t require JavaScript; however, not all signals listed are included in the demo, largely due to their low contribution to accuracy or inherent instability.

IP address (not included in demo)

The server receives your IP address with every HTTP request. Typically, IP addresses are unique but are considered unstable: when your underlying internet connection changes (e.g., from Wi-Fi to cellular) or VPN is turned on, your device IP address changes as well. For this reason, IP address is not used as a signal in the demo.

HTTP headers

HTTP headers are a part of every HTTP request and response — they come before the body (i.e., the payload) and consist of name/value pairs separated by colons. This meta information enables better communication between the browser and the server. Some HTTP request headers contain information about the user’s browser settings. The demo uses these header values as signals.

The following illustration depicts a browser HTTP request and a server HTTP response when a user visits example.com:

You can view the headers under the Network section of your browser’s development toolbox.
Browsers send these headers with every HTTP request; in turn, the backend can parse signals from these headers from any HTTP request, including the request for the main page.

User-Agent (not included in demo)

This HTTP header signal contains detailed information about the browser version, operating system, and other device-related information. This header value is considered unstable, as mobile browsers alter it when a desktop version of the website is requested. Additionally, Safari provides an easy way to change the user-agent value and many privacy-related browser extensions spoof the user-agent. For these reasons, user-agent isn’t used in the demo.

Accept

Browsers use this HTTP header value to tell servers what file types are supported.

For example:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9

The file types supported depends on the browser engine and version. Browsers send different header values for different types of resources (e.g., webpages, images, stylesheets, video and audio). The demo makes individual requests to get Accept header values for each resource type:

<html>
  <head>
    <link rel="stylesheet" href="/headers/(token)/style" />
  </head>
  <body>
    <img src="/headers/(token)/style" />
  </body>
</html>

No separate request for the web page header is needed because browsers send the header with the request for the main page.

The demo doesn’t use <audio> and <video> tags, since media requests aren’t made when the page is invisible; if these tags were used, the page would produce a different fingerprint when visible. Also, the Accept header value for audio/video requests never changes in a single browser engine.

Accept-Language

This HTTP header value tells the server what languages the client prefers. For example:

Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,ru;q=0.7

Google Chrome only sends one language in incognito mode, so the demo uses the first language as a signal.

Accept-Encoding

This HTTP header value advertises which content encoding (e.g., compression algorithm) the browser is able to understand and varies with browser engine/version. For example:

Accept-Encoding: gzip, deflate, br

Client Hints (not included in demo)

Client Hints are special HTTP headers. Browsers don’t send these by default — if the server responds with an Accept-CH header, the browser will add the Client Hints to future requests to this website. For example, this response header makes browsers send a Device-Memory and a Sec-CH-UA-Full-Version header:

Accept-CH: Device-Memory, Sec-CH-UA-Full-Version

Currently, only Google Chrome and other Chromium-based browsers support this header. Chromium browsers don’t send Client Hints when JavaScript is disabled, thus Client Hints aren’t used in the demo.

CSS

The demo collects several signals using the browser’s CSS engine. All the CSS signals work the same way: the page’s CSS code determines whether or not to send an HTTP request based on the browser, OS, device, and other parameters. In general, the CSS code for a signal looks like this:

<div class="css_probe_42"></div>
<style>
  magic-query .css_probe_42 {
    background: url('/signal/(token)/(signalName)');
  }
</style>

If your browser matches the magic-query CSS selector, it will apply the background style to the <div> tag and make an HTTP request to download the background image (with the URL /signal/(token)/(signalName)). The server will then save this information in the database. If your browser doesn’t match the selector, the server will treat the absence of a request as a signal as well. css_probe_42 is a random class name for a signal, as every signal must have a unique class name.

The magic selectors used in the demo are described in the following section.

Feature queries

A special CSS rule called @supports applies CSS styles only if the browser supports the given feature. Different browsers vary in terms of their features, so these can be used to tell browser engines apart.
This is CSS code that will only trigger an HTML request in Chromium-based browsers:

@supports(-webkit-app-region: inherit) {
  .css_probe_42 {
    background: url(...);
  }
}

Other features (in place of -webkit-app-region) used in the demo include:

-moz-appearance detects Firefox and other browsers with the Gecko engine
-apple-pay-button-style detects Safari
-webkit-touch-callout detects any iOS browser
-moz-osx-font-smoothing detects macOS Firefox
accent-color detects modern Chromium (version 93+) and Gecko (version 92+) browsers. Since Tor uses an outdated version of Gecko, the absence of this feature indicates that the browser is most likely Tor.

Media queries

@media is a CSS keyword that enables the application of CSS styles based on various conditions outside the page. In general, CSS code with a media query looks like this:

@media (feature: value) {
  .selector {}
}

If the feature matches the value, the interior CSS code is applied to the page. A feature may have multiple possible values, so the demo can produce various HTTP requests depending on the feature value. The browser either makes one of the requests, or none at all.

This is what the CSS code looks like in general:

<div class="css_probe_42"></div>
<style>
  @media (featureX: value1) {
    .css_probe_42 {
      background: url('/signal/(token)/featureX/value1');
    }
  }
  @media (featureX: value2) {
    .css_probe_42 {
      background: url('/signal/(token)/featureX/value2');
    }
  }
  /* ... */
</style>

The demo uses the following media features:

hover and any-hover indicate whether the device allows users to hover over HTML elements
pointer and any-pointer indicate whether the device has a pointing device (e.g., a mouse) and how accurate it is.
color indicates whether the device’s screen supports colors and how many bits are used in a single color channel of the screen
color-gamut denotes the color space the device’s screen is capable of
forced-colors indicates whether the browser is set up to restrict the color palette
inverted-colors indicates whether the operating system inverts the screen colors
monochrome indicates whether the screen is monochrome — either naturally or because of operating system settings
prefers-color-scheme indicates whether the user has chosen the light or the dark theme in the operating system settings
prefers-contrast indicates whether the user has asked the system to increase or decrease the amount of contrast between adjacent colors
prefers-reduced-motion indicates the user’s preference in having less motion on the screen
dynamic-range indicates whether the display supports HDR

The next set of features are a bit trickier: device-width, device-height and -webkit-device-pixel-ratio reflect the resolution of the whole screen and its pixel density. The values of these features are arbitrary — you can write CSS code that has a @media rule for all the thousands of possible values, but it will only add unnecessary bloat to your code base. Instead, the demo checks ranges of values using the min and max rules.

Below is an example of how to detect screen width:

@media (max-width: 349.99px) {
  .css_probe_42 { background: url('/signal/(token)/screenWidth/,350) }
}
@media (min-width: 350px) and (max-width: 999.99px) {
  .css_probe_42 { background: url('/signal/(token)/screenWidth/350,1000) }
}
@media (min-width: 1000px) and (max-width: 2499.99px) {
  .css_probe_42 { background: url('/signal/(token)/screenWidth/1000,2500) }
}
@media (min-width: 2500px) {
  .css_probe_42 { background: url('/signal/(token)/screenWidth/2500,) }
}

More range entries with narrower values will result in a higher degree of precision.

The screen width and height values of an Android device will swap when it’s rotated from portrait orientation to landscape, and vice-versa. In order to preserve the fingerprint, the demo swaps the values in order to make the width always be smaller than the height.

Fonts

Operating systems have a myriad of different built-in fonts; additionally, desktops systems typically allow users to add their own custom fonts. It’s impossible to retrieve a list of all the user’s fonts without JavaScript (and the user’s permission), but it is possible to check whether a specific font is installed.

A CSS rule called font-face adds a custom font for use on the web page. The rule includes a set of font names to search the device for and a URL of the font file. If an installed font with the given name is found, the browser will use it; otherwise it will download the font file from the specified URL. For this reason, the server can make the determination that the font is missing if the URL has been requested. For example:

<div style="font-face: 'Helvetica';">a</div>
<style>
  @font-face {
    font-family: 'Helvetica';
    src: local('Helvetica'),
         url('/signal/(token)/fontHelvetica') format('truetype');
  }
</style>

The demo uses the following fonts:

Roboto and Ubuntu are available on Android and ChromeOS
Ubuntu is available on Ubuntu
Calibri and MS UI Gothic are available on Windows
Gill Sans and Helvetica Neue are available on macOS
Arimo is available on ChromeOS

As you can see, installed fonts are an effective way to tell operating systems apart.

Conclusion

Disabling JavaScript doesn’t prevent your device from being fingerprinted, as most browsers will still leak an abundance of data such as IP addresses, behavior patterns, and more. And since most websites require JavaScript to function properly, using this method to preserve your online privacy will invariably lead to a suboptimal web experience.

Special browsers like Tor guarantee anonymity and the exact same fingerprint across all users; for those that take privacy to the extremes, this may be the only option.

Star, follow, or fork our no JavaScript fingerprinting demo
Email any questions you have to oss@fingerprintJS.com
Join our Discord channel to discuss all things FingerprintJS, cybersecurity, and privacy
Join our team and work on exciting research in device security: work@fingerprintjs.com

How Android Wallpaper Images Can Threaten Your Privacy

Savannah Copland 👋 — Tue, 05 Oct 2021 21:33:47 +0000

Android 12’s highly anticipated Material You design system features wallpaper-based color theming and advanced customizations powered by color extraction. These UI enhancements allow users to select a wallpaper (i.e., a personal background image) from which an optimal palette of colors is automatically generated and applied to the device’s look and feel globally.

Unfortunately, such personalization can carry a high price in compromised privacy. In this article, we’ll demonstrate how Android wallpapers can be used to track users and explore ways to prevent your device from being exploited.

Android wallpaper images vs. user privacy

The WallpaperManager class was introduced in 2009 as part of the release of Android 2, API version 5. The class provides methods for interacting with wallpapers, including getDrawable() for retrieving the current system wallpaper as a drawable resource.

Using the following code, a drawable resource can be represented as a byte array:

private fun calculateWallpaperBytes(): ByteArray {
   val imageBitmap = wallpaperManager.drawable.toBitmap()
   val stream = ByteArrayOutputStream()
   imageBitmap.compress(Bitmap.CompressFormat.PNG, 100, stream)
   return stream.toByteArray()
}

Byte arrays can be used to restore original images from Android wallpapers, which are highly likely to contain personal information or details uniquely important to the user. Every app on your device can view and download photos of your family, pets, favorite bands or movies, and anything else you may have set as a wallpaper. Moreover, you couldn’t prevent them from doing so before Android 8.1.

As it stands, a large percentage of devices are running Android 8.1 or earlier (almost 44.6% at the time of this writing, per Google Analytics) and still vulnerable to this exploit.

A new color extraction method

Starting with Android 8.1, the getDrawable() method requires the use of READ_EXTERNAL_STORAGE, a less insecure but nonetheless risky permission as it enables access to all media on a device (and more privileged data). To compensate for the limited functionality, an easier way to extract colors was also introduced in Android 8.1: getWallpaperColors(int which), which returns 3 main colors from a wallpaper image.

Like iOS, Android allows users to determine which specific screens to use wallpaper images, and the integer argument “which” sets which exact wallpaper image to use for color extraction. There are two options: the constant values WallpaperManager.FLAG_SYSTEM or WallpaperManager.FLAG_LOCK.

// WallpaperManager.FLAG_LOCK for the the lock screen

val colors = WallpaperManager

.getInstance(context).getWallpaperColors(WallpaperManager.FLAG_SYSTEM) 

val primaryColor: Int = colors.primaryColor.toArgb()

val secondaryColor: Int = colors.secondaryColor.toArgb()

val tertiaryColor: Int = colors.tertiaryColor.toArgb()

The above code illustrates how to extract colors using a context object with primary, secondary and tertiary colors corresponding to the most popular colors in the picture (primary being the most popular). Note that no special permissions are required to use this new method.

The following is an example of color extraction using the new method with a real picture:

The methods may return null in some scenarios (e.g., when custom launchers redefine wallpaper management logic without using the WallpaperManager class). However, if a wallpaper was set once by WallpaperManager, the method will return a not-null value.

The science of color extraction

Since Android is open source, we can readily determine how the method actually works. According to the code, colors are the result of work of Variational K-means quantizer. Every image pixel is represented by a color and every color is a 3-dimensional point in space (e.g., RGB color space). All pixels form a set in space, and the algorithm performs clustering of the set on K parts with finding K points, which are equidistant from others in the set.

Above is a visualization of how the K-means method works, courtesy of vas3k. This particular case is 3-means in a 2-dimensional space.

In the case of Android, colors are represented in the HSL color space and distance is calculated using classical measures of euclidean distance. The results are three shades of an image that are equidistant (in the color space) from every pixel of the image.

A universe of combinations

This color extraction algorithm is basically a map from the set of all possible images to the RGB color space. The set is infinite and the RGB color space is limited by 2²⁴ combinations. Theoretically, this means every RGB combination is possible. Every color is represented by 32 bits, but only 24 matter. Alpha channels will always be equal to 1 (according to sources), while every component of the colors R, G and B have 256 possible combinations, or 2⁸.

Since each component is independent, we can directly multiply the number of combinations together. This comes out to: 2⁸ * 2⁸ * 2⁸ = 2²⁴ combinations for every color. We have 3 colors for a image, and 2²⁴ * 2²⁴ * 2²⁴ = 2⁷² combinations per image.

The same logic applies to the second wallpaper image, and they can be set up independently of each other. From one wallpaper image we have 72 bits and 144 bits using system wallpaper and lock screen wallpaper — 144 bits and 2¹⁴⁴ combinations. The more combinations possible, the higher probability of generating a unique value suitable for use as an ID. And hence, it’s likely you can easily be tracked.

2¹⁴⁴ = 22,300,745,198,530,623,141,535,718,272,648,361,505,980,416

How large is this number, exactly? For context, the universe is made up of around 10⁸⁰ atoms. And 2¹⁴⁴ is approximately equal to 10⁴³. So the squared value of combinations is larger than the number of atoms in the universe! It’s safe to say that this outnumbers all devices on the Earth, for the foreseeable future.

The identification algorithm

As you may recall, developers can use byte arrays to restore wallpaper images prior to Android 8.1. After version 8.1, 144 bits can be extracted from wallpaper colors. Both can be used as an ID, but let’s use them instead as inputs for the SHA-256 hash function (for unification).

We have an ID that contains 256 bits, is unique across all applications, and only changes when the device wallpaper changes. The code for getting the ID is:

val id = hasher.hash(

   if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O_MR1) {

       extractWallpaperBytes()

   } else extractColorsBytes())

The ID remains the same even after reinstalling the application and only changes when the wallpaper changes.

Try it yourself

For demonstration purposes, we’ve created an open source application that calculates the ID and checks its uniqueness. You can download the app on Google Play (for Android 5.0 and above, no permissions are required); the source code is available on GitHub.

Note: the method does not work on custom launchers that redefine logic of wallpaper management without using WallpaperManager class.

How to prevent wallpaper tracking on your Android device

The following measures can help prevent wallpaper tracking on your Android device:

Never use private or personal images for wallpapers, especially on devices running Android 8.1 and earlier.
Use a default wallpaper and don’t change it. By using a custom image, you inadvertently add entropy and uniqueness for distinguishing your device from others.
Check if your launcher has redefined the logic of the device’s wallpaper management (you can do this with our demo application).
Don’t install suspicious applications.
Be sure to keep your device operating system continuously updated.
Use anti-malware software to ensure your installed applications are behaving as expected.

Conclusion

As you can see, signals generated from wallpaper color extraction can be used to create a single identifier available to all applications, no additional permissions required. That said, extracting colors from device wallpapers is just one way mobile developers can uniquely profile Android devices, and it’s not the most dependable at that.

For some examples of more stable and reliable methods, please view our fingerprint-android library source code. Google has not restricted these for a number of years now, and it is unlikely that it ever will. At the end of the day, doing so would impact Android’s efficacy as an advertising platform — and for the world’s largest tech firm, it’s a constant juggle between balancing these interests with protecting user privacy.

Get in touch

Star, follow, or fork our production-grade library for Android device fingerprinting
Email any questions you have to oss@fingerprintJS.com
Join our team and work on exciting research in device security: work@fingerprintjs.com

iOS 15 iCloud Private Relay Vulnerability Identified

Savannah Copland 👋 — Mon, 20 Sep 2021 19:06:49 +0000

Apple’s new iCloud Private Relay service allows users to hide their IP addresses and DNS requests from websites and network service providers. In this article, we’ll demonstrate how this security feature can be circumvented and discuss what users can do to prevent their data from being leaked.

You’ll need to turn on iCloud Private Relay to test the vulnerability. At the moment iCloud Private Relay is available only in Safari on iOS 15 for iCloud+ subscribers.

Try the demo on our blog

Please note that this leak only occurs with iCloud Private Relay on iOS 15—the vulnerability has been fixed in MacOS Monterey beta.

IP addresses and online privacy

Online privacy is a hot topic of debate these days. Internet users don’t like being tracked online; on the other hand, advertisers need to glean user behavior insights to display the most relevant (and profitable) ads. Unfortunately, this requires access to sensitive and private information that users may not be willing to share.

Your IP address is one such piece of information used for tracking your activity across websites. These numerical labels (e.g., 1.2.3.4) are relatively stable and unique even if they aren’t dedicated, and can be used to determine your location with building-level precision.

Another way interested parties can track your online activity is to analyze your domain name system (DNS) requests. Like users and their devices, a website is also identified by its IP address. However, visitors need only type in the associated domain name (e.g., example.com) into the address bar, since DNS does the hard part of translating alphanumeric domain names into numeric IP addresses for proper routing.

This of course makes the internet a lot more user friendly, but also creates another way for interested parties to track your online behavior. DNS requests contain the names of the websites you visit, so they can be used to see your browsing history and your interests. DNS requests are unencrypted unless DNS-over-HTTPS is implemented, allowing your internet service provider and other parties between you and the DNS server to see your unencrypted DNS requests.

What is iCloud Private Relay

Browser vendors (most notably Apple) have in recent years made a concerted effort to improve the security and privacy of their users. iCloud Private Relay is Apple’s latest feature for protecting users against these online tracking techniques.

According to Apple’s website:

“iCloud Private Relay is a service that lets you connect to virtually any network and browse with Safari in an even more secure and private way. It ensures that the traffic leaving your device is encrypted and uses two separate internet relays so no one can use your IP address, location, and browsing activity to create a detailed profile about you.”

The service works by proxying network/HTTP traffic (including DNS requests) from the Safari browser, as well as unencrypted HTTP traffic from applications. By doing this, Apple claims that network providers no longer can see your DNS requests and unencrypted HTTP traffic; similarly, websites visited will only see your iCloud-assigned proxy IP address.This address is drawn from a pool shared between multiple iCloud Private Relay users, grouped by their approximate location (Apple provides a public table of proxy IPs/locations).

The following diagram from Apple illustrates how iCloud Private Relay handles HTTPS requests and what each party sees:

iCloud Private Relay is available exclusively for iCloud+ subscribers running iOS 15 or macOS 12 Monterey with the Safari browser. Unfortunately, it’s unavailable in several countries due to regulatory limitations.

You can learn more about iCloud Private Relay in this video from Apple.

How to get the real IP of a client that uses iCloud Private Relay

If you read the IP address from an HTTP request received by your server, you’ll get the IP address of the egress proxy. Nevertheless, you can get the real client’s IP through WebRTC. The process is described in detail below.

If you want to go straight to the leak explanation, skip the following “what is” sections.

What is WebRTC

WebRTC (web real-time communication) is a browser API for websites to establish direct communication between website visitors (i.e., peer-to-peer). The communication allows sending and receiving audio, video, and arbitrary data between browsers without requiring an intermediate server. All modern browsers support WebRTC natively; for example, Google Hangouts is one of the more popular applications that uses WebRTC — it works with all browsers and launches meetings with a click/tap, no plugin installation required.

WebRTC is a complex API. More information is available from this Google guide; however, we will only cover the aspects required for the IP address leak.

In order for browsers to communicate with each other, they first need to connect. This sounds simple, but in actuality is not a trivial task because— unlike servers—a website visitor’s device has no public IP to connect to. The ICE protocol was created to solve this problem.

What is ICE

ICE (interactive connectivity establishment) is a framework used by WebRTC. It lets two browsers find and connect with each other for direct, peer-to-peer communications.When one browser wants to connect to another, it will collect all possible hosts in a process called “collecting ICE candidates”. An ICE candidate is a piece of text that includes the host (IP address or domain name), port, protocol and other information. The browser will return the ICE candidates to the browser application.

The following is an example of an ICE candidate (see the full format description in the RFC document):

Let’s say Alice wants to connect to Bob. Alice’s browser will collect all its ICE candidates and send them to Bob through the website’s server. This is the only time when a server is needed, any further communication will happen directly between Alice and Bob. When Bob receives Alice's ICE candidates from the server, it will try to connect to Alice using the addresses and ports from the list until it finds one that works.

Different types of ICE candidates exist—for this demonstration, we’re concerned with the Server Reflexive Candidate. You can recognize it by a typ srflx substring. It contains an IP address and a port from a STUN server that allows Bob to connect through Alice's NAT.

What are NAT and STUN

NAT (network address translation) is a protocol that allows multiple devices to connect to the internet using a single internet connection and public IP address. Every home router implements NAT—in fact, your device is most likely behind NAT now.

Devices inside a network using NAT have no public IP addresses, so they can’t be accessed from the internet directly. The STUN (session traversal utilities for NAT) protocol was created to solve this problem.

A STUN server performs one small but critical task: it returns your public IP address and port number. We won’t cover NAT traversal in-depth (you can learn more here); just know that Alice gets an ICE candidate containing her public IP address and port returned by the STUN server, and Bob can connect to her using this IP address and port.

This is what happens when a WebRTC connection is established from behind a NAT:

WebRTC requests two types of IP addresses from the STUN server: IPv4 and IPv6. If the STUN server and the user’s network supports IPv6, WebRTC will receive 2 ICE candidates: one with the IPv4 address and the other with the IPv6 address.

The Leak

Because Safari doesn’t proxy STUN requests through iCloud Private Relay, STUN servers know your real IP address. This isn’t an issue on its own, as they have no other information; however, Safari passes ICE candidates containing real IP addresses to the JavaScript environment. De-anonymizing you then becomes a matter of parsing your real IP address from the ICE candidates — something easily accomplished with a web application.

So, in order to get real IP addresses, you need to create a peer connection object with a STUN server, collect the ICE candidates, and parse the values. This method requires no user permissions and works on both HTTP and HTTPS pages. Additionally, it’s fast (the time it takes for a couple of parallel network requests) and leaves no traces in browser development tools.

First, create a peer connection object with at least one STUN server. We’ll use Google's server because it’s widely referenced in examples across the internet.

js
const peerConnection = new RTCPeerConnection({
  iceServers: [{
    urls: 'stun:stun.l.google.com:19302'
  }]
})

Subscribe to the icecandidate event to receive ICE candidates. There will be STUN candidates and candidates of other types, so you need to filter the STUN candidates and parse their IP addresses.

const ips = []

function isSTUNCandidate(candidate) {
  return candidate.includes(' typ srflx ')
}

function parseIP(candidate) {
  return candidate.split(' ', 5)[4]
}

peerConnection.onicecandidate = event => {
  if (event.candidate) {
    const candidateString = event.candidate.candidate
    if (isSTUNCandidate(candidateString)) {
      ips.push(parseIP(candidateString))
    }
  } else {
    // There will be no other ICE candidates
    // Print the result
    console.log('IPs', ips)
  }
}

Finally, create a data channel and an offer to make WebRTC start collecting ICE candidates.

peerConnection.createDataChannel('')

peerConnection.createOffer().then(description => {
  peerConnection.setLocalDescription(description)
})

The process will complete when you receive an icecandidate event with null candidate. The ips array will contain your real IPs (IPv4 and IPv6 depending on your network connection). For the complete code, please visit our GitHub repository.

How to protect yourself from the leak

Using a real VPN instead of iCloud Private Relay will proxy all your network traffic—including STUN requests and other browser traffic—so that no one except you and the VPN provider can see your real IP address. A myriad of VPN apps are available in the App Store.

Disabling JavaScript in your Safari’s browser settings will turn off WebRTC and provide protection from this leak. However, many websites require Javascript to function properly.

To fix this vulnerability, Apple will need to modify Safari so it routes all traffic through iCloud Private Relay. The FingerprintJS Team has already reported this issue to them.

Get in touch

Try our open source browser fingerprinting library
Try FingerprintJS Pro, which combines browser fingerprinting with additional identification techniques and machine learning for 99.5% accuracy. It’s free for 10 days with unlimited API calls.
Join our team to work on exciting research in online privacy and cybersecurity: work@fingerprintjs.com

How ad blockers can be used for browser fingerprinting

Savannah Copland 👋 — Thu, 01 Jul 2021 21:03:44 +0000

In this article, we show how signals generated by the use of an ad blocker can improve browser fingerprinting accuracy. This novel browser fingerprinting method, while oft-discussed as a theoretical source of entropy, has only just been added to FingerprintJS as of April 2021, and has never been fully described until now. Ad blockers are an incredibly pervasive and useful piece of technology. Around 26% of Americans use an ad blocker today. If you are reading this article on ad blocker technology, you almost undoubtedly have one installed.

While ad blockers make the internet a more pleasant experience for many people, whether or not they protect your privacy in any meaningful way is up for debate. As ad blockers have access to the content of all pages that a browser loads and can reliably perform cross-site tracking, they are able to collect more information on a user’s browsing activity than most marketing trackers they block.

Perhaps more insidiously, the fact that a user is attempting to avoid being tracked online with an ad blocker can be used to identify them. Consider the example of tracking an individual in the woods by their shoe print. You may find success if you know their shoe’s size and ridge pattern, but it may be just as easy if you know that person habitually covers their tracks by raking a branch over their path. Whether you are looking for a shoe print or the absence of one, a signature pattern can be found.

Ad blockers leave a trace that can be harnessed by the websites you visit to identify you. By testing whether certain page elements are blocked, a site can find discrepancies in the filters used by your specific ad blocker(s). These discrepancies provide a source of entropy that when combined with other unique signals, can identify a specific user over multiple visits. This combining of browser signals to create a unique identifier is known as browser fingerprinting.

While browser fingerprinting is a proven-out method of visitor identification (you can read more about how it works in our beginner’s guide), how ad blockers can be used for fingerprinting is rarely discussed. As the developers of the largest open source browser fingerprinting library, we have only started including ad blocker signals as of April 2021, so this work is hot off the press from our team. We hope shining a light on this cutting edge technique will be useful to the open source community at large.

What is an ad blocker

An ad blocker is a browser extension that prevents browsers from loading video and displaying advertisements, pop-ups, tracking pixels and other third-party scripts.

Ad blockers not only improve the online experience by hiding ads, but also protect browsing activity from being tracked by third-party scripts. All major online ad platforms (like Google and Facebook), as well as other marketing and product testing tools (like Crazy Egg and Hotjar) use tracking scripts to monitor and monetize user activity online. Privacy conscious users often turn to ad blockers to stop their browsing history from being shared with these platforms.

However, ad blockers have access to the content of all pages that a browser loads. They have a lot more information about browsing activity than trackers, because trackers can’t do reliable cross-site tracking. Therefore, it is possible for ad blockers to violate user privacy.
Safari is an exception which we’ll discuss below.

How ad blockers work

In this section we’ll go fairly deep into the internals of ad blockers as it will help us build a better understanding of how ad blocking mechanics make it possible to reliably identify visitors.

Ad blockers typically run as extensions built on top of browser APIs:

Google Chrome and other Chromium-based browsers: Extensions are JavaScript applications that run in a sandboxed environment with additional browser APIs available only to browser extensions. There are two ways ad blockers can block content. The first one is element hiding and the second one is resource blocking:
Element hiding is done either by injecting CSS code, or by using DOM APIs such as querySelectorAll or removeChild.
Resource blocking employs a different technique. Instead of rendering elements on a page and then hiding them, extensions block the resources on a browser networking level. To plug into browser networking, ad blockers will intercept requests as they happen or use declarative blocking rules defined beforehand. Request interception utilizes webRequest API, which is the most privacy violating technique. It works by reading every request that a browser is making and deciding on the fly if it represents an ad and should be blocked. The declarative approach utilizes declarativeNetRequest API to preemptively instruct browsers what needs to be blocked. This happens without reading actual requests, thus providing more privacy.
Firefox: This API is almost the same as in Google Chrome. The only notable difference is the lack of declarativeNetRequest API.
Safari: Unlike Chrome or Firefox, Safari extensions are native applications. Safari provides a declarative API for ad blockers. Ad blockers create static lists of things that describe what to block, and pass them to Safari. A list will contain rules that tell what network requests, HTML elements or cookies to block. A list content may also depend on user settings. Ad blockers have no way of accessing browsing history in Safari. You can watch a video by Apple with a detailed explanation.

Android browsers are a special case, in that they generally lack extension APIs. However, Android Play Market allows you to install ad-blocking apps that will work in all browsers. These apps will create a VPN on the system level and pass all the device traffic through it. The VPN connection will act as an ad blocker by adding JavaScript code or CSS styles to pages that will hide unwanted content, or by blocking HTTP requests entirely.

Ad blocking filters

Ad blockers prevent ads from being shown by looking for specific elements to block within the site’s contents. To identify these advertising elements, ad blockers use collections of rules called "filters" to decide what to block.

Usually these filters are maintained by the open source community. Like any other project, filters are created by different people for different needs. For example, French websites often use local ad systems that are not known worldwide and are not blocked by general ad filters, so developers in France will want to create a filter to block ads on French websites. Some filter maintainers can have privacy concerns and thus create filters that block trackers.

A filter is usually a text file that follows a common standard called "AdBlock Plus syntax". Each line of text contains a blocking rule, which tells an ad blocker which URLs or CSS selectors must be blocked. Each blocking rule can have additional parameters such as the domain name or the resource type.

A blocking rule example is shown below:

The most common sets of filters used by AdBlock, AdGuard and other ad blockers include:

EasyList: includes EasyList, EasyPrivacy, EasyList Cookie List, EasyList Germany and many others.
AdGuard: includes a base filter, a mobile ads filter, a tracking protection filter, a social media filter and many others.
Fanboy: includes Enhanced Trackers List, Anti-Facebook Filters, Annoyance List and several others.

How to get entropy from ad blockers

Our goal is to get as much information from ad blockers as possible to generate a fingerprint.

A JS script running on a page can't tell directly if the browser has an ad blocker, and if it does, what is blocked by it. Instead, the script can try adding something on the page to see if it gets blocked. The addition can be an HTML element that matches a blocked CSS selector or an external resource such as a script or an image.

We recommend using CSS selectors over resources to detect ad blockers, as resource detection has two significant downsides. Firstly, detecting whether a resource is blocked requires trying to download the resource by making an HTTPS request and watching its state. This process slows down the web page by occupying the network bandwidth and CPU. Secondly, the HTTPS requests will appear in the browser developer tools, which may look suspicious to an observant site visitor. For these reasons, we will focus on using CSS selectors to collect data in this article.

We will now run through how to generate two related data sources using ad blocker signals: the list of blocked CSS selectors, and the list of filters. Finding the list of filters will result in a significantly more stable fingerprint, but requires additional work to identify unique CSS selectors to distinguish each filter from one another.

Data source 1: detecting the list of blocked CSS selectors

The process of detecting whether a CSS selector is blocked consists of the following steps:

Parse the selector, i.e. get the tag name, CSS classes, id and attributes from it;
Create an empty HTML element that matches that selector and insert the element into the document;
Wait for the element to be hidden by an ad blocker, if one is installed;
Check whether it's hidden. One way to do it is checking the element's offsetParent property (it's null when the element is hidden).

If you do the above steps for each selector, you'll face a performance issue, because there will be a lot of selectors to check. To avoid slowing down your web page, you should create all the HTML elements first and then check them to determine if they are hidden.

This approach can generate false positives when there are a lot of HTML elements added to the page. It happens because some CSS selectors apply only when an element has certain siblings. Such selectors contain a general sibling combinator (~) or an adjacent sibling combinator (+). They can lead to false element hiding and therefore false blocked selector detection results. This problem can be mitigated by inserting every element into an individual < div> container so that each element has no siblings. This solution may still fail occasionally, but it reduces the false positives significantly.

Here is an example code that checks which selectors are blocked:

async function getBlockedSelectors(allSelectors) {
  // A storage for the test elements
  const elements = new Array(allSelectors.length)

  const blockedSelectors = []

  try {
    // First create all elements that can be blocked
    for (let i = 0; i < allSelectors.length; ++i) {
      const container = document.createElement('div')
      const element = selectorToElement(allSelectors[i])
      elements[i] = element
      container.appendChild(element)
      document.body.appendChild(container)
    }

    // Then wait for the ad blocker to hide the element
    await new Promise(resolve => setTimeout(resolve, 10))

    // Then check which of the elements are blocked
    for (let i = 0; i < allSelectors.length; ++i) {
      if (!elements[i].offsetParent) {
        blockedSelectors.push(allSelectors[i])
      }
    }
  } finally {
    // Then remove the elements
    for (const element of elements) {
      if (element) {
        element.parentNode.remove()
      }
    }
  }

  return blockedSelectors
}

// Creates a DOM element that matches the given selector
function selectorToElement(selector) {
  // See the implementation at https://bit.ly/3yg1zhX
}

getBlockedSelectors(['.advertisement', 'img[alt="Promo"]'])
  .then(blockedSelectors => {
    console.log(blockedSelectors)
  })

To determine which CSS selectors to check, you can download some of the most popular filters and extract the CSS selectors that are blocked on all websites. The rules for such selectors start with ##.

Your chosen selectors should contain no < embed>, no fixed positioning, no pseudo classes and no combinators. The offsetParent check will not work with either < embed> or fixed positioning. Selectors with combinators require a sophisticated script for building test HTML elements, and since there are only a few selectors with combinators, it isn't worth writing such a script. Finally, you should test only unique selectors across all the filters to avoid duplicate work. You can see a script that we use to parse the unique selectors from the filters here.

You can see some of the selectors blocked by your browser in the interactive demo on our blog.

This is just an image - check out the full interactive demo on our site!

Data source 2: getting the list of ad blocking filters

A better way to get identification entropy from ad blockers is detecting which filters an ad blocker uses. This is done by identifying unique CSS selectors for each filter, so that if a unique selector is blocked, you can be sure a visitor is using that filter.

The process consists of the following steps:

Identify which selectors are blocked by each filter. This step will be done once as a preparation step.
Get unique selectors by filter. This step will also be done once as a preparation step.
Check whether each unique selector is blocked. This step will run in the browser every time you need to identify a visitor.

These three steps are explained in more detail below.

Identify which selectors are blocked by each filter

To get the selectors blocked by a filter we can’t just read them from the filter file. This approach will not work in practice because ad blockers can hide elements differently from filter rules. So, to get a true list of CSS selectors blocked by a filter, we need to use a real ad blocker.

The process of detecting which selectors a filter really blocks is described next:

Make an HTML page that checks every selector from the filters you want to detect. The page should use the process described in the previous section (detecting the list of blocked CSS selectors). You can use a Node.js script that makes such an HTML page. This step will be done once as a preparation step.
Go to the ad blocker settings and enable only the filter we’re testing;
Go to the HTML page and reload it;
Save the list of blocked selectors to a new file.

Repeat the steps for each of the filters. You will get a collection of files (one for each filter).

Some filters will have no selectors, we won’t be able to detect them.

Get unique selectors by filter

Now, when you have selectors that are really blocked by each of the filters, we can narrow them down to the unique ones. A unique selector is a selector that is blocked by only one filter. We created a script that extracts unique selectors. The script output is a JSON file that contains unique blocked selectors for each of the filters.

Unfortunately, some of the filters have no unique blocked selectors. They are fully included into other filters. That is, all their rules are presented in other filters, thus making these rules not unique.

You can see how we handle such filters in our GitHub repository.

Identify blocked selectors by filter

This part will run in the browser. In a perfect world we would only need to check whether a single selector from each of the filters is blocked. When a unique selector is blocked, you can be sure that the person uses the filter. Likewise, if a unique selector isn't blocked, you can be sure the person doesn't use the filter.

const uniqueSelectorsOfFilters = {
  easyList: '[lazy-ad="leftthin_banner"]',
  fanboyAnnoyances: '#feedback-tab'
}

async function getActiveFilters(uniqueSelectors) {
  const selectorArray = Object.values(uniqueSelectors)

  // See the snippet above
  const blockedSelectors = new Set(
    await getBlockedSelectors(selectorArray)
  )

  return Object.keys(uniqueSelectors)
    .filter(filterName => {
      const selector = uniqueSelectors[filterName]
      return blockedSelectors.has(selector)
    })
}

getActiveFilters(uniqueSelectorsOfFilters)
  .then(activeFilters => {
    console.log(activeFilters)
  })

In practice, the result may sometimes be incorrect because of wrong detection of blocked selectors. It can happen for several reasons: ad blockers can update their filters, they can experience glitches, or page CSS can interfere with the process.

In order to mitigate the impact of unexpected behavior, we can use fuzzy logic. For example, if more than 50% of unique selectors associated with one filter are blocked, we will assume the filter is enabled. An example code that checks which of the given filters are enabled using a fuzzy logic:

const uniqueSelectorsOfFilters = {
  easyList: ['[lazy-ad="leftthin_banner"]', '#ad_300x250_2'],
  fanboyAnnoyances: ['#feedback-tab', '#taboola-below-article']
}

async function getActiveFilters(uniqueSelectors) {
  // Collect all the selectors into a plain array
  const allSelectors = [].concat(
    ...Object.values(uniqueSelectors)
  )

  const blockedSelectors = new Set(
    await getBlockedSelectors(allSelectors)
  )

  return Object.keys(uniqueSelectors)
    .filter(filterName => {
      const selectors = uniqueSelectors[filterName]
      let blockedSelectorCount = 0

      for (const selector of selectors) {
        if (blockedSelectors.has(selector)) {
          ++blockedSelectorCount
        }
      }

      return blockedSelectorCount > selectors.length * 0.5
    })
}

getActiveFilters(uniqueSelectorsOfFilters)
  .then(activeFilters => {
    console.log(activeFilters)
  })

Ad blocker fingerprinting

Once you collect enough data, you can generate a visitor fingerprint.

Browser fingerprinting is a technique that works by reading browser attributes and combining them together into a single identifier. This identifier is stateless and works well in normal and incognito modes.

There are dozens of ad blockers available. For example, AdBlock, uBlock Origin, AdGuard, 1Blocker X. These ad blockers use different sets of filters by default. Also users can customize ad blocking extensions by removing default filters and adding custom filters. This diversity gives entropy that can be used to generate fingerprints and identify visitors.

An example of an ad blocker customization:

A good browser fingerprint should stay the same when a user goes from regular to incognito (private) mode of the browser. Thus, ad blockers can provide a useful source of entropy only for browsers and operating systems where ad blockers are enabled by default in incognito mode:

Safari on MacOS, iOS, iPadOS: browser extensions are enabled (including ad blockers) in both regular and incognito mode.
All Browsers on Android: Ad blockers work on the system level, so they affect all browser modes.

Desktop Chrome and Firefox:
Extensions are disabled by default in incognito mode. Users however can manually choose to keep extensions enabled in incognito mode, but few people do so. Since we cannot know if a user has an ad blocker enabled in incognito mode, it makes sense to identify visitors by their ad blockers only in Safari and on Android.

You can make a fingerprint solely from the information that we’ve gotten from the visitor's ad blocker either by using the list of blocked selectors, or the list of filters from the sections above.

Using Selectors

To make a fingerprint using selectors only, we take a list of selectors, check which of them are blocked and hash the result:

// See the snippet above
getBlockedSelectors(...)
  .then(blockedSelectors => {
    // See the murmurHash3 implementation at
    // https://github.com/karanlyons/murmurHash3.js
    const fingerprint = murmurHash3.x86.hash128(
      JSON.stringify(blockedSelectors)
    )

    console.log(fingerprint)
  })

This fingerprint is very sensitive but not stable. The CSS code of the page can accidentally hide a test HTML element and thus change the result. Also, as the community updates the filters quite often, every small update can add or remove a CSS selector rule, which will change the whole fingerprint. So, a fingerprint based on selectors alone can only be used for short-term identification.

Using Filter Lists

To mitigate the instability of CSS selectors alone, you can use the list of filters instead to generate a fingerprint. The list of filters that a person uses is only likely to change if they switch ad blockers, or if their installed ad blocker undergoes a significant update. To make a fingerprint, get the list of enabled filters and hash it:

// See the snippet above
getActiveFilters(...).then(activeFilters => {
  // See the murmurHash3 implementation at
  // https://github.com/karanlyons/murmurHash3.js
  const fingerprint = murmurHash3.x86.hash128(
    JSON.stringify(activeFilters)
  )

  console.log(fingerprint)
})

This is just an image - check out the full interactive demo on our site!

As we mentioned above, the filter lists themselves are updated frequently. The updates can make the fingerprint change. The fuzzy algorithm mitigates this problem, but the underlying selectors will need to be updated eventually. So, you will need to repeat the process of collecting unique selectors after some time to actualize the data and keep the fingerprinting accuracy high.

Performance

The browser main thread is where it processes user events and paints. By default, browsers use a single thread to run all the JavaScript in the page, and to perform layout, reflows, and garbage collection. This means that long-running JavaScript can block the thread, leading to an unresponsive page and bad user experience.

The process of checking CSS selectors runs on the main thread. The algorithm uses many DOM operations, such as createElement and offsetParent. These operations can run only on the main thread and can't be moved to a worker. So, it's important for the algorithm to run fast.

We've measured the time it takes several old devices to check different numbers of CSS selectors per filter. We test only in the browsers where it makes sense to identify visitors by ad blockers. The tests were conducted in cold browsers on a complex page (about 500 KB of uncompressed CSS code). The results:

	MacBook Pro 2015 (Core i7), macOS 11, Safari 14	iPhone SE1, iOS 13, Safari 13	Pixel 2, Android 9, Chrome 89
1 selector per filter (45 in total)	3.1ms	10ms	5.7ms
At most 5 selectors per filter (210 in total)	9ms	27ms	17ms
At most 10 selectors per filter (401 in total	20ms	20ms	36ms
All selectors (23029 in total)	≈7000ms	≈19000ms	≈2600ms

The more CSS selectors the algorithm checks, the more accurate the result will be. But a large number of CSS selectors increases the execution time and the code size. We have chosen to check 5 selectors per filter as a good balance between performance, stability and the code size.

You can see a complete implementation of the described algorithm in our GitHub repository.

Brave and Tor

Brave is a browser based on Chromium. It disables extensions in incognito mode by default. Thus, we don't perform ad blocker fingerprinting in Brave.

Desktop Tor has no separate incognito mode, so every extension works in all Tor tabs. Ad blockers can be used to identify Tor users. But the Tor authors strongly recommend not to install any custom extensions, and it's not easy to do so. Very few people will install ad blockers in Tor. So the effectiveness of ad blocker fingerprinting is low.

Closing thoughts

Ad blocker fingerprinting is only a small part of the larger identification process

Ad blocker fingerprinting is one of the many signals our open source library uses to generate a browser fingerprint. However, we do not blindly incorporate every signal available in the browser. Instead we analyze the stability and uniqueness of each signal separately to determine their impact on fingerprint accuracy.

Ad blocker detection is a new signal and we’re still evaluating its properties.

You can learn more about stability, uniqueness and accuracy in our beginner’s guide to browser fingerprinting.

Try Browser Fingerprinting for Yourself

Browser fingerprinting is a useful method of visitor identification for a variety of anti-fraud applications. It is particularly useful to identify malicious visitors attempting to circumvent tracking by clearing cookies, browsing in incognito mode or using a VPN.

You can try implementing browser fingerprinting yourself with our open source library. FingerprintJS is the most popular browser fingerprinting library available, with over 14K GitHub stars.

For higher identification accuracy, we also developed the FingerprintJS Pro API, which uses machine learning to combine browser fingerprinting with additional identification techniques. You can use FingerprintJS Pro for free with up to 20k API calls per month.

Get in touch

Star, follow or fork our GitHub project
Email us your questions at oss@fingerprintJS.com
Sign up to our newsletter for updates
Join our team to work on exciting research in online security: work@fingerprintjs.com

Have Recent Browser Privacy Updates Stopped Browser Fingerprinting? An Analysis

Savannah Copland 👋 — Tue, 25 May 2021 21:20:20 +0000

The trend in web browsers over the past few years has generally been in favor of more privacy for users. Almost all mainstream browsers (Safari, Firefox, Brave, and Chrome) now block third-party cookies which enabled tracking across multiple sites, and Chrome uses encrypted traffic (via HTTPS) by default.

Similarly, regulations like GDPR and CCPA are adding legal hurdles for companies that want to gather user data online. Cookie consent boxes are now ubiquitous (despite the fact that they're rarely implemented correctly), and companies in many jurisdictions are now responsible for allowing users the right to be forgotten.

More privacy is generally a good thing for legitimate users. It means fewer opportunities for their personal data to be stolen, it can decrease the risk of identity theft, and it gives them more control over how their data can be used.

But, increased browser privacy also comes with a hidden cost. By preventing cookies and other tracking mechanisms, it's very hard for web application developers to figure out whether a visitor is a real user or a fraudulent bot. This leads developers to rely heavily on multi-factor authentication methods, which slow down and frustrate users. It also increases the cost of building and maintaining applications - costs likely passed on to users in one form or another.

There is another way to identify users without intrusive cookies. In this article, I'll share a technique called browser fingerprinting and discuss how it can be used to prevent fraud in modern browsers. I'll also share an overview of the privacy settings that impact fingerprinting in each of the three major web browsers (Chrome, Safari, and Firefox). Finally, I'll share how fingerprinting must continue to evolve as privacy measures do.

How Browser Fingerprinting Works

Browser fingerprinting can be used to uniquely identify users and their associate sessions regardless of anonymizing tactics like incognito browsing, VPNs, and cookie blockers. Unlike third-party cookies, which can be cleared or blocked by the browser, your browser fingerprint cannot be altered.

Fingerprinting can be used to identify visitors with a pattern of fraudulent behavior and then target only these visitors for additional security checks. This means you won't slow down legitimate users who want to access your site, but you will be able to identify those who are trying to brute force access or circumvent your security measures.

Understanding Fraudulent Users

Most fraudsters use identity concealing techniques like incognito mode or VPNs (virtual private networks) to hide their identity. This allows them to try multiple passwords, stolen credit cards, or email addresses in your app in an attempt to gain access to restricted data or make an illegitimate purchase.

Fingerprinting takes in data from the browser to help build a unique profile for each user on your site. By capturing the following specifics, fingerprinting software can identify suspicious traffic without an IP address or cookie:

Computer make and model
Operating system version
Browser version
Browser extensions
Timezone
Language settings
Adblocker used
Screen size and resolution
Tech specs (CPU, GPU, hard disk, etc.)

This method is surprisingly accurate when done well. FingerprintJS is 99.5% accurate at identifying users and assigning them a unique visitorID. Using this ID, you can associate patterns of fraud with specific visitors and block them as needed.

Privacy in the Modern Browser

As you might imagine, browser fingerprinting has had to evolve as browsers have evolved. In the past few decades, the laws and standards around online privacy, as well as the tactics available to web developers have changed a lot.

For example, cookies on their own have always been relatively easy to bypass. Because they're stored on the user's browser, they can be easily cleared manually or programmatically, so they don't provide a useful mechanism for identifying malicious users.

Other browser features are much harder to bypass. Since the introduction of WebGL in the 2010s, web applications can draw a Canvas element onto the DOM. This uses the computer's graphics card to render an image that can be converted to a unique identifier for a user. Of course, browser extensions can block this method, so it's rarely used alone but as part of a comprehensive fingerprinting method.

This continued arms race between companies that rely on tracking to prevent fraud and malicious users has led to a number of new features that affect fingerprinting in modern browsers. With extensions and native features in all of the top three browsers that can block or bypass some part of the fingerprinting process, let's look at some of the privacy settings that impact fingerprinting.

Browser Fingerprinting in Chrome

Chrome is currently the most popular browser, with a 64.19% market share.

Despite Google’s spotty record of offering privacy to users, the Chrome browser does provide options that make tracking harder. First, users can block third-party cookies or all cookies or manually clear their cookies each time they close their browser.

While cookies may not be critical in most fingerprinting algorithms, Chrome is also currently running a trial of Google’s Privacy Sandbox. This feature attempts to prevent fingerprinting by hiding your hardware and software information from websites. It’s not clear when these features will be on for all Chrome users, but that seems to be the direction Google is heading.

Chrome also offers users the option to block access to operating system services or make websites ask before accessing them. Many of these services can be used to help fingerprint users if they’re enabled. Users can also turn off JavaScript completely, but this likely isn’t practical for real users as most websites rely on JavaScript to function.

Chrome users can also use extensions to block fingerprints, obscure their IP addresses, and more. Each of these extensions limits tracking in its own way (for example, the Canvas Fingerprint Detector blocks the HTML Canvas fingerprint method described above).

Of course, no browser's privacy protections are perfect, and researchers are constantly finding new ways to track users in Chrome. For example, according to a 2020 paper by computer scientist Doug Leith, Chrome sends a "persistent identifier" as a header on each web request (presumably for debugging) that can be used as part of a browser fingerprint. It’s almost impossible for malicious users to completely avoid detection if fingerprinters are willing to stay up-to-date on the latest changes, but keeping up with these changes is a huge undertaking.

Safari Browser Fingerprinting

As the second most popular web browser, Safari is slightly more private by default than Chrome. Safari uses Intelligent Tracking Prevention to determine the sites tracking a user and blocks them if a user hasn't visited them for thirty days. Safari now blocks a number of tracking technologies, including some attempts at fingerprinting, without making any concessions for fraud prevention.

Like Chrome, Safari lets users disable JavaScript and block cookies. It also shows a privacy report right on the welcome page. Users can disable location services and autofill to prevent those features from being used in fingerprinting.

Finally, Safari users can make fingerprinting even harder with extensions like Better or a VPN to obscure their IP address, location, and other device-specific data.

Still, there are some weak spots in Safari’s pro-privacy measures. Researcher Doug Leith found that the Safari welcome page can actually leak information to third party apps that can then load user identifiers into the browser cache. It’s also possible that Apple’s iCloud processes make connections with identifying user information (likely for debugging purposes). Either of these data points could be part of a browser fingerprint, depending on how the data is distributed.

Browser Fingerprinting in Firefox

Firefox has been outspoken about user privacy in recent years. Users are presented with the company’s privacy statement upon opening the browser for the first time, and fingerprint controls are turned on by default.

This layer of fingerprinting protection built directly into the browser prevents sites from reading:

Your timezone
Your installed fonts
Window size preference
Operating system version
Keyboard layout and language
Site-specific zoom settings
And more

As in Chrome, Firefox users can change the permissions given to each website they visit, or they can block system resource requests entirely from the Permissions menu.

Finally, there are thousands of Firefox extensions that give users more fine-grained control over their privacy. Users can also install the AmIUnique addon to see how unique their browser is among the millions of fingerprints collected by AmIUnique. This knowledge can be used by malicious users to tweak their settings further to obscure their identity.

Even with some pretty strict fingerprinting protections in place, Doug Leith found shortcomings in Firefox’s privacy configuration too. For example, Firefox transmits identifying information during telemetry data reporting which is on by default.

The Ever-Changing World of Browser Fingerprinting

I’ve covered some of the features that browsers offer to users who want to protect their privacy online, but the specifics are constantly changing.

Browsers need to add new features to enable more complex behavior online, but these new features can often be used to build fingerprints to identify users by their hardware or software. So, the browsers make these features gated or harder to access, but this makes certain websites harder to use.

Despite the resistance to fingerprinting in some circles, it’s a legitimate and useful tool for preventing fraud and improving online security. With an ever-escalating race between malicious users and fingerprinters, it can be really hard for development teams to keep up with all the changes.

For example, Firefox just released an update that prevents sites from reading other open windows' names. If you were maintaining your own fingerprinting software that used open windows as part of your identifying data, you have to decide how to compensate for this change, or your fingerprint will get obsolete quickly.

This is where tools like FingerprintJS come in. As experts in the fingerprinting space, they provide developers with 99.5% accurate browser fingerprinting and offer a free, open-source library as well as paid services. FingerprintJS doesn’t rely on outdated third-party tracking mechanisms, and it helps you prevent account takeovers, password sharing, and fake accounts.

Modern browsers are doing a good job of improving privacy protections, but this trend comes with a cost to web application owners. Fortunately, fingerprinting is still an accurate and low-cost way to prevent fraud even now. Just don't roll your own.

Vulnerability allows cross-browser tracking in Chrome, Firefox, Safari, and Tor

Savannah Copland 👋 — Thu, 13 May 2021 19:28:40 +0000

In this article we introduce a scheme flooding vulnerability, explain how the exploit works across four major desktop browsers and show why it's a threat to anonymous browsing.

DISCLAIMER: FingerprintJS does not use this vulnerability in our products and does not provide third-party tracking services. We focus on stopping fraud and support modern privacy trends for removing third-party tracking entirely. We believe that vulnerabilities like this one should be discussed in the open to help browsers fix them as quickly as possible. To help fix it, we have submitted bug reports to all affected browsers, created a live demo and have made a public source code repository available to all.

Test the vulnerability on our live demo site. Works on desktop browsers only.

In our research into anti-fraud techniques, we have discovered a vulnerability that allows websites to identify users reliably across different desktop browsers and link their identities together. The desktop versions of Tor Browser, Safari, Chrome, and Firefox are all affected.

We will be referring to this vulnerability as scheme flooding, as it uses custom URL schemes as an attack vector. The vulnerability uses information about installed apps on your computer in order to assign you a permanent unique identifier even if you switch browsers, use incognito mode, or use a VPN.

Why does this matter?

The scheme flooding vulnerability allows for third party tracking across different browsers and thus is a violation of privacy.

No cross-browser anonymity

Cross-browser anonymity is something that even a privacy conscious internet user may take for granted. Tor Browser is known to offer the ultimate in privacy protection, though due to its slow connection speed and performance issues on some websites, users may rely on less anonymous browsers for their every day surfing. They may use Safari, Firefox or Chrome for some sites, and Tor for sites where they want to stay anonymous. A website exploiting the scheme flooding vulnerability could create a stable and unique identifier that can link those browsing identities together.

Even if you are not a Tor Browser user, all major browsers are affected. It’s possible to link your Safari visit to your Chrome visit, identify you uniquely and track you across the web.

Profiling based on installed apps

Additionally, the scheme flood vulnerability allows for targeted advertisement and user profiling without user consent. The list of installed applications on your device can reveal a lot about your occupation, habits, and age. For example, if a Python IDE or a PostgreSQL server is installed on your computer, you are very likely to be a backend developer.

Depending on the apps installed on a device, it may be possible for a website to identify individuals for more sinister purposes. For example, a site may be able to detect a government or military official on the internet based on their installed apps and associate browsing history that is intended to be anonymous.

Unknown impact on the web

This vulnerability has been possible for more than 5 years and its true impact is unknown. In a quick search of the web, we couldn’t find any website actively exploiting it but we still felt the need to report it as soon as possible.

How does it work? (technical overview)

Note: You may skip this section if you are not interested in the technical implementation details. The source code of the demo application is available on GitHub.

The scheme flooding vulnerability allows an attacker to determine which applications you have installed. In order to generate a 32-bit cross-browser device identifier, a website can test a list of 32 popular applications and check if each is installed or not. On average, the identification process takes a few seconds and works across desktop Windows, Mac and Linux operating systems.

To check if an application is installed, browsers can use built-in custom URL scheme handlers. You can see this feature in action by entering skype:// in your browser address bar. If you have Skype installed, your browser will open a confirmation dialog that asks if you want to launch it. This feature is also known as deep linking and is widely used on mobile devices, but is available within desktop browsers as well. Any application that you install can register its own scheme to allow other apps to open it.

In order to detect if an application is installed, we can test an application's custom URL scheme and then check if a popup has been shown.

To make this vulnerability possible, the following steps are required:

Prepare a list of application URL schemes that you want to test. The list may depend on your goals, for example, if you want to check if some industry or interest-specific applications are installed.
Add a script on a website that will test each application from your list. The script will return an ordered array of boolean values. Each boolean value is true if the application is installed or false if it is not.
Use this array to generate a permanent cross-browser identifier.
Optionally, use machine learning algorithms to guess your website visitors’ occupation, interests, and age using installed application data.

The steps above may sound easy, but most browsers have safety mechanisms in place designed to prevent such exploits. Weaknesses in these safety mechanisms are what makes this vulnerability possible. A combination of CORS policies and browser window features can be used to bypass it.

The actual implementation of the exploit varies by browser, however the basic concept is the same. It works by asking the browser to show a confirmation dialog in a popup window. Then the JavaScript code can detect if a popup has just been opened and detect the presence of an application based on that.

Let’s walk through some of the browser differences.

Chrome

Of the four major browsers impacted, only Chrome developers appear to be aware of the scheme flooding vulnerability. The issue has been discussed on the Chromium bug-tracker and is planned to be fixed soon.

Additionally, only the Chrome browser had any form of scheme flood protection which presented a challenge to bypass. It prevents launching any application unless requested by a user gesture, like a mouse click. There is a global flag that allows (or denies) websites to open applications, which is set to false after handling a custom URL scheme.

However, you can use Chrome extensions to reset this flag and bypass the scheme flood protection. By specification, extensions need to be able to open custom URLs, such as mailto: links, without confirmation dialogs. The scheme flood protection conflicts with extension policies so there is a loophole that resets this flag every time any extension is triggered.

The built-in Chrome PDF Viewer is an extension, so every time your browser opens a PDF file it resets the scheme flood protection flag. Opening a PDF file before opening a custom URL makes the exploit functional.

Firefox

Every time you navigate to an unknown URL scheme, Firefox will show you an internal page with an error. This internal page has a different origin than any other website, so it is impossible to access it because of the Same-origin policy limitation. On the other hand, a known custom URL scheme will be opened as about:blank, whose origin will be accessible from the current website.

By opening a popup window with a custom URL scheme and checking if its document is available from JavaScript code, you can detect if the application is installed on the device.

Safari

Despite privacy being a main development focus for the Safari browser, it turned out to be the easiest browser of the four to exploit. Safari doesn’t have scheme flood protection and allows to easily enumerate all installed applications.

The same-origin policy trick as used for the Firefox browser was used here as well.

Tor Browser

Tor Browser has confirmation dialogs disabled entirely as a privacy feature, which, ironically, exposed a more damaging vulnerability for this particular exploit. Nothing is shown while the exploit runs in the background, contrasting with other browsers that show pop-ups during the process. This oversight allows the exploit to check through installed applications without users even realizing it.

Tor Browser is based on the Firefox source code, so the Same-origin policy trick was used here as well. But because Tor Browser does not show pop-ups, we used the same-origin policy trick with iframe elements instead.

By creating an iframe element with a custom URL scheme and checking if its document is available you can check if the application is installed or not.

Of the four browsers, the scheme flooding vulnerability takes the longest to successfully run in Tor. It can take up to 10 seconds for each application to be checked due to Tor Browser policies. Still, the exploit can be made to work in the background and track you over a longer browsing session. If you left a Tor Browser window on a web page only for 4 minutes, it could be enough to expose your identity.

It’s possible to remove the 10-second limitation by running each application test inside a user-triggered gesture. A fake captcha is an ideal candidate: 24 characters entered by a user makes it possible to reset that 10-second limitation 24 times in a row and enumerate 24 installed applications instantaneously.

Conclusion

The exact steps to make the scheme flooding vulnerability possible may vary by browser, but the end result is the same. Getting a unique array of bits associated with a visitor’s identity is not only possible, but can be used on malicious websites in practice. Even Tor Browser can be effectively exploited by tricking a user into typing one character per application we want to test.

Until this vulnerability is fixed, the only way to have private browsing sessions not associated with your primary device is to use another device altogether.

By submitting these bug reports, writing this article and building our demo application, we hope that this vulnerability is fixed across all browsers as soon as possible.

Useful links

If you enjoyed reading this article, consider joining our fully remote team to work on exciting research in online security: work@fingerprintjs.com

How the Web Audio API is used for browser fingerprinting

Savannah Copland 👋 — Tue, 23 Mar 2021 01:24:00 +0000

Did you know that you can identify web browsers without using cookies or asking for permissions?

This is known as “browser fingerprinting” and it works by reading browser attributes and combining them together into a single identifier. This identifier is stateless and works well in normal and incognito modes.

When generating a browser identifier, we can read browser attributes directly or use attribute processing techniques first. One of the creative techniques that we’ll discuss today is audio fingerprinting.

Audio fingerprinting is a valuable technique because it is relatively unique and stable. Its uniqueness comes from the internal complexity and sophistication of the Web Audio API. The stability is achieved because the audio source that we’ll use is a sequence of numbers, generated mathematically. Those numbers will later be combined into a single audio fingerprint value.

Before we dive into the technical implementation, we need to understand a few ideas from the Web Audio API and its building blocks.

A brief overview of the Web Audio API

The Web Audio API is a powerful system for handling audio operations. It is designed to work inside an AudioContext by linking together audio nodes and building an audio graph. A single AudioContext can handle multiple types of audio sources that plug into other nodes and form chains of audio processing.

A source can be an audio element, a stream, or an in-memory source generated mathematically with an Oscillator. We’ll be using the Oscillator for our purposes and then connecting it to other nodes for additional processing.

Before we dive into the audio fingerprint implementation details, it’s helpful to review all of the building blocks of the API that we’ll be using.

AudioContext

AudioContext represents an entire chain built from audio nodes linked together. It controls the creation of the nodes and execution of the audio processing. You always start by creating an instance of AudioContext before you do anything else. It’s a good practice to create a single AudioContext instance and reuse it for all future processing.

AudioContext has a destination property that represents the destination of all audio from that context.

There also exists a special type of AudioContext: OfflineAudioContext. The main difference is that it does not render the audio to the device hardware. Instead, it generates the audio as fast as possible and saves it into an AudioBuffer. Thus, the destination of the OfflineAudioContext will be an in-memory data structure, while with a regular AudioContext, the destination will be an audio-rendering device.

When creating an instance of OfflineAudioContext, we pass 3 arguments: the number of channels, the total number of samples and a sample rate in samples per second.

const AudioContext = 
  window.OfflineAudioContext ||
  window.webkitOfflineAudioContext
const context = new AudioContext(1, 5000, 44100)

AudioBuffer

An AudioBuffer represents an audio snippet, stored in memory. It’s designed to hold small snippets. The data is represented internally in Linear PCM with each sample represented by a 32-bit float between -1.0 and 1.0. It can hold multiple channels, but for our purposes we’ll use only one channel.

Oscillator

When working with audio, we always need a source. An oscillator is a good candidate, because it generates samples mathematically, as opposed to playing an audio file. In its simplest form, an oscillator generates a periodic waveform with a specified frequency.

The default shape is a sine wave.

We made a live demo of this! You can play with the real deal on our blog.

It’s also possible to generate other types of waves, such as square, sawtooth, and triangle.

The default frequency is 440 Hz, which is a standard A4 note.

Compressor

The Web Audio API provides a DynamicsCompressorNode, which lowers the volume of the loudest parts of the signal and helps prevent distortion or clipping.

DynamicsCompressorNode has many interesting properties that we’ll use. These properties will help create more variability between browsers.

Threshold - value in decibels above which the compressor will start taking effect.
Knee - value in decibels representing the range above the threshold where the curve smoothly transitions to the compressed portion.
Ratio - amount of input change, in dB, needed for a 1 dB change in the output.
Reduction - float representing the amount of gain reduction currently applied by the compressor to the signal.
Attack - the amount of time, in seconds, required to reduce the gain by 10 dB. This value can be a decimal.
Release - the amount of time, in seconds, required to increase the gain by 10 dB.

We made a live demo of this! You can play with the real deal on our blog.

How the audio fingerprint is calculated

Now that we have all the concepts we need, we can start working on our audio fingerprinting code.

Safari doesn’t support unprefixed OfflineAudioContext, but does support
webkitOfflineAudioContext, so we’ll use this method to make it work in Chrome and Safari:

const AudioContext =
  window.OfflineAudioContext ||
  window.webkitOfflineAudioContex

Now we create an AudioContext instance. We’ll use one channel, a 44,100 sample rate and 5,000 samples total, which will make it about 113 ms long.

const context = new AudioContext(1, 5000, 44100)

Next let’s create a sound source - an oscillator instance. It will generate a triangular-shaped sound wave that will fluctuate 1,000 times per second (1,000 Hz).

const oscillator = context.createOscillator()
oscillator.type = "triangle"
oscillator.frequency.value = 1000

Now let’s create a compressor to add more variety and transform the original signal. Note that the values for all these parameters are arbitrary and are only meant to change the source signal in interesting ways. We could use other values and it would still work.

const compressor = context.createDynamicsCompressor()
compressor.threshold.value = -50
compressor.knee.value = 40
compressor.ratio.value = 12
compressor.reduction.value = 20
compressor.attack.value = 0
compressor.release.value = 0.2

Let’s connect our nodes together: oscillator to compressor, and compressor to the context destination.

oscillator.connect(compressor)
compressor.connect(context.destination);

It is time to generate the audio snippet. We’ll use the oncomplete event to get the result when it’s ready.

oscillator.start()
context.oncomplete = event => {
  // We have only one channel, so we get it by index
  const samples = event.renderedBuffer.getChannelData(0)
};
context.startRendering()

Samples is an array of floating-point values that represents the uncompressed sound. Now we need to calculate a single value from that array.

Let’s do it by simply summing up a slice of the array values:

function calculateHash(samples) {
  let hash = 0
  for (let i = 0; i < samples.length; ++i) {
    hash += Math.abs(samples[i])
  }
  return hash
}

console.log(getHash(samples))

Now we are ready to generate the audio fingerprint. When I run it on Chrome on MacOS I get the value:

101.45647543197447

That’s all there is to it. Our audio fingerprint is this number!

You can check out a production implementation in our open source browser fingerprinting library.

If I try executing the code in Safari, I get a different number:

79.58850509487092

And get another unique result in Firefox:

80.95458510611206

Every browser we have on our testing laptops generate a different value. This value is very stable and remains the same in incognito mode.

This value depends on the underlying hardware and OS, and in your case may be different.

Why the audio fingerprint varies by browser

Let’s take a closer look at why the values are different in different browsers. We’ll examine a single oscillation wave in both Chrome and Firefox.

First, let’s reduce the duration of our audio snippet to 1/2000th of a second, which corresponds to a single wave and examine the values that make up that wave.

We need to change our context duration to 23 samples, which roughly corresponds to a 1/2000th of a second. We’ll also skip the compressor for now and only examine the differences of the unmodified oscillator signal.

const context = new AudioContext(1, 23, 44100)

Here is how a single triangular oscillation looks in both Chrome and Firefox now:

However the underlying values are different between the two browsers (I’m showing only the first 3 values for simplicity):

`Chrome:`	`Firefox:`
`0.08988945186138153`	`0.09155717492103577`
`0.18264609575271606`	`0.18603470921516418`
`0.2712443470954895`	`0.2762767672538757`

Let’s take a look at this demo to visually see those differences.

We made a live demo of this! You can play with the real deal on our blog.

Historically, all major browser engines (Blink, WebKit, and Gecko) based their Web Audio API implementations on code that was originally developed by Google in 2011 and 2012 for the WebKit project.

Examples of Google contributions to the Webkit project include:
creation of OfflineAudioContext,
creation of OscillatorNode, creation of DynamicsCompressorNode.

Since then browser developers have made a lot of small changes. These changes, compounded by the large number of mathematical operations involved, lead to fingerprinting differences. Audio signal processing uses floating point arithmetic, which also contributes to discrepancies in calculations.

You can see how these things are implemented now in the three major browser engines:

Additionally, browsers use different implementations for different CPU architectures and OSes to leverage features like SIMD. For example, Chrome uses a separate fast Fourier transform implementation on macOS (producing a different oscillator signal) and different vector operation implementations on different CPU architectures (which are used in the DynamicsCompressor implementation). These platform-specific changes also contribute to differences in the final audio fingerprint.

Fingerprint results also depend on the Android version (it’s different in Android 9 and 10 on the same devices for example).

According to browser source code, audio processing doesn’t use dedicated audio hardware or OS features—all calculations are done by the CPU.

Pitfalls

When we started to use audio fingerprinting in production, we aimed to achieve good browser compatibility, stability and performance. For high browser compatibility, we also looked at privacy-focused browsers, such as Tor and Brave.

OfflineAudioContext

As you can see on caniuse.com, OfflineAudioContext works almost everywhere. But there are some cases that need special handling.

The first case is iOS 11 or older. It does support OfflineAudioContext, but the rendering only starts if triggered by a user action, for example by a button click. If context.startRendering is not triggered by a user action, the context.state will be suspended and rendering will hang indefinitely unless you add a timeout. There are not many users who still use this iOS version, so we decided to disable audio fingerprinting for them.

The second case are browsers on iOS 12 or newer. They can reject starting audio processing if the page is in the background. Luckily, browsers allow you to resume the processing when the page returns to the foreground.
When the page is activated, we attempt calling context.startRendering() several times until the context.state becomes running. If the processing doesn’t start after several attempts, the code stops. We also use a regular setTimeout on top of our retry strategy in case of an unexpected error or freeze. You can see a code example here.

Tor

In the case of the Tor browser, everything is simple. Web Audio API is disabled there, so audio fingerprinting is not possible.

Brave

With Brave, the situation is more nuanced. Brave is a privacy-focused browser based on Blink. It is known to slightly randomize the audio sample values, which it calls “farbling”.

Farbling is Brave’s term for slightly randomizing the output of semi-identifying browser features, in a way that’s difficult for websites to detect, but doesn’t break benign, user-serving websites. These “farbled” values are deterministically generated using a per-session, per-eTLD+1 seed so that a site will get the exact same value each time it tries to fingerprint within the same session, but that different sites will get different values, and the same site will get different values on the next session. This technique has its roots in prior privacy research, including the PriVaricator (Nikiforakis et al, WWW 2015) and FPRandom (Laperdrix et al, ESSoS 2017) projects.

Brave offers three levels of farbling (users can choose the level they want in settings):

Disabled — no farbling is applied. The fingerprint is the same as in other Blink browsers such as Chrome.
Standard — This is the default value. The audio signal values are multiplied by a fixed number, called the “fudge” factor, that is stable for a given domain within a user session. In practice it means that the audio wave sounds and looks the same, but has tiny variations that make it difficult to use in fingerprinting.
Strict — the sound wave is replaced with a pseudo-random sequence.

The farbling modifies the original Blink AudioBuffer by transforming the original audio values.

Reverting Brave standard farbling

To revert the farbling, we need to obtain the fudge factor first. Then we can get back the original buffer by dividing the farbled values by the fudge factor:

async function getFudgeFactor() {
  const context = new AudioContext(1, 1, 44100)
  const inputBuffer = context.createBuffer(1, 1, 44100)
  inputBuffer.getChannelData(0)[0] = 1

  const inputNode = context.createBufferSource()
  inputNode.buffer = inputBuffer
  inputNode.connect(context.destination)
  inputNode.start()

  // See the renderAudio implementation 
  // at https://git.io/Jmw1j
  const outputBuffer = await renderAudio(context)
  return outputBuffer.getChannelData(0)[0]
}

const [fingerprint, fudgeFactor] = await Promise.all([
  // This function is the fingerprint algorithm described
  // in the “How audio fingerprint is calculated” section
  getFingerprint(),
  getFudgeFactor(),
])
const restoredFingerprint = fingerprint / fudgeFactor

Unfortunately, floating point operations lack the required precision to get the original samples exactly. The table below shows restored audio fingerprint in different cases and shows how close they are to the original values:

OS, browser	Fingerprint	Absolute difference between the target fingerprint
macOS 11, Chrome 89 (the target fingerprint)	124.0434806260746	n/a
macOS 11, Brave 1.21 (same device and OS)	Various fingerprints after browser restarts: 124.04347912294482 124.0434832855703 124.04347889351203 124.04348024313667	0.00000014% – 0.00000214%
Windows 10, Chrome 89	124.04347527516074	0.00000431%
Windows 10, Brave 1.21	Various fingerprints after browser restarts: 124.04347610535537 124.04347187270707 124.04347220244154 124.04347384813703	0.00000364% – 0.00000679%
Android 11, Chrome 89	124.08075528279005	0.03%
Android 9, Chrome 89	124.08074500028306	0.03%
ChromeOS 89	124.04347721464	0.00000275%
macOS 11, Safari 14	35.10893232002854	71.7%
macOS 11, Firefox 86	35.7383295930922	71.2%

As you can see, the restored Brave fingerprints are closer to the original fingerprints than to other browsers’ fingerprints. This means that you can use a fuzzy algorithm to match them. For example, if the difference between a pair of audio fingerprint numbers is more than 0.0000022%, you can assume that these are different devices or browsers.

Performance

Web Audio API rendering

Let’s take a look at what happens under the hood in Chrome during audio fingerprint generation. In the screenshot below, the horizontal axis is time, the rows are execution threads, and the bars are time slices when the browser is busy. You can learn more about the performance panel in this Chrome article. The audio processing starts at 809.6 ms and completes at 814.1 ms:

The main thread, labeled as “Main” on the image, handles user input (mouse movements, clicks, taps, etc) and animation. When the main thread is busy, the page freezes. It’s a good practice to avoid running blocking operations on the main thread for more than several milliseconds.

As you can see on the image above, the browser delegates some work to the OfflineAudioRender thread, freeing the main thread.
Therefore the page stays responsive during most of the audio fingerprint calculation.

Web Audio API is not available in web workers, so we cannot calculate audio fingerprints there.

Performance summary in different browsers

The table below shows the time it takes to get a fingerprint on different browsers and devices. The time is measured immediately after the cold page load.

Device, OS, browser	Time to fingerprint
MacBook Pro 2015 (Core i7), macOS 11, Safari 14	5 ms
MacBook Pro 2015 (Core i7), macOS 11, Chrome 89	7 ms
Acer Chromebook 314, Chrome OS 89	7 ms
Pixel 5, Android 11, Chrome 89	7 ms
iPhone SE1, iOS 13, Safari 13	12 ms
Pixel 1, Android 7.1, Chrome 88	17 ms
Galaxy S4, Android 4.4, Chrome 80	40 ms
MacBook Pro 2015 (Core i7), macOS 11, Firefox 86	50 ms

Audio fingerprinting is only a small part of the larger identification process.

Audio fingerprinting is one of the many signals our open source library uses to generate a browser fingerprint. However, we do not blindly incorporate every signal available in the browser. Instead we analyze the stability and uniqueness of each signal separately to determine their impact on fingerprint accuracy.

For audio fingerprinting, we found that the signal contributes only slightly to uniqueness but is highly stable, resulting in a small net increase to fingerprint accuracy.

You can learn more about stability, uniqueness and accuracy in our beginner’s guide to browser fingerprinting.

Try Browser Fingerprinting for Yourself

You can try implementing browser fingerprinting yourself with our open source library. FingerprintJS is the most popular browser fingerprinting library available, with over 12K GitHub stars.

For higher identification accuracy, we also developed the FingerprintJS Pro API, which uses machine learning to combine browser fingerprinting with additional identification techniques. You can try FingerprintJS Pro free for 10 days with no usage limits.

Get in touch

Star, follow or fork our GitHub project
Email us your questions at oss@fingerprintJS.com
Sign up to our newsletter for updates

Have you built a website with Gatsby?

Savannah Copland 👋 — Mon, 04 Jan 2021 08:46:31 +0000

Our team recently just rebuilt our website in Gatsby and set up our first blog using Netlify CMS. The main reason for the switch was for faster performance and easier content management, and in that regard its been great so far!

Curious to hear your experiences using Gatsby and you have any tips and tricks for us:

How was your experience using Gatsby (overall, compared to other static site generators)?
What CMS did you use (if any)?
Are you doing for AB testing on your site? We had some trouble out of the box with standard tools (Google Optimize), so curious what others have found worked well for them!

The Beginner’s Guide to Browser Fingerprinting For Fraud Detection

Savannah Copland 👋 — Mon, 04 Jan 2021 08:17:13 +0000

Website fraud can be incredibly frustrating to deal with, especially for small websites. Fraud comes in many forms, including spam bots filling out forms, fraudsters trying to steal login information, or scammers making fake purchases. What website owners and developers need is the ultimate 'swiss army knife' for your fraud-fighting toolkit - browser fingerprinting.

Browser fingerprinting provides a highly accurate user identifier that makes it much easier to triage suspicious traffic. The key to identifying those most likely to commit fraud is either by past activity, or by associating specific patterns of use with a higher likelihood of fraudulence.

Browser fingerprinting is already used by many companies for developer-led fraud prevention as it cuts through spoofing attempts to accurately identify users, and it can do this without requiring additional permissions from the user. FingerprintJS has an open source browser fingerprinting library with over 12K stars on Github and is used by 8,000+ websites. Fingerprinting techniques on their own have been found to be over 90% accurate in correctly identifying a unique user in the browser, and when used in conjunction with usage history, fuzzy matching, and probability engines, this accuracy can be further improved.

How Fingerprinting Works

Identifying a Vehicle

To explain the technology in an 'ELI5' style, here's an analogy: let’s say you’re a detective in a large city trying to find one specific car suspected of being involved in a crime, as captured by a security camera. To find this car your plan is to go to a busy intersection and take note of all the details of passing cars until you find one that matches the vehicle on the security camera. Ideally, you would like to be able to uniquely identify the car, such that only one vehicle in the city matches your description, otherwise you may have to question multiple drivers.

Let's say the security camera caught some basic details (or signals) about the vehicle. From this, you’ll be able to narrow your search considerably:

Color (blue)
Manufacturer (Chevrolet)
Type of car (truck)
Model name (Silverado)
Brand of tires (stock Goodyears)
Age/year (2015-2021)

With these signals, you may be able to uniquely identify the vehicle right away, especially if any of the specifics are particularly rare. However, in a city with millions of drivers, there may be hundreds of blue Chevrolet Silverado trucks with standard-issue tires. The more standard the combination of signals, the harder it is to get a unique match.

In those cases, you hope that your camera may have gotten lucky and matched on a more unique signal about the vehicle:

Wood panelling
Custom logo or paint job
Rust or damage
Interior decorations

Any one of these signals may quickly narrow down your search. A blue Chevrolet Silverado truck with a local company’s logo could very well be unique, even in a large city.

It's worth mentioning the most uniquely identifiable element of a car that I have let out so far - the license plate. License plates serve the express purpose of uniquely identifying a car, but what good will they do if the owner removes their plates or swaps them with fakes? It’s important to have a backup for when this method of identification fails.

By assembling a broad and comprehensive set of identifiers you can narrow the list of suspects to make singling out a bad-actor much easier.

Identifying a Visitor

Fingerprinting works just about exactly the same as the car example above. Only now you are trying to identify a visitor to a website (suspect) by capturing signals passed via the visitor’s browser (car) using a fingerprinting function (security camera).

A lot of signals can be captured through the browser, including:

User agent details (browsers installed and their versions, operating system)
Hardware details (screen resolution, battery usage, device memory)
Browser plugins used
Browser and OS settings
WebGL parameters

When a new visitor lands on your webpage, the fingerprinting function collects signals and compiles them into a hash that can be stored. Any time this visitor returns, their fingerprint can be compared to past visit history to identify suspicious behavior or fraudulent activity.

Accuracy

Let's say you are now collecting a 'fingerprint' for every visitor to your website. For that fingerprint to be useful as a method of uniquely identifying visitors, it needs to have a high accuracy. The FingerprintJS Pro API has a 99.5% accuracy rate, which means for every 1,000 visits, 995 are correctly associated with a unique identifier.

For the 5 out of 1,000 that are not correctly identified, they are either false positives or false negatives:

False positive: multiple unique visitors are given the same fingerprint
False negative: one visitor over multiple visits are given different fingerprints

To reduce false results, your fingerprint should use the right combination of signals that balance both uniqueness and stability. If a signal is highly unique, it will reduce your chances of a false negative, whereas a signal that is highly stable will reduce your chances of a false positive.

While there are hundreds of signals available via the browser, you may want to avoid using some signals in your fingerprinting function altogether. If a signal has both low uniqueness and low stability, it is likely to change over time or be spoofed frequently, and would not contribute meaningfully to uniqueness. To our car example, this might be whether a car has a dirty windshield - you cannot count on this signal to improve your chances of finding the correct car. In the world of browser fingerprinting, current battery level is a poor signal, and so while it is accessible, I would not recommend including it in any fingerprinting function you use.

The Case for Cookies

Special consideration should be given to highly unique identifiers that are not always available for user identification purposes. The most ubiquitous example of this is cookies.

Cookies work by storing a unique identifier hash in the browser when a visitor first lands on your website. When a visitor has a cookie that matches a previous visit record in your database, you can be certain that these two visitors are the same. However, cookies are a very easy identifier for a visitor to conceal:

Cookies can be cleared in browser settings
Adblockers can disable cookies by default
Visitors can revoke consent to being cookied as part of GDPR or CCPA

In these cases, instead of including a cookie as an identifier in your fingerprinting function, it can be more useful to use logic to determine when to use cookies as your identifier:

If cookie matches a previous record: use cookie
If no cookie matches previous record: use fingerprint

One of the main advantages of fingerprinting is that it is stateless. A well-implemented fingerprint can remain stable through multiple sessions, incognito browsing, uninstalling or reinstalling apps, or clearing cookies. For that reason, using the two methods in conjunction with one another can give a higher % accuracy than either identification method alone.

FingerprintJS Pro achieves its high rate of accuracy by using fingerprinting, cookies and additional machine learning techniques that incorporate IP address and geolocation. One challenge is keeping up with changes in available signals as new browser versions are released. Anytime Chrome or Safari is updated, for example, identification techniques need to be re-evaluated to determine if further tweaks need to be made to keep accuracy high. The team at FingerprintJS is constantly looking to improve our accuracy by iterating on the signals, algorithms, and techniques used.

Fraud Applications For Fingerprinting

An important thing to keep in mind when dealing with fraud is that only a small percentage of visitors are responsible for the majority of fraud cases. You will need to find ways to isolate these fraudulent visitors, verify their identity through authentication, and blacklist them as needed. However, you will want to avoid putting up roadblocks for your ‘trusted’ traffic, as additional authentication can be detrimental to user experience. You don't want to be slowing your users’ ability to access their account, make purchases, and engage with your website.

Let's explore one example of online fraud to see how you could use fingerprinting in a flexible way to isolate fraud and keep your website experience seamless.

Account takeover is a common form of fraud where malicious users try to log in to other users’ accounts, and is an excellent use-case for fingerprinting technology. Additional security at login can make account takeover much more difficult, though the type of authentication used may depend on the suspicious behavior your website experiences most often:

For bot or brute force attacks (one user or a network of bots trying many combinations of usernames/passwords):
- Show a captcha after 1 unsuccessful login attempt on a fingerprint.
- Lock user out of attempting login after 5 unsuccessful attempts on a fingerprint.
For phished accounts (a user obtained someone else’s legitimate login information through a scam or social engineering):
- Require two-factor or email authentication when attempting to login with a new fingerprint.
- Blacklist specific fingerprinted visitors from your site based on their fingerprint.

For each of these cases, type of authentication needed can be incorporated into your website by using existing workflows without having to fundamentally change the architecture of your site.

It is also important to note that users intending to commit fraud are much more likely to use techniques to conceal their identity, including using incognito mode, VPNs, and disabling cookies. These are the cases where fingerprinting especially shines, as it can associate these users without needing easily concealed identifiers like cookies and IP addresses.

Browser vs. Device Fingerprinting

The FingerprintJS open source library as well as the Pro API are intended for browser fingerprinting - they can accurately identify visitors to a website using all modern mobile and desktop browsers. However, if you want to identify users of a native mobile app, you will need to use a device fingerprinting function that is made specifically for each mobile operating system. The signals available for mobile app developers are different from signals that can be retrieved in the browser, and vary between iOS, Android, and other mobile operating systems.

The FingerprintJS team recently launched Fingerprint Android, our first open source library for identifying unique Android devices. You can read more about how our Fingerprint Android library works in our explainer article.

Get Involved

I would love to hear your questions and get feedback from the developer community on our fingerprinting technology.

Here are a few ways you can get involved

Star, follow or fork our Github projects: FingerprintJS (browser fingerprinting) and Fingerprint-Android
Need more accurate browser fingerprinting for your business? Try FingerprintJS Pro for 99.5% fingerprinting accuracy
Email us your questions
Sign up for our newsletter for updates