Encrypted crash reports submitted via Tor

If the user chooses to report a crash, the crash reporter should encrypt the crash report with the developers' public key and store it on the disk until the app is re-launched. The app should import the encrypted report, post it to a crash report channel and delete it from the disk.

Messages in the crash report channel should be synced with contacts, but no further. We'll need to add a special contact that's only reachable via Tor for delivering reports to the developers. To prevent the special contact from being a single point where Briar users can be enumerated, it should only be contacted when there are crash reports to deliver.

Users should be able to opt out of sending crash reports and opt out of delivering crash reports for their contacts.

mentioned in issue #158 (closed)

mentioned in issue #236 (closed)

Messages in the crash report channel should be synced with contacts, but no further.

@akwizgran can you expand on this? We don't want every Briar user to synchronize every report ever posted, so I assume you mean something like "if a Briar user doesn't have Tor, push this report to all contacts that do advertise Tor"? Or "... to all contacts", and have this done recursively?

@str4d sorry for being unclear, I meant share locally created reports with contacts, but don't share reports received from contacts with other contacts.

However, as a first pass let's just upload locally created reports to HQ via Tor - we can worry about the sync stuff later. I want to punt the "special kind of contact that's only accessible via Tor" issue until we've decided whether we need anonymous contacts for private groups (see comments on #127 (closed)).

If we are going to just upload reports directly to HQ via Tor, do we want to consider moving to ACRA for crash collection and Acralyzer or something compatible for the server backend? We will need to have something to view the crash reports in anyway, and ACRA is a reasonably mature and well-used crash collector. It supports custom attributes in case there is something it doesn't send that we want to, and provides for sending reports on next start. Support for sending reports via Tor or through Briar could probably be implemented by a new ReportSender. The only feature it doesn't provide is encrypting unsent reports on the local storage (partly it seems because it offers the ability to edit the unsent reports on next startup, but I'm not certain), but being an open-source project, we could extend it to do so

@str4d in the long term we may well want to use something like ACRA, but given the time constraints I think we should aim to get a minimal version of this feature working first, and revisit it later if ACRA or another project offers something we need (such as analysis tools).

It doesn't look like ACRA would save us time at this stage, as we'd still have to write the code for encrypting crash reports and uploading them via Tor.

Where I figured it would save us time was on the server side. But for now I will proceed on the assumption that we have some server-side script that receives POSTs and saves the received data to a file. I'll aim to make the new code modular enough that we can adapt it to ACRA at a later stage (I don't see any other open-source crash collection libraries, ACRA appears to have become the standard if you aren't using a specific upstream provider and their SDK).

mentioned in merge request !126 (merged)

mentioned in merge request !128 (merged)

The current implementation in !128 (merged) uploads the crash reports to the server as a multipart form-data POST. This is probably good enough for now; we don't need to worry about protecting the server from spamming, because eventually the only way to upload will be through Briar.

On a related note, do we want to only be able to submit crash reports through Briar? I can forsee a bootstrapping issue, if a crash is being caused by bugs in Bramble that are triggered on that user's device.

The current implementation in !128 (merged) uploads the crash reports to the server as a multipart form-data POST. This is probably good enough for now; we don't need to worry about protecting the server from spamming, because eventually the only way to upload will be through Briar.

An attacker could skip Briar and spam our hidden service via Tor, but I agree that spamming is something we can worry about later.

What do you think about skipping HTTP and just delivering the encrypted crash report over plain TCP?

On a related note, do we want to only be able to submit crash reports through Briar? I can forsee a bootstrapping issue, if a crash is being caused by bugs in Bramble that are triggered on that user's device.

Yup, that's an important potential problem, but I think the privacy of our users (and the protection we get from not being able to identify them even if we wanted to) trumps other concerns here. We'll have to hope that if there are bugs causing a significant number of crashes, we'll be able to learn about them from beta testers and reproduce them to generate our own crash reports.

What do you think about skipping HTTP and just delivering the encrypted crash report over plain TCP?

I picked that simply for ease of implementing the server; there should be easy server modules for e.g. Python that can listen for form POSTs, and save the received files to disk. We certainly can do plain TCP, but then we need some kind of protocol to separate individual crash logs. Then again, a custom protocol may make the client side slightly cleaner...

It turns out that ACRA also uses a form for sending data, or a more detailed JSON structure for newer versions. Perhaps that might be a better format to emulate; then it would be trivial to switch from encrypted reports being sent to disk, to encrypted reports being sent to Acralyzer.

Added ~8 label

Reassigned to @str4d

mentioned in commit 355c84d7

!128 (merged) now functions for sending encrypted crash reports to a server running reportsrv.py and Tor configured with:

HiddenServicePort 8080 127.0.0.1:19990
HiddenServicePort 8081 127.0.0.1:19991

The only dependency is Twisted.

Updated reportsrv.py

mentioned in merge request !140 (merged)

!140 (merged) builds on !128 (merged) to use ACRA for crash reporting. In combination with decryptsrv.py, Briar can upload encrypted crash reports directly into Acralyzer for analysis.

mentioned in issue #311 (closed)

mentioned in commit 1b087202

mentioned in issue #323

Opened #323 for sending reports through Briar. This ticket will be closed once !140 (merged) is merged.

Status changed to closed by commit ec933c09

mentioned in commit ec933c09

Added ~10 and removed ~8 labels