Telemetry

[YoshiRulz]

Reminded about this by natt and feos joking about crash reports in IRC. I'd briefly discussed it with adelikat a while back and came across [1], which looks promising technically but might not be suitable functionally.

Here are all the unanswered questions of telemetry in EmuHawk:

• Should crash reports be collected, or hardware/OS specs, or app usage, or everything?
  • The first is generally useful. The other two may be helpful with diagnosing certain problems (#1820), and with choosing to drop features, respectively. --yoshi
• How should users opt-in?
  • We don't currently do much (visibly) on first run. I don't think a telemetry opt-in dialog would be much of a burden, and they've become ubiquitous. --yoshi
  • I've had a brief look at Discord, and I don't like the way it's loaded at runtime. That gave me the idea of having a separate executable without telemetry (easier with .NET 5+). --yoshi
• Where will data be sent?
  • tasvideos.org seems the obvious choice. Using [1] would have Microsoft do all the work, including collection. --yoshi
• Are we in practice able to anonymise telemetry data e.g. file paths?
  • leaving this here: Stacktraces are localised in at least one configuration (net48 on Win10), so collecting the "language" datapoint may be unavoidable. IMO we should be collecting system language(s) anyway. natt at some point mentioned disabling localised stacktraces. --yoshi
• How much of the dataset will be public?
• Should users be able to de-anonymise themselves?
  • (with a TASVideos forum account, for example)
• Will EmuHawk 2.x (i.e. the first version w/ telemetry) be able to call home in 5 years' time? Should it try?

links

• [1] unofficial blog post Use Application Insights in a desktop application from 2017-03-29