Crypto | Be less blind: Analytics, reports, better logs

[BillCarsonFr]

Problem

We need more visibility on how many users are seeing crypto problems, and what are the most common cause so that we can efficently affect effort.

Solution

Get started on the journey to full observability by implementing simple analytics and better logging.

• Analytics | Port existing matomo metrics to posthog UISI Metric in Post Hog Cross Platform #34
• Analytics | Improve posthog metrics Posthog | E2EE possible error inconsistency on name cross platform, would need also to add error code in event #224
• Analytics | Create a new dedicated posthog/sentry event that better fit our needs #781
• Analytics | Report olm decryption errors (to_device messaging) Crypto | Posthog analytics for to-device decryption errors #234
• Logs | Lab option to auto report rageshakes on UTD Auto UISIs Reporting #37
• Improve auto-rage shake #114
• Logs | UX to send matching rageshake on UTD Provide feedback to sender when a recipient failed to decrypt a message #123
• Make debugging UISIs easy
  • Discovery:
    • Standardize client logs, make it easy to report issues (from sender or receiver)
    • or R&D realtime observability via Jaeger, see UISIs Observability #31
• Structured logging on clients (opentracing compatible) #32
• Analytics | Instrument verification
• Analytics | Instrument key backup

[richvdh]

See also #558

[anon8675309]

Report bug screen in the Android app: there doesn't seem to be an option for the user to view their own logs. The only option appears to be to report an issue which may:

1. send unknown data to
2. an unknown server where
3. unknown people will be able to see it
4. open a duplicate issue on the bug tracker

This results in at least some, and likely many, users not reporting bugs and not submitting logs when they do file a report.

As a user, at a minimum, I want to know:
A. Exactly what data will be sent (be able to see the contents so I can decide on whether to include it)
B. Where it will go (GitHub? some big data aggregation company? only my home server admin?)
C. Who will be able to see it (just saying it will not be publicly visible does not answer this question)

Having that information allows the user to make an informed decision and be comfortable sharing more information. This is especially important for reporting issues with encrypted messages such as #245