I’m sympathetic to both the default distrust and to devs like you who want telemetry to improve their software and won’t use the data for anything else, but it

I’m sympathetic to both the default distrust and to devs like you who want telemetry to improve their software and won’t use the data for anything else, but it is because of bad actors and enough dark ad patterns that we just can’t trust companies to play nice, and it’s too difficult to expect people to scrutinize each and every app or site individually. So I get why the default assumption is nefarious behavior. But you’re totally right - telemetry & crash dumps & analytics are helpful & great for devs who care about the customer UX and don’t use the data for advertising or anything other than fixing & writing good software, so it’s a real kind of tragedy of the commons that we can’t have safe, trustworthy, and pro-consumer telemetry. I went from building a web app that used Google Analytics and some other kinds of anonymous telemetry (and using that data only for identifying functional software & site issues), to building driver software that absolutely cannot send data out, and I wish for telemetry all the time. Not only is it difficult to understand what users are doing, they usually don’t even know themselves and can’t tell me what happened when things crash. The result is that turnaround times for critical issues are in months, when it could be days or hours if we had crash dumps and analytics, the lack of automated reporting hurts users. I’m not sure there’s a way to separate the good from the bad, to designate some kinds of telemetry as safe and to be able to trust it while disallowing the stuff we don’t want. If that were somehow possible, if anyone has ideas, I would love to help figure out how to make it a reality.