We start by seeing 5 requests to go-updater.brave.com/extensions. Each of these is requesting a different component of the browser. Each request contains 617 bytes of JSON data including your Operating System, and version of Brave. This information helps the server to know which variant of an extension is appropriate for your device.

None of these requests actually return the extension itself. Instead, they reply with further instructions. The first 4 requests result in about 465 bytes of JSON telling Brave where it can find the requested extensions, as well as how to test them for authenticity. The 5th response is empty. Instead of JSON instructions, the server uses HTTP headers to inform the browser that it should request the CRLSet (Certificate Revocation List) from componentupdater.brave.com.

The call to componentupdater.brave.com results in 1.8 KB of JSON informing Brave where the CRLSet can be downloaded. All of the URLs provided come from Google, which Brave doesn’t call directly. Instead, Brave continues the practice of proxying all requests through the brave.com domain, shielding the user’s device from Google servers. The next 5 requests (to brave-core-ext.s3.brave.com and crlsets.brave.com) are the actual downloads taking place.

Once these have downloaded, Brave initiates the routine process of ensuring all extensions are up to date. All of those requests return with confirmations that these extensions do not need to be updated at this time. Brave will check later to ensure ongoing user privacy and security.

Next up is a request for /promo/custom-headers. This request returns 271 bytes of JSON that serves as a replacement for a unique user-agent string. This file instructs Brave to add a custom HTTP header to certain partner requests, enabling Brave users to anonymously enjoy free access to things like premium content on cheddar.com, and more.

We then see Brave issue 3 very peculiar requests to invalid host names. In this case, it’s to kgcemqlxlymf, jlejbuhy, and skxrkyaibq. You may spot similar requests being made by other Chromium-based browsers later. These are to detect DNS Hijacking. If at least 2 of these resolve to the same host, Brave will suspect the ISP or network of advantageously inserting content into the user’s session (often times the ISP may be showing ads).

Another set of familiar requests we’ll see in later reviews is for Google’s SafeBrowsing service. This is a large collection of URLs that are known to be harmful. There are 2 ways to interact with this service: the Lookup API, and the Update API. Brave uses the Update API, which downloads a list of URLs suspected to be harmful. This allows Brave to query a local resource rather than making numerous calls out to a third party. As we can see later, Brave continues to proxy even these requests through safebrowsing.brave.com.

That covers nearly everything Brave does during its first run experience on a new profile. We do see another call to go-updater.brave.com/extensions, checking to make sure all of our installed extensions are up to date. And this returns with a 1.7 KB confirmation response.

One thing we didn’t see here, but you may see in your own reviews, are referral pings. If you download the Brave browser via a referral link, Brave will attempt to give credit to the owner of that referral code. This means you will see a couple of additional requests. You can learn more about how we implemented the Referral System in Brave’s Use of Referral Codes on GitHub.