> but only if you collect the data.
If the problem is impacting the user and they want it fixed they'll happily tell you. This bug (which causes crashes) would've been investigated just as well by asking users "Firefox has crashed - send bug report?", while giving the user the choice to decline if they had sensitive data in the browser's state.
Obviously nobody in their right mind should opt-in to generic telemetry because all the "product improvements" excuses never panned out - in the last decade software has only become worse, more annoying, and less feature-full, so people are making the rational decision and are not opting into something that's not actually benefiting them. But opt-in telemetry in specific cases where the user actually has a problem like this occurrence can work just fine.
Even when not abused to violate our privacy, the end result is often highly questionable. In place of good design, common sense, and user studies, companies try to extrapolate trends/patterns from data where there are none, resulting in mediocre decisions at best, and self-feeding cycles of devolution. ("Users are clicking this button a lot, let's make it larger" - users are actually clicking the button by accident.)
Telemetry doesn't have to be 100% anonymized - it can (and in some cases needs) to contain PII, just needs to be collected respectfully and transparently. Ask the user before sending something, and let the user review it. The user can then make their own decision.
I under The sentiment, but say you were sending a memory dump as part of your crash reporting. How is a user going to review that?
It's not feasible for a smaller developer, but it wouldn't be unreasonable for Mozilla to have a big lab bench with like 100 different devices on it that are just constantly running a script to start Firefox and load a suite of test sites.
Without substantially increasing the cost and work to maintain the test pool, you'll be testing exactly one combination of OS version/patch level/settings, one internet connection medium/carrier, one set of browser config options, etc for each device in the pool.
The investigation into any fault isolated to a single device in the test pool has to start with suspicion of the health of the specific device. The test S20 crashing doesn't tell you that every S20 will crash in the same way, it could be an isolated local fault. Yes you can throw more devices but that's further increasing the cost and effort of maintaining the test pool.
Android has an immense variety of devices. Without a representative sample, you wouldn't know which devices to buy. Regional variants sometimes have a huge difference and sometimes not; this bug seems to be tied to non-US Samsung flagships, which you might not buy if you're US based and don't know what people are using.
I'm not saying bad actors don't exist, just that telemetry is often used for good, with no nefarious goals.
Telemetry is probably just one more excuse to ship crap in the first place.
You spelled 'send crash dumps with the user's permission' wrong.
Useful for what? We've had an explosion of telemetry and "analytics" the past decade and software quality and functionality has only gone downhill. In some fields we've outright regressed compared to early 2000s tooling.
A simple example is that despite all the telemetry, manpower and tech innovation, every single mainstream communications product out there is inferior to pre-Microsoft Skype (despite the latter being built with much less manpower and running on much more primitive hardware & bandwidth).
Of course, not all of this devolution is to blame on telemetry alone, but I disagree that telemetry is some sort of requirement or game-changer when it comes to software quality. We've successfully built good quality software before it and within reasonable budgets.
I do agree that it seems that despite increased capabilities across the board and piles and piles of newer and better ways to do things, the quality of consumer software has dropped somewhat.