Crashlytics and performance monitoring

[tstirrat]

Placeholder issue to decide on crash and performance monitoring solution.

It would be good to have something in place as early as possible so that we can catch crash/perf issues before they become wide spread.

Case example: A large contingent in a certain country use a certain device which is very different to the developers devices and emulators, causing that contingent to crash and be unavailable to participate.

Firebase Crashlytics and Perf (disclaimer, I work at Firebase, this is the one I am familiar with)

• https://firebase.google.com/pricing (Free for both perf and crash)
• Unsure if installing crash/perf implies installing the Google Analytics SDK

There are certainly other options for crash and perf too.

Open questions:

1. Might a crash and/or perf monitoring SDK cause additional privacy concerns for the users?

[E3V3A]

Crashlytics is certainly great to use when you have a complex app, but for the simplicity (?) of this, I can't imagine to see the benefit outweigh the extra load of adding new library dependencies and the extra weight (and tarnishing?) of privacy. (First the app focused on privacy, then we start adding libraries that undo most of those privacy measures.) Dumping a simple logcat text file can probably help resolve 95% of any future issues.

[alecharmon]

@E3V3A brings up a good point, but I don't think grep'ing text files is a scalable or accessible solution either. @tstirrat is there a pragmatic way to implement the necessary features of firebase without risking the mission of being privacy focused?

[efalkner]

What sort of privacy concern is there with Crashlytics, provided we're not intentionally logging any PII?

[E3V3A]

@efalkner

What sort of privacy concern is there

Crashlytics can be uploading all sorts of very device specific info (incl, serial numbers etc.)

But my main issue is the extra needless bloat taking away from development effort.

@alecharmon

I don't think grep'ing text files is a scalable

I'm not suggesting running external shell commands, and since every language have built-in regex, this is trivial. I have done a lot of this before, but if you need an already working code, that even scrubs user specific data, I suggest using that built-in to the Signal app, in the logsubmit functions here.

[tstirrat]

extra needless bloat

Seeing detail of crashes, percentage of crashes and stack traces is extremely helpful to a dev. So I wouldn't call it needless bloat.

These tools group crashes into similar by comparing stack traces, and by version so you can track "issues" over time across multiple versions.... I would say this is significantly better in almost every dimension than manual log scanning. I would consider the tools to be adding a lot of value to the Dev effort and in my humble opinion "worth it" (not speaking specifically of Firebase or CL but crash tools in general)

Specifically on Firebase tools: They can be made user opt-in. I verified with Crashlytics folks if they can be useful without the broader Google analytics SDK, and the response was:

• Crashlytics can work without GA SDK, but loses a couple of user segmentation (i.e crashes by country) features

• Performance Monitoring does not need it in the first place.

Manual log scanning has another set of privacy concerns. Because I as the log reader do not have control over what you, as a developer with different needs, might have accidentally or intentionally spammed into a log.

The question still remains if users would feel more hesitation using the app knowing these things were installed even if they could opt-out. And I suppose this is a good question for the UX research team.

[Patrick-Erichsen]

@tstirrat think we can close this out?