Data Privacy and Blackfire
Security and transparency are very important for us and probably key to our success. Learn more about your data privacy.
Very early on, we decided that Blackfire would be a SaaS offering. It gives us a lot of flexibility, and thanks to our continuous integration workflow, we can deploy very frequently; at least once a week and sometimes several times a day. That’s the power and one of the promises of Software as a Service.
But some companies are more security-sensitive than others (banks, governments, …) and they are worried about the data SaaS websites gather from their servers. An on-premise version could be a solution, but it makes things a lot harder on our side when it comes to packaging and updating the full stack. We will probably get there at some point, but for now, we like to be able to iterate and innovate as fast as possible.
As I’m going to show you in this blog post, Blackfire does not get any sensitive data from client servers, but making that information transparent is one big step towards adoption in security-sensitive companies.
Security and transparency are core values of Blackfire and they drive everyone in the team. That’s why we already wrote about the sensitivity of your server and client credentials in the past. And that’s why we want you to better understand what kind of information we get from your code.
Blackfire is made of two parts: a PHP extension and an agent that you need to install on your servers, but also a website where you can work on your profiles. The agent does quite a few things like: parsing different input formats, cleaning up the data, compressing them, anonymizing potential sensitive data. The agent does that on your servers to limit the number of data we send back to our servers but also to respect your data privacy as much as possible; we only get what we really need.
When the data are ready, the agent send them back to Blackfire servers. So, what are we getting on our side? Function call names, times, memory, anonymized SQL queries and HTTP calls (only for the Enterprise Edition), and some metadata like the full HTTP request (URL and headers) for web profiles, or the CLI command for console apps. Nothing that could potentially be used to harm you.
Of course, you don’t need to trust us and we highly encourage you to check the data that are sent by the agent. The easiest way is to install a proxy between the Blackfire’s agent and the Blackfire’s servers. If you don’t have one, we provide a very simple PHP script that does exactly that (and the code being simple, you can audit it quickly).
Then, change the endpoint to
127.0.0.1:8383 by using one of the following methods:
blackfire curl --endpoint=http://127.0.0.1:8383 ...;
- Or start the agent with
- Or temporarily change the blackfire agent/cli config files.
$ php blackfire-io-proxy.php
Profile your code, and you will see something like the following:
-> file-format: BlackfireProbe
-> Php-Os: Linux
-> Request-Pmu: 375592
-> Session-Serializer: php
-> Request-Mu: 365992
-> Request-Start: 1432676122.066484
-> Sys-Load-Avg: 0.03 0.04 0.04
-> Php-Sapi: cli
-> Php-Version: 5.5.24-1~dotdeb+wheezy.1
-> Cost-Dimensions: wt cpu mu pmu php_errors num_obj ref_mismatch nw_in nw_out gc_ct gc_num_obj gc_wt gc_mu gc_pmu
-> Php-Extensions: [...]
-> Request-End: 1432676122.067598
-> _server: _=%2Fusr%2Fbin%2Fphp&argv%5B0%5D=test.php
-> Response-Code: 255
-> run_init::composer/autoload_psr4.php==>dirname//3 2 4 208 0 0 0 0 0 0 0 0 0 0 0
-> run_init::composer/autoload_files.php==>dirname//3 1 0 208 0 0 0 0 0 0 0 0 0 0 0
-> Composer\Autoload\ClassLoader::register==>spl_autoload_register//1 2 2 184 0 0 0 0 0 0 0 0 0 0 0
-> run_init::vendor/autoload.php==>load::composer/autoload_real.php//1 99 100 13752 27008 0 0 0 0 0 0 0 0 0 0
-> run_init::vendor/autoload.php==>run_init::composer/autoload_real.php//1 2 2 0 0 0 0 0 0 0 0 0 0 0 0
If you want to better understand the meaning to the data, we’ve even documented our profile file format.