Current service configurations

At Brave we care about privacy. That means we work to minimize tracking on the internet for our users, and that includes interaction with services run by Brave itself.

We also don't expect you to take our word for it; we try to make our privacy features something you can verify.

This repository is a mechanism for that. Many of our features depend on complex configuration data with various service providers. That configuration protects your privacy, so you deserve a chance to verify it.

We've granted this repository special, read-only access to some of that configuration data. You can follow the steps below to review our work.

Verification

To check the current configuration of the service, click on the config badge above, or on the Actions tab for this repository and select a recent workflow run. You'll need to be logged in to GitHub to access data on this page.

Examine the logs for the fetch and display config step. You should see something like

{
  "protocol": "tcp/443",
  "domain": "pcdn.bravesoftware.com",
  "proxy_protocol": "off",
  "traffic_type": "direct",
  "modified_on": "2020-06-25T23:16:38.918708Z"
}

This displays key values that control our configuration of Cloudflare's Spectrum proxy for a particular website.

• protocol A value of tcp/443 indicates the proxy accepts normal https traffic.
• domain This describes the website the proxy is forwarding for. Match this up with the brave service endpoint you're auditing. Cloudflare is accepting traffic for this domain name and routing the traffic to their own internal servers first so they can strip the IP address.
• proxy_protocol This should be off, meaning the proxy does not forward the IP address of the connecting client. This means Brave can't use it to track you!
• traffic_type A value of direct here means https traffic is forwarded directly to Brave's server without decrypting it. Although Cloudflare sees the client IP address, this means they don't learn anything about the content of the request or our server's response to it.
• modified_on The date the configuration was last updated.

By publishing these values, we offer some assurance that we're not able to track clients connecting to these services. Since the configuration data comes directly from Cloudflare, it accurately represents the real proxy parameters. Because the query is processed by GitHub, we can't have changed the values before reporting them.

Threat Model

Since this report is about auditing Brave's service configuration, the primary attacker we consider is Brave itself. The various service providers are generally trusted to implement what they claim to. We consider various attacks below.

Brave could post a fake report. The main audit report webpage generated by this code repository is published through the Github Pages mechanism. While hosted by Github, the content is under Brave's control, and so Brave could publish a report page which wasn't actually generated by running this code. The web page is thus not trustworthy in itself, but intended as a reader-friendly summary. This attack may be guarded against by review of the Github Action workflow log, linked at the bottom of the page. That content is controlled by Github and would not match a different report page published through another channel.

Brave could try to subvert report generation. The configuration data is fetched and the report generated as part of a Github Actions script. To insert incorrect information in this process, Brave would require Github's collusion. We consider this unlikely.

Note, however that this is only true while the script is using a Github-provided runner. If Brave configured the action to execute on a self-hosted runner under their own control, they could likely subvert the process, inserting inauthentic report data while pretending to execute the code as specified.

Brave could change the configuration while the report is running. Brave ultimately controls the Cloudflare configuration for each service and the audit report timing. They could use a less secure config most of the time and only set secure options for a short interval around the time a query is made to publish a new audit report. This is, however, detectable by looking at the modified_on field of each domain's report. This data comes from the Cloudflare API, and so is trusted to be correct. Any recent modification is suspicious, and one that is habitually more recent than the report generation interval could indicate this attack.

Brave could try to get inaccurate data from Cloudflare. The report is ultimately generated from configuration data retrieved from Cloudflare's API endpoint and refers to specific domains. Brave would require Cloudflare's collusion, similar to the Github case. We consider this unlikely as well.

Brave could omit compromising channels. While this audit publishes certain service configuration settings, the information that config is designed to protect may be available in other ways. To the extent that services have public documentation and/or offer the same services to other subscribers, anyone evaluating the audit report can independently look for any such overlapping access methods.

One example is the Cloudflare Spectrum event log which can contain both a timestamp and the original client IP addresses. If Brave accessed that log they could subvert some of the anonymity protection the proxy is intended to create. There is an audit log which would reveal whether the Spectrum event log had been accessed. Brave has this log disabled for their account and enabling it is forbidden in their contract with Cloudflare. Unfortunately, unlike the Spectrum configuration itself, which can be accessed through a read-only interface, the audit log can only be accessed with a token which grants edit permissions. We considered the risk of granting modification rights to a Github Actions script too high, and so that audit log isn't included in the report.

Happy checking!