Comment by wmichelin
4 years ago
I disagree that telemetry is inherently bad. As product engineers, telemetry is often our only visibility into whether or not a system is functioning healthily. How else can you detect difficult-to-spot bugs in production?
> our only visibility into whether or not a system is functioning healthily.
Your problem here is viewing the end user's setup as part of your system.
It's the user's private system -- why should you have any visibility into how it is functioning?
They said a system, not their system.
Car computers report telemetry to mechanics, and given that digitization allows for economies of scale, this isn't that different.
> Car computers report telemetry to mechanics
Yes -- and they shouldn't.
3 replies →
As a software engineer I disagree. You are saying that you want to collect my personal information so you can fix your bugs. I don't see it being a valuable trade. I'll just find someone who can fix their bugs without tracking me.
>You are saying that you want to collect my personal information so you can fix your bugs.
How do you define personal information? Let's use Chrome as an example. Recording what website I visit is clearly personal information. What about recording how many tabs I have open, how much RAM each tab is using, and when each tab was last viewed? Is that personal information to you? I personally don't value keeping that private and it is probably a valuable piece of information that could help the developers improve what has been one of the biggest user complaints about Chrome since almost its release.
I think that is generally OP's point. Each piece of data exists on a spectrum in value for both the user and the developer. Data should be kept private when it has value to the user. There is little harm in sharing the data with the developer when the user would deem it low value and the developer would deem it high value.
It's pretty easy to understand what information is technically static and could be used to track you. Number of tabs: low possible range and pretty variable, even for tab hoarders, so it's low entropy information. Amount of RAM used in each open tab: that should be statistically significant and I'm pretty sure could be used to identify people if there are enough tabs open for a long enough period. When each tab was viewed: every (not-)clicked tab is a bit of information, you don't need much to narrow down a person. Interesting reading on de-anonymizing people on seemingly anonymized data: https://www.wired.com/2007/12/why-anonymous-data-sometimes-i...
2 replies →
Personal information is a bit nebulous. Do we consider the list of function calls in a stack trace "personal information"?
If I sent the stack trace to you, no. Otherwise, yes. It's my stack trace after all.
(Perhaps "private" not "personal" is a better term here, but stack traces can expose personal information too, if they include details about function arguments.)
For me, the point is really about control.
These companies know people don’t actively want to be surveilled which is why they sneak this shit in instead of being upfront about it.
If it was so great for consumers it would be an opt in not an opt out hidden behind a series of dark patterns.
Even Apple switches Siri back on after every OS upgrade.
+1 to this. As long as proper privacy concerns are addressed and the data gathering is imperceptible to the product experience, telemetry signals are immensely valuable for improving the product in a variety of ways.
Many users care more about their privacy than your product.
Certainly true, but it doesn't counter the original claim: Anonymized telemetry collection with proper privacy considerations can have a net positive impact on the product.
1 reply →
So why does $product need to send telemetry data via google? Why can highly complex software that runs most of the worlds internet infrastructure (linux) work without telemetry? Why is telemetry not opt-in or relies on reports in situation where a bug causes an issue like firefox crash reports? I'd rather have privacy and buggy software then bug free software in exchange for no privacy at all
>So why does $product need to send telemetry data via google?
Because Google is responsible for most of the software on said product. Who would be receiving that telemetry data if it wasn't Google?
>Why can highly complex software that runs most of the worlds internet infrastructure (linux) work without telemetry?
First, this is a false premise because it ignores the potential that telemetry could help improve this software but most Linux distros have decided against it for other reasons. Secondly, it ignores that some distros do in fact include telemetry.
>Why is telemetry not opt-in
It probably should be when it comes to something that has potential to invade privacy, but we have to be realistic that practically no one will actively turn on telemetry if it is initially set to off. That drastically decreases the value of the collected data and it basically turns into nothing more than something customer service can tell someone to turn on while trying to troubleshoot a specific issue.
>or relies on reports in situation where a bug causes an issue like firefox crash reports?
Telemetry isn't just about bugs. It is also about guiding future development, knowing what features are used, knowing the workflow for users, etc. It can provide value beyond crash reports.
>I'd rather have privacy and buggy software then bug free software in exchange for no privacy at all
This is completely fair. I would generally agree with you and bet that most HN readers would too. However this is not a binary choice. Not all telemetry is inherently bad. Not all loss of privacy is inherently damaging. This is a complicated issue that will involve compromises and anyone sticking to a complete extreme of it being all bad or all good isn't going to offer anything productive to this conversation.
> Because Google is responsible for most of the software on said product. Who would be receiving that telemetry data if it wasn't Google?
Depends, on Android maybe. On my Android Device, not really i don't use google software with the exception of the core android system without gplay services. On iOS, the HTML Based Web, or Desktop Systems, I see no need for google to exist. If you need telemetry, run your own damn telemtry server instead of feeding the FAANG Privacy nightmare even more.
> First, this is a false premise because it ignores the potential that telemetry could help improve this software but most Linux distros have decided against it for other reasons. Secondly, it ignores that some distros do in fact include telemetry.
Distros may, Linux itself does not. The fact that the majority of Linux Distros work just fine without telemetry shows that large scale software developement and deployment work just fine without invading peoples privacy needlessly.
> It probably should be when it comes to something that has potential to invade privacy, but we have to be realistic that practically no one will actively turn on telemetry if it is initially set to off.
so, if given the fair and free choice everyone will chose against telemetry? And that doesn't make you ask yourself "are we the baddies?".
> That drastically decreases the value of the collected data and it basically turns into nothing more than something customer service can tell someone to turn on while trying to troubleshoot a specific issue.
So, wheres the problem here? Sounds EXACTLY how a good telemetry system should work. If the bugs don't bother the users there's no need to invade their privacy to fix them, if they do bother them, telemetry can be a tool to help them. There's no need to generate "valuable data" except to invade peoples privacy.
> Telemetry isn't just about bugs. It is also about guiding future development, knowing what features are used, knowing the workflow for users, etc. It can provide value beyond crash reports.
Why is it any of your effing buisness what my workflow is like? If i need a feature i request it. This shit is only accepted because the majority of users lack a meaningful understanding of the depth of invasion by app and web developers into their privacy.
3 replies →
This argument does not hold because you can compare Google to Apple (in this case and based on the article) and say that if this was the case, then Apple which gathers less data would have inferior (more bugs, slow feature development, etc.) than Google. I see the competition, which is Apple in this case, doing relatively fair without (presumably) gathering as much data, therefore I absolutely don’t buy this claim.
2 replies →
> I'd rather have privacy and buggy software then bug free software in exchange for no privacy at all
Unfortunately, nobody offers bug free software in exchange for no privacy. It’s still buggy.
We’re increasing the risk exposure for every user for our own trivial convenience. It is inherently bad, just like other forms of widespread surveillance that is often motivated by some seemingly good cause, like catching terrorists.
Telemetry is inherently bad if it's not done with the informed, opt-in consent of the end user whose data it's (mis)appropriating, oftentimes silently.
There's no issue with opt-in telemetry, where the user says "yes, it's okay to track me".
Invisible, silent, always-on telemetry is actually just spyware that's been mislabeled.
Ultimately it's not the telemetry that's at issue: it's the unethical and selfish behavior of the software/device manufacturer.
No sane or reasonable person thinks that an EULA is informed consent.
Once upon a time fixing bugs in production didn't happen because the product got all the bugs out before production. If it had bugs in production, the product failed.
You used the phrase "once upon a time", a common opening for fairy tales, which seems apropos for describing a magical land where products achieved a 100% bug detection rate before release. I suppose this might have been true 50 years ago, at the dawn of the electronic calculator, but that is now an age of legend...
I've often wondered about this commonly repeated belief that software of ~30 years ago was less buggy than software today, because it doesn't really line up with my memories. There's definitely part of it that comes from a standard "back in my day", rose-tinted glasses sort of thing.
But I actually think a lot of it comes from the fact that modern software can be easily patched, whereas older software couldn't. It is easy to believe that software today is buggier because of just how many patches we get for it. But back in the day, any bugs that existed in the product were not as visible, because we weren't getting weekly updates where the patch notes say "Bug fixes."
How many massive vulnerabilities existed in major products of the day, and continued to persist unnoticed by all of us because of the relative impossibility of patching them out?
On top of that, modern software is simply more complex -- often times an order of magnitude more complex. (Whether this increased complexity is always needed/appropriate is a separate question.) I'm not sure what metric you would use to be able to do a "bugs per complexity unit" sort of comparison between then and now, something that attempts to control for increased complexity, but my intuition is that it would be pretty flat.
When that was true, several decades ago, products generally had upwards of 2 years of design/architecture/engineering effort and definitions prior to another 3-5 years of development.
It still (sometimes) happens for medical, aerospace and other transportation software that interfaces with hardware where safety is a concern.