F40 Change Request: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

I won’t rehash what others have said. But I think it is important to examine why we are at this point, discussing opt-out telemetry in a historically fiercely free Linux distribution.

The above argument by Adam is very important. I’ve been around Fedora for more than a decade, and I was drawn to it because of its community engagement. However while today’s Fedora releases are more bug free than say 2010, I would still prefer the 10 year old project because then I could open a BZ report, and get a human to respond. Now only RHEL relevant reports get human responses. As a result, my participation in the community has also reduced (that includes the mailing list, and here). The alternative to telemetry isn’t easy, but wishing for telemetry is a dehumanising crutch popularised by corporations.

That said, some more specific comments:

  1. Anyone affiliated to RH should declare their affiliation when responding to this thread. While reading several of the “in-favour” responses I realised they are RH employees. It wasn’t immediately obvious. This is important, since apparently internal RH goals are influencing this proposal:
  1. The proposal asks for building surveillance infrastructure into the OS, and the only check against abuse is a “promise” to adhere to agreed processes. What guarantee does a user have that malware won’t target this OS level infra for abuse? How about proprietary software people might use on Fedora, how will a user ensure they are not abusing this infrastructure?

  2. The implementation detail of how this will work, a project wanting telemetry will depend on eos-* packages. I suggest also requiring this dependency to be a “weak dependency”. I do not want to trust my privacy to a UI toggle. The user should have the ability to exclude all telemetry packages from their system with something like excludepkgs.

  3. Why will the aggregated data be gated? As with everything Fedora, it should also be open to users to use. I can see two reasons, 1) the users played their part in creating the dataset, so they should have access to it (a reasonable check could be requiring a FAS account), 2) only if it’s open we can inspect it and verify if it is still privacy preserving after aggregation (I think this was pointed out in one of the responses: privacy preserving at collection is not necessarily privacy preserving after aggregation).

  4. What is the process for notifying users on any changes in the collected data points? A user might agree to providing info about their editing behaviour, but not the languages/platforms they use in their projects. I’m deliberately choosing development as IDEs were mentioned in the proposal, but this can be extended to anything else.

  5. Dismissing GDPR is naïve. Under GDPR, the user has certain rights, you cannot dismiss it without discussion.

7 Likes