3 ms·
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 w
by dtx1 6y ago
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
- oarsinsync 6y ago> 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.
- slg 6y ago>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.
- dtx1 6y ago> 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.
- slg 6y ago>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. The article is specifically about the mobile OSes and the default apps and services. I'm not sure why your general complaint about third parties using FAANG tracking is relevant here, but I have no argument against it. >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. You are doing the same thing again. You are assuming a level of "work just fine" without having a comparison for what it would look like with telemetry. Ignoring the privacy issues for a second, can you say definitively that Linux would see no technical improvements from developers having access to telemetry data? >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?". Because the benefits of telemetry are widespread while the downsides are localized. The incentive for an individual user to participate is low and isn't well understood so they will default to off. Expand that to everyone and you end up with the tragedy of the commons.[1] It has nothing to do with skulls on a cap, it is basic individualized economic incentives playing out that lead to less than ideal results for the whole. >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. >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. Once again you are returning to bugs. This is about more than just bugs. Very few pieces of software are published and then abandoned beyond bug fixes. Today most software needs to constantly evolve and add new features. Maybe you are the type who will request those features from a developer in official channels, but that isn't common. Also most users will simply decline when presented with the option to submit a bug report. They just don't see the a strong enough or immediate enough connection between a bug report and the bug being fixed. I would bet any developer who has spent time informally talking to their users would have heard some complaints about their software that were never previously voiced through official channels. That is just the nature of things. A developer will get more valuable data if they don't leave the sending of this information up to the whims of the user in the moment when a bug report screen might appear in front of them. [1] - https://en.wikipedia.org/wiki/Tragedy_of_the_commons https://en.wikipedia.org/wiki/Tragedy_of_the_commons