Defending this because "it's industry standard" is no better than justifying any wrong practice because "it's always been done this way".

My point is that it's done this way for a reason beyond the nefarious ones that people in hn always seem to assume. Engineers want this data because it helps them do their job, bit because some product person wants to use it to sell it or use it to train an ML model. There is certainly extraneous data collected because the incremental cost of doing so once you've established the pipeline is small and eventually someone does make a bad decision, but that's where we should focus our energy. Otherwise you're just making a lot of folks jobs harder because their software runs doesn't run in the cloud. An unintended consequence of this might be to push even more software into the cloud which would otherwise run on client side.

> I'd rather focus on standardizing a transparent and privacy safe way to gather these metrics. Consumers would know what metrics are collected and there would be guarantees that privacy is kept.

I'd rather see laws to have it disabled by default. People who don't mind can then opt-in again.

If we do that the relative cost of software will increase and reliability will overall decrease. This doesn't sound like a great outcome for end users who will end up dealing with both of these things.

> Honestly there are many good reasons to do so and it does result in finding real problems and solving them.

Honest question, what is a good reason to do this?

My Logitech software sends telemetry to Logitech.

My VW apparantly sends my GPS coordinates.

How is this useful for improving their hardware?

I'm not sure I can defend all choices various vendors make, but there are plenty of signals that are helpful. Precise gps coordinates seem unnecessary, but some sort of region based information can help correlate whether there is a particular problem that might happen at far higher rates in hilly terrain or specific humidity levels. Users also often use products in a way that doesn't line up with how the product owner thinke it should be used. Metrics don't replace interviewing people but it might help you craft the right questions. In the case of a Logitech mouse, it might be useful to understand if people are actually using those extra features you've added or maybe it's worth removing in a future version.

The most obvious metric that everyone wants to know is failure or crash rates. After a software update it's always good to know if those rates went up. Those errors may be recoverable, but it's good to try and understand them to improve reliability. Maybe pairing android auto with specific phone models is more problematic, or maybe trying to pair Bluetooth is particularly bad under specific conditions like high thermals in warmer climates. It's pretty difficult to interop testing with all possible parties in all conditions.

> some sort of region based information can help correlate whether there is a particular problem that might happen at far higher rates in hilly terrain or specific humidity levels.

You know what will help in those situations ? Testing.

It is expensive, i know. Why not skip it and just analyse the KPIs from the telemetry. /s

Testing is not really an economically viable option in all cases. Ecosystems are simply to diverse and products are so complex that covering every case is not really possible. There is likely no software you use today short of projects like sqlite which don't leverage user reported bugs or telemetry to improve the software.

> Honestly there are many good reasons to do so and it does result in finding real problems and solving them.

Tell that to Microsoft. Although their products have telemetry, they become shittier every day.