Will there be anyway to turn off that telemetry? In Windows it is easy. But in Linux, I think it will be much harder. If Fedora devs introduce an easy way to turn it off, then good, otherwise it might be a big ‘NO NO’ for many loyal users.
Ofcourse, this page explains the proposed process:
https://fedoraproject.org/wiki/Changes/Telemetry#Current_status
So where to after Fedora?
From what I hear, it’s going to be simple, opt-in telemetry, like what KDE Plasma already offers to collect. I’m quite sick of people making a mountain out of a molehill with this. If you don’t want it, don’t turn it on.
One of the goals I have is for no network traffic to occur unless I specfically initiate it. This is a security posture and a way to effectively present at meetings without supprises ie: forced install of updates like with MS products.
I suggest testing no matter what OS you are attempting to determine if data is being collected. Every time MS products were tested, no matter how may settings and registry hacks were employed, it would collect telemetry or not run at all. Do not trust anyone. My favorite place to test is a monitor on the network switch or wifi access point.
Fedora employing an opt-in is nice. A command to initiate data collection/transfer without any auto transfer would also be nice. I am expecting the auto collection default will be something I can disable.
In all cases a detailed review of the data will be something I deem necessary before I ever agree to transfer it. I expect there will be a way to keep the installation process from doing telemetry stuff too.
100% agree with you on this.
The page linked just 3 posts above gives a full description of the proposal including a detailed description of the telemetry data and the user control of what is submitted.
Remember that this is FOSS so whatever is finally approved can still be reviewed at the code level to verify it does exactly what is stated – no less and no more.
I follow the guideline ‘trust but verify’ in all cases and excessive paranoia is limited by that practice since everyone knows that what is promised will be verified.
All the above was off topic for the original thread so it was moved here.
Telemetry is proposed but not yet approved and the link in 2 above is the full proposal with details. It includes the data to be collected and how users can manage it (with opt-in only).
Lets not allow paranoia to bloom here.
That’s the first I’ve heard that I’m content with just setting AllowTelemetry
to 0
but I see other MS/Windows apps still having settings for optional data sending making me think there’s plenty of other stuff around not honoring that.
I’m kind-of iffy about whether the data I’d submit to Fedora would be that useful, but I’m not exactly against passively giving statistics. I do some weird non-default/standard stuff and like the idea of someone seeing that and improving the experience to either auto-do some of that or make it not needed
In windows I can only reduce the telemetry not turn it off.
And that is only for some of the Microsoft stuff.
Other apps like games launchers have no controls and force being on-line.
I don’t know but I have a github script which disables all the inbuilt telemetry of the Windows OS and regarding games, I always tell people to play offline games. I personally play some games which are offline and I turn off the internet before starting the game and if by chance my internet connection remains on, I block all requests from the game with firewall.
Keeping a PC safe from numerous security threats these days is difficult.
Having Telemetry specifically designed for the current release of an OS easily available adds risk - it’s an attractive attack surface that clearly has the potential to be exploited in attacking a PC even when the user has chosen not to install it themselves.
- Pretty obvious when you consider the fact that most malware victims don’t deliberately chose to install the malware.
- The intentions of actors in the public view aren’t really that relevant.
So if there’s a distribution that avoids this risk it has an advantage and other things being equal I will go for the lower risk Linux distribution.
The “we know you don’t like this but we know better than you that it’s actually OK” attitude is not going to assist in building a user base.
Of course malware professionals can already, and probably are, trying to work out how to leverage Endless OS to attack Fedora and other Linux systems for nefarious purposes - which is why responsible designers of such Linux distributions should be offering tools to harden your system against this pestilence, not modifying the distribution to facilitate an infestation.
The fact that I have to point out any of the above tells me that those who are leading the push don’t know how to do their job properly – that’s another clue it’s time to part company with Fedora.
I’m not really interested in debating this any further or responding to abusive labels. If you see it otherwise, you do you.
A few more random observations:
-
None of the proposed uses are essential and the information can be gained to some extent via other means and/or the design problems addressed in other ways - which is relevant when you weigh the risk (publicly distributing source code for a useful attack surface for the OS) vs the benefit (information that isn’t really essential that we can to some extent get via other means):
“we want to know things like which IDEs are most popular among our users, and which runtimes are used to create containers using Toolbx.”
“Metrics can help us understand the hardware we should be optimizing Fedora for”
“Fedora localization wishes to count users of particular locales to evaluate which locales are in poorer shape relative to their usage.” -
If it was my job to design malware to attack an operating system then, looking at a description of Endless OS, I would be pretty keen on developing exploits that socially manipulated users into agreeing to install a modified version of this stuff:
“On Endless OS, applications use a D-Bus API (via a small C library, eos-metrics) to record metrics events locally on the device.”
“This API is implemented by a system-wide service, named eos-metrics-event-recorder or eos-event-recorder-daemon (no, I don’t know why it has two different names either), which buffers those events in memory, and periodically submits them anonymously to a server, Azafea, which ingests them into a PostgreSQL database”