Brave's Concerns with the Client-Hints Proposal

By Brave employees Pete Snyder, privacy researcher, Pranjal Jumde, security engineer, Tom Lowenthal, product manager for privacy and security, and Brian Clifton, development manager for the desktop browser.

One of Brave’s main goals is to improve privacy on the Web, so that everyone can enjoy and interact with the Web while protecting their personal information.

The primary way Brave does this is by building a wide array of privacy protections that are on by default into our browsers, across all of our supported platforms.

A second way Brave works to improve privacy on the Web is through Web standards. For example, Brave advocates for privacy on several W3C committees, most significantly of which (for privacy) is PING, the Privacy Interest Group. As part of PING, Brave works to ensure that new Web standards don’t introduce new privacy risks, to Brave users or Web users in general.

This post discusses a new proposed Web standard, Client Hints, and why Brave is concerned that it harms Web privacy.

What is Client-Hints?

Client-Hints is a new standard for HTTP communication. It has aspects that affect both HTTP and the Web API, and so different pieces are dealt with in different standards bodies (i.e. the IETF and W3C respectively).

At a high level, the Client-Hints proposal has three parts:

1. A convention for HTTP headers that browsers can generally use to tell the server about the browser.
2. A system for describing when the browser should send various values in Client-Hint headers.
3. Definitions of initial “hints”, or which values the browser should send to the server.

At root, Client-Hints is a standard that allows servers to send to clients (via HTTP header) a request for information about the browser, and for the browser to respond (via HTTP header) with the requested values. Examples of such Client Hint values include the height and width of the browser viewport (roughly, the browser window), the amount of memory on the client device, and pixel depth of the user’s display, among others. There exist related proposals to, for example, move the user agent to be a client hint.

Under the current proposal, Client-Hints are not automatically sent to all domains. They are opt-in with respect to the server, meaning that the browser won’t send the values unless the server requests them, but should provide them when the server does request them. The first party domain (the site to which you’ve browsed) can also indicate that the client should send requested client hint values to some or all third parties involved in the page.

There are additional proposed rules for when Client-Hints should be sent, including that clients should send Client-Hints only over TLS-secure connections, that clients should not send Client-Hints when the browser has disabled JavaScript, and that clients should avoid sending Client-Hints when that data is otherwise unavailable via JavaScript, HTML or CSS.

Privacy Concerns with the Client-Hints Proposal

We are concerned that the Client-Hints proposal would harm Web privacy in three ways:

1. Client-Hints Gives Existing Identifying Values to Servers in Additional Ways

The Brave Browser, along with other privacy tools and browsers, go to great lengths to prevent websites from tracking and identifying you without your consent. Prior research and organizations have documented that the values transmitted through Client-Hints can be used to identify and track Web users with shockingly high accuracy. For example, Eckersley (2010) found that screen resolution is highly identifying, and Laperdrix et al (2016) found that device color depth (along with screen resolution) is also highly identifying.

Brave is working on preventing websites from learning many of these values using JavaScript, while at the same time not breaking websites; adding Client-Hints into the browser platform would expose an additional tracking method to block and potentially make it even more difficult to maintain a usable, private Web.

2. Client-Hints Allows Additional Parties To Track You

Client-Hints would expose identifying values to parties that currently cannot access them without actively injecting scripts. This is true for two reasons.

First, Client-Hints allows the first party to instruct the browser to send identifying (i.e. fingerprintable values) to third parties, through a process called third-party delegation. Currently, when a site links to an image on a third party domain, that third party has no way of determining these identifying values (browser height and width, display depth, etc). Under Client-Hints, the first party could instruct your browser to send these identifying values to third parties in the background, resulting in more identifying information being shared with more parties, without most users realizing what is happening.

Second, Client-Hints would make it easier for an additional set of Web parties, “TLS-terminators” (i.e. servers between the client and the website) to track users. TLS-terminating parties like CDNs and proxies would have new passive and consistent access to identifying information. Currently, if a TLS-terminating party wanted to track a user, they would need to use either an active attack (e.g. script injection) to learn these identifying values (we expect these are uncommon), or fallback to difficult, and frequently changing heuristics to try and extract these values from URLs and cookies. In other words, Client-Hints would make it easy for CDNs and proxies to access identifying information, in cases where it is currently difficult-to-impossible to do (in the common case).

We want to emphasize that we are not accusing existing CDNs (or similarly positioned parties) of being malicious or harmful. On the contrary, many CDNs are leading valuable efforts to improve Web privacy (to name just two wonderful examples, Cloudflare’s PrivacyPass work, and CloudFlare’s 1.1.1.1 DNS resolver). But the unfortunate lesson of Web privacy is that systems need to be designed to protect against Web parties that are far less trustworthy and privacy-respecting than well known CDNs such as Cloudflare and Fastly.

3. Client-Hints Continues the Pattern of Privacy Violations on the Web

Some proponents of Client-Hints defend the proposal by saying, effectively, that it is no worse than what already exists, that servers / sites gain no additional fingerprintable values through Client-Hints that they cannot already access. Privacy-wise, we think this is too low a bar.

Brave, among other privacy-focused parties on the Web, is working hard to improve privacy on the Web, and to solve problems that exist today. Even if all Client-Hints did was duplicate existing fingerprinting surface, it would still amount to further technical debt that we in the privacy community need to pay down.

In other words, when you find you’re digging yourself into a hole, the first thing to do is to stop digging. The Web is already rife with difficult privacy problems; Client-Hints would only further things in that direction.

Not Throwing the Baby Out With the Bath Water

We note that there are some aspects of the Client-Hints proposal that we don’t oppose, or think could even be a positive thing for the Web. The previously mentioned example of moving the User-Agent HTTP header to a client hint is one such example where, if coupled with removing the navigator.userAgent property, Client-Hints could be useful for improving privacy online. (Removing User-Agent would require effort sustained over a long term, among all browsers and maintained websites and services.) At the moment though, most of the suggested values shared in Client-Hints are privacy harming, and so we are negative on the proposal in general.

Likewise, we support the overall goal of the Client-Hints proposal, to improve Web performance. While we don’t think the potential performance improvements in the proposal are worth the risk to Web privacy, we applaud and appreciate that the Client-Hints authors are working towards an important and valuable goal.

Brave and Privacy

Privacy is a core part of Brave, both for our users and for the Web in general. Brave protects users’ privacy in many ways, such as blocking resources known to be tracking related, by default block third party cookies and storage setting, and preventing websites from accessing Web API methods used for fingerprinting. We are developing similar protections to the kinds of privacy harms discussed in this post (sending identifying values in Client-Hint HTTP headers, and where possible, preventing websites from accessing the same values through JavaScript).

We’re excited to continue working to keep our users private online, to put users first in ownership and control of their data, and to keep trying to improve privacy on the Web as a whole through our standards work.