How Sciagraph stores your data privately and securely in the cloud

Once profiling in Sciagraph is finished, a report is generated. This is a static set of files that won’t change; the availability of newer versions of Sciagraph with improved reporting won’t change the output of previous reports.

If you’re using the Team plan, the report will be stored in Sciagraph’s cloud server for later retrieval.

In order to keep your profiling results secure, the reports are encrypted end-to-end. The goal is to ensure that the cloud server cannot read the reports’ contents.

Specifically, the data is encrypted and stored as follows:

  1. A random encryption key is generated on your computer, within the process being profiled.
  2. The report is encrypted with this key.
  3. The encrypted report is uploaded to the Sciagraph cloud server, where it is stored under a random download key.
  4. The download key and decryption key are logged within your running program; you can use them later to retrieve and view the decrypted report.

Because the decryption key is never sent to Sciagraph’s cloud server, and only encrypted data is uploaded, it is not possible for anyone with access to the cloud server to decrypt your data, regardless of whether they are an operator or an attacker. Only someone who has the decryption key can read the data.

Note: Your application’s data is never uploaded. The profiling report does include source code snippets from those Python lines that showed up in the profiling.

Your responsibilities

Keep track of the keys: Because the server cannot read your data, if you lose your decryption key (or your download key) your profiling report will be unrecoverable. You must therefore make sure you keep track of the download and decryption keys for each profiling report so you don’t lose it.

Note: Alternatively, you can also have Sciagraph write the unencrypted reports to local disk and store them yourself.

Keep the keys reasonably secure: Anyone with the decryption+download key can download and view your profiling reports. Make sure you control access to these keys appropriately.

The profiling report will contain small chunks of your program’s source code—the stack traces responsible for most runtime or memory usage—but not your whole program. As such, a good baseline heuristic is that you should be treating these keys with the same level of security as you would the logs from your program.