Brave brings HTTPS by Default to iOS
Starting with version 1.68, Brave will become the first iOS Web browser to try to upgrade all sites to HTTPS by default.
Read this article →By the Brave Privacy Team
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.
“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.
Brave is the only popular browser to ship multiple protections against sites maliciously accessing localhost resources. Brave currently uses filter list rules to:
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:
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.
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).
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.
Brave’s localhost protections do not apply to aliases the user may have installed for localhost, such as in /etc/hosts
. See the final section of this blog post for more details. ↩︎
On Desktop, users can grant sites the localhost permission at brave://settings/content/localhostAccess
. Android users can do the same by visiting Settings > Site settings > Localhost Access
. ↩︎
Starting with version 1.68, Brave will become the first iOS Web browser to try to upgrade all sites to HTTPS by default.
Read this article →With desktop and Android version 1.64 in a couple of months, Brave will sunset Strict fingerprinting protection mode.
Read this article →Request OTR is another in Brave's suite of features that support the privacy needs of individual users, protecting far beyond the "standard" threats browsers typically watch out for.
Read this article →