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 post describes work done by Research Engineer Anton Lazarev and Senior Privacy Researcher Peter Snyder.
Trackers are constantly working on new techniques for evading privacy tools, and keep deploying new ways to evade privacy-protecting tools like the Brave browser. This post discusses a recent technique trackers use, CNAME cloaking, and a new feature in Brave that keeps Brave users protected.
One way privacy tools like Brave prevent trackers from tracking you online is to use crowd-sourced lists of privacy-harming domains, and blocking requests to them. Trackers sometimes use canonical name DNS records (i.e, CNAMEs, a way of making one domain point to another) to make their tracking domains look like subdomains owned by the site you’re visiting, when in truth the domain is (effectively) controlled by a unrelated third party. This is now available in our Nightly desktop version. With the upcoming Brave 1.17, Brave Shields will roll out support for CNAME-based adblocking to all Brave users. This enhanced adblocking solution is able to counter the increasingly common practice of CNAME-cloaked tracking scripts.
Non-technically, a CNAME DNS record says “you can call me this, but treat me like that”. In its benign uses, it enables things like custom domains on hosts; Github Pages provides me with the domain pes10k.github.io, but with a CNAME instruction visitors can use www.peteresnyder.com to reach my github pages site, regardless of where GitHub points pes10k.github.io to.
Some trackers abuse CNAME records by using the indirection it provides to evade privacy protections. For example, many browser features and privacy tools make distinctions based on whether a request of iframe is “first-party” (i.e., it comes from the same party that provides the top-level website) or “third-party” (i.e., the frame or resource comes from anyone else). Some trackers use a technique sometimes called “CNAME cloaking” to make their tracking code look like a “first-party”, more trusted resource. Other trackers use “CNAME cloaking” to serve their code from unexpected or frequently changing origins, in combination with techniques like domain generation algorithms.
Though CNAME cloaking has been observed for a long time, the technique received more attention in late 2019, when tracking companies started leveraging the fact that adblocking extensions could not access CNAME information when making blocking decisions. Taking advantage of this limitation, trackers started using randomized subdomains with CNAME records, all pointing to the domain of the tracking company. Tracking companies would then serve unwanted JavaScript code under unguessable first-party domains. The resulting unguessable origins have proven extremely difficult to fully identify and enumerate using list-based approaches, given how cheap they are for trackers to create, and how frequently they rotate.
Tracking scripts are harmful to privacy on the web, causing users to be fingerprinted and tracked when left unblocked. CNAME-cloaked tracking scripts are even more dangerous, as they are often served under a first-party subdomain. This means they gain the ability to access cookies and other local identifiers under a first-party context, which can allow tracking companies to gather even more information about individuals’ browsing habits.
In version 1.25.0, uBlock Origin gained the ability to detect and block CNAME-cloaked requests using Mozilla’s terrific browser.dns API. However, this solution only works in Firefox, as Chromium does not provide the browser.dns API. To some extent, these requests can be blocked using custom DNS servers. However, no browsers have shipped with CNAME-based adblocking protection capabilities available and on by default.
In Brave 1.17, Brave Shields will now recursively check the canonical name records for any network request that isn’t otherwise blocked using an embedded DNS resolver. If the request has a CNAME record, and the same request under the canonical domain would be blocked, then the request is blocked. This solution is on by default, bringing enhanced privacy protections to millions of users.
Consider the site https://mathon.fr as a concrete example. Without CNAME uncloaking, Brave blocks 6 requests for tracking scripts served by Google, Facebook, Criteo, Sirdan, and Trustpilot. Four of these requests are initiated by a single script hosted under a randomized path under the first-party subdomain 16ao.mathon.fr. Inspection outside of the browser reveals that 16ao.mathon.fr actually has a canonical name of et5.eulerian.net, meaning it’s a third-party script served by Eulerian. With CNAME uncloaking, Brave 1.17 is able to detect the CNAME redirection and block the initial Eulerian script before it can initiate requests to any other third party trackers, enhancing users’ privacy and saving network bandwidth and CPU cycles at the same time.
CNAME-cloaked third-party resources from et5.eulerian.net appear to the browser as if they are first-party resources served from 16ao.mathon.fr.
We expect this change to reach all Brave users by November 17th, 2020. This is another example of how Brave aggressively protects your privacy and improves performance, even when trackers refuse to take no for an answer. Stay tuned for more information about new privacy features coming in Brave!
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 →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.
Read this article →