Localhost Resource Permission

This is the 27th post in an ongoing, series describing new privacy features in Brave browsers. This post describes work done by Sr. Research and Privacy Engineer Shivan Sahib. This post was written by Peter Snyder.

Starting in version 1.54, Brave for desktop and Android will include more powerful features for controlling which sites can access local network resources, and for how long. Most popular browsers allow websites to access local network resources without protection or restriction, which puts users’ privacy and security at risk. Many popular websites query your local network, often as a fingerprinting technique; others do so to observe and possibly exploit information from other software running on your machine.

Brave is the first popular browser to extend the Web’s permission API to control when sites can access localhost resources. Brave’s implementation allows advanced users to give any site access to localhost resources, while also avoiding the annoyance of prompts that a localhost request is likely malicious. Brave’s implementation also takes advantage of existing improvements Brave has made to Web permissions.

What are localhost resources, and why might sites want to access them?

“Localhost resources” is a broad term that refers to resources (images, web pages, etc.) that websites can access, but which don’t come from the “Web.” Instead, these resources are hosted (often unknowingly) by other software on your computer.

Surprising though it may be, most browsers allow websites to access these local resources just as easily as they can access other resources on the Web. Browsers allow websites to access localhost resources for a range of reasons, but the main two reasons are historical legacy (i.e. it’s always been done this way) and backwards compatibility. Browsers used to be less concerned about user privacy, and so didn’t enforce distinctions between first-party resources (those hosted by the site you’re visiting), third-party resources (those hosted on other public websites), and localhost resources.

Thanks to this historical “accident,” a small but important amount of software has been built expecting to be freely accessible by websites, often in ways invisible to users. And many of these uses are benign. Examples include some wallets for cryptocurrencies, security software provided by banks or security companies, and hardware devices that use certain Web interfaces for configuration.

In some situations, browsers also allow public websites to access localhost resources to help developers test their software.

Unfortunately, a wide range of malicious, user-harming software on the Web uses access to localhost resources for malicious reasons. For example, fingerprinting scripts try to detect unique patterns in the other software you have running on your device to re-identify you, and other scripts try to identify insecure and vulnerable software on the machine and try to exploit it.

How does this change affect how websites can access localhost resources in Brave?

Brave is the only popular browser to ship multiple protections against sites maliciously accessing localhost resources. Brave currently uses filter list rules to:

• Block scripts known to maliciously scan localhost resources
• Block requests from public sites to localhost resources 

This is in contrast to other browsers, which generally ship no protections against sites accessing localhost resources (see the next section for some caveats).

Brave will soon start rolling out a new approach for protecting users against sites abusing local network resources. This new system will have the following parts:

• Requests to localhost resources, from a localhost context are allowed automatically; Brave does not block a locally hosted page from accessing other locally hosted resources. ¹
• Brave will continue to use filter list rules to block scripts and sites known to abuse localhost resources.
• Brave will include a new permission called the “localhost” permission. Only sites with this permission will be able to make sub-resource requests to localhost resources. By default, no sites have this permission and, importantly, most sites have no way to prompt users for this permission. However, advanced users can use the existing site settings interface to grant sites this permission. ²
• Brave will also include a list of trusted sites, or sites known to access localhost resources for user-benefiting reasons. The first time a site on this list initiates a sub-request to a localhost resource, it will trigger a permission prompt of the previously mentioned localhost permission. This list is publicly available, and will be maintained by Brave.

Brave has chosen to implement the localhost permission in this multistep way for several reasons. Most importantly, we expect that abuse of localhost resources is far more common than user-benefiting cases, and we want to avoid presenting users with permission dialogs for requests we expect will only cause harm.

Additionally, we’re purposely inserting a permission prompt into a situation where sites won’t expect it (or even realize third-party scripts are trying to access localhost resources), and so we want to further limit the permission prompt to situations where we expect it’s beneficial to users and sites alike.

How do other browsers handle connections to localhost resources?

As mentioned, most other browsers do not significantly prevent websites from accessing localhost resources. The desktop versions of Firefox and Chrome allow both secure and insecure public sites to access localhost resources, and seem to intend to allow public secure sites to access localhost resources indefinitely.

As a side-effect of security restrictions, Safari currently blocks requests to localhost resources (as do other WebKit browsers) from secure public websites. But to the best of our understanding, Safari does not explicitly intend to block these requests from public websites.

As far as we can tell, Brave is the only browser that will block requests to localhost resources from both secure and insecure public sites, while still maintaining a compatibility path for sites that users trust (in the form of the discussed localhost permission).

What’s next for localhost resource handling in Brave?

We’re excited to share this work with Brave users, and expect it to make the Brave browser even more powerful without harming user privacy. However, there’s more work to be done to improve how browsers handle localhost resources.

First, we’re exploring ways to better explain to users what localhost resources are, while they’re using Brave. Once we’re confident we’ve found a way of explaining what the permission controls that non-advanced users can understand, we plan on making the permission available to all sites, and not only those on our list.

Second, we’re pushing these protections deeper in the network stack, so that Brave can protect users against additional, less common methods of sites making localhost requests (including DNS records that refer to localhost). We also hope to have more to share soon.

Third, we’re interested in unifying and expanding how we can apply permissions (or permissions-like controls) to network requests in general. Brave already applies permissions protections to Google login requests that require third-party cookies, and we’re interested in seeing what other similar uses make sense. The main difficulty here is applying an asynchronous permission model to requests that are often made with synchronous expectations. Again, we’re exploring several options, both within Brave and with external researchers, and hope to have more to share soon.