How browsers are adapting their technology to prevent fingerprinting
As discussed in the article, ‘Why fingerprinting is unlikely to succeed‘, all three leading browsers, including Chrome, have stated that they will actively stop any fingerprinting activities. This article describes the different methodologies that each browser has in place to protect users and, ultimately, stop users from being tracked without their knowledge.
Apple Safari makes users look similar by removing unique identifiers from web requests
Safari has been at the forefront of implementing privacy-first changes. In a white paper released in November 2019, Safari mentioned three approaches to tackling fingerprinting, which prevent data being shared about each user and make users look similar to one another:
- Presenting a simplified version of the system configuration to trackers, so different devices look identical;
- Removing any custom headers or unique identifiers from web requests; and
- Stopping support for most plug-ins with MacOS, so these can no longer be used for cross-site tracking.
Together, these techniques mean that trackers see fewer data points about each user and users begin to look like each other, creating a kind of “herd immunity”.
Mozilla Firefox prevents data from being shared with blacklisted tracking companies
In January 2020, Firefox introduced fingerprinting blocking as a standard browser setting as an extension of its Enhanced Tracking Protection (ETP). The organization believes that there are two ways to protect users against fingerprinting:
- block known fingerprinting trackers
- modify or remove APIs that can be used for fingerprinting
Google Chrome has proposed limiting information exposed to trackers
Google’s announcement that it intends to block third-party cookies shook the market. It has the largest market share of browser traffic and was also the least expected to make the change because of Google’s heavy involvement in Ad Tech.
Google has made it clear that it will also block fingerprinting. However, it has proposed a different route from Firefox; rather than blacklisting particular companies, Google instead plans to incorporate technological barriers to stop fingerprinting. This is described in Google’s privacy sandbox, which is a list of proposals for protecting user privacy. Chrome has not yet implemented nor set these in stone, but they show a clear indication of the direction in which Chrome is moving. These are some of the suggestions made by Chrome, as of April 2020.
- Privacy Budget – Users can be identified by a combination of the pieces of information exposed about them. This proposal suggests limiting the number or depth of pieces of information exposed about a user, making them unidentifiable. Chrome would start by measuring how many pieces of information each domain collects on users. In cases where it detects that the amount of information can lead to uniquely identifying a user, Chrome would then enforce the budget. It would do this by either blocking API calls that exceed the limit (with some exceptions), or by obfuscating the results.
- Removing Passive Fingerprinting Surfaces – A fingerprinting surface is a point where a website can learn information about a user. This can include the user’s IP address or the user’s language selection. Chrome proposes to restrict two fingerprinting surfaces:
- Client-side language selection which the proposal states should only be made available for decisions on what language content to display, and nothing else.
- User-Agent String shows the device and version of a browser that someone is using. The proposal suggests that this is slowly made less and less granular.
- Reducing Entropy from Surfaces – Entropy is a measure of information in a variable. For fingerprinting, this means the higher the entropy of a fingerprint, the more unique the user (more information on the entropy of fingerprints can be found here). In order to reduce the entropy from fingerprinting surfaces, Chrome is proposing to reduce the number of pieces of information available about a user, thus making them less uniquely identifiable.
- Device Sensors – device settings, such as orientation and accelerometers of mobile devices may not uniquely identify a user, but by carefully analyzing enough of these data points, it is possible to get a per-device factory calibration [source]. Chrome does not have an explicit solution proposal, but so far has acknowledged the problem.
- Battery Level – following Mozilla and Safari’s lead, Chrome is considering stopping exposing battery level information. The initial use case for this data was letting programs save data before a device runs out of battery. However, in reality, it is used for short-term device identification instead [source]. Chrome does not have a firm plan in place for tackling this, but it is under consideration.
- IP Address – IP addresses are considered a part of a privacy budget by Chrome, as static IPs are an extremely strong candidate for fingerprinting. Chrome’s proposal involves making third parties “blind” to IP addresses, thus saving their privacy budget for other data points.
Many of these fingerprinting prevention techniques are still being developed but it is apparent that Chrome, Safari and Firefox will all invest in blocking user tracking. They take a similar stance to Permutive in believing that users’ personal information should not be shared by linking an ID to an IP address or device. We are closely monitoring developments in the market to ensure full technical and regulatory compliance.