Many people accept that free software tends to protect your privacy better than proprietary alternatives, but they may not understand why that is. This week’s news about the Audacity project adding telemetry and the public outcry is a perfect test case to explore why free software means better privacy. If you haven’t been following the story, this piece in The Register provides a good summary. In short, Audacity (audio editing software) published a pull request to add telemetry about their users as an opt-in feature to a future release. The free software community largely balked at this change and started a debate over the change inside the pull request.
To better understand why free software protects your privacy more than proprietary software, let’s contrast a few key points in this story with how it would play out with a proprietary counterpart.
Thanks for calling out the inportance of opt in vs opt out, something so simple yet very powerful.
I didnt read the entire converstation, but wish if analytics were used that there would be a reason why options like Plausible werent chosen. If there is a need for analytics I hope to see companies move towards privacy respecting options.
as an additional explanation to the potential vast majority of our readers out there - Hello world !!! - (who may not have an account on forums/Purism) what this means is that if they (the Audacity devs/contributors) DECIDE to add such ‘features’ to the code-base then free-software - on the virtue of being LIBRE (free as in liberty but not necessarily ‘free’ of resources that need to be put into developing and maintaining and advancing the code base with quality code) - means that each person from the PUBLIC CAN READ AND MODIFY the source-code (written and distributed by devs/contributors through the internet) that concerns this particular issue - ON AN INDIVIDUAL BASIS or a community fork - (maybe people that WANT to send ‘telemetry’ back to the ‘company’ can see it and NOT touch the offending code in any way or even ENABLE the telemetry-code themselves)
there is ofc a discussion to be had still on the merits of being FOR (Aye) this issue but largely i believe there is enough literature out there for anybody interested in following Alice down the Rabbit hole …
so how do you recognize such ‘offending-code’ IF it gets added (by mistake or intentionally) in the source-code that accompanies free-software (usually by virtue of the GPL license as released by the GNU/FSF) ?
i would ask if there are any developers / contributors out there that would like / KNOW how to answer this question in an easy to understand manner for the masses …
just try your best to reveal to the GENERAL audience WHAT would they look FOR once they have the source-code open inside a text-editor ( could be Nano, Gedit, Vi/Vim, Emacs, etc. there are so many out there …) and how would they search for the ‘offending-code’ …
One problem I have with opt in is that it is usually phrased as a way for the user to help maintain the software, not as “can we target you?”. User who loves program is obviously going to say, “Yes! Let’s keep great program great!”
Anything proprietary is sort of like magic pipe (a tool for herding) that Pied Piper of Hamelin used to lure lemmings over the cliff or down into the river.
Thanks, Kyle, for doing this post. It’s another one I can forward to people who aren’t sure why software libre/free software is such a great thing. I use Audacity myself, so this affected me directly. If the Audacity developers want to get some feedback on usage, they could do it as follows. Have an opt in for Audacity to collect stats in a plain text file or other human-readable format like XML. Every month or so point you to the stats file and ask you to upload it via a browser to their site (with a common URL, not some tracking URL). Since it’s a text file, you can inspect it (and edit it) before you send it. Anything happening behind the scenes is suspect and risky, and an upload-it-yourself scheme eliminates the need to add networking code bloat to Audacity.
If (Audacity) used a self-hosted Matomo I’d be perfectly fine opting-in.
Matomo, formally Piwiki, is meant to be a drop-in replacement for GA and even allows importing to make transitioning easier. It’s also under the GPLv3.
I understand that it’s a pretty complex piece of software that competes with large companies that have millions of dollars backing their products. Having a few usage metrics can be incredibly valuable for figuring out what’s actually used and how.
If they interpret the data correctly and correctly fill in the gaps for, likely advanced or GNU/Linux & *BSD, users who likely never opt-in, then it might become easier to use for newcomers and novices.
or they could set up a system that does this by way of ‘mailing-list’ type functionality without requiring java-script or cross-site embeded elements to run amok and wreak havok on user privacy.
they seem to be on the right track as alternatives to GitHub and GitLab > https://sourcehut.org/
it’s fast, minimal and employs the older concept of ‘contributions’ as is still the case with Emacs development.
you could practically use it directly with eww in Emacs without needing a proper www browser.
email is still operable we just need to bring it up to speed with modern times and requirements/integrations.
Yes, you can read more about it in Tenacity’s README.md in the Codeberg repository, but I will bring the relevant quote up to the forefront for your convenience:
I think they dropped the attempt at adding telemetry. So, yes, it was misjudged (poorly thought out in the first place and poorly communicated) but in the end amounted to nothing.
For example, if you have telemetry but you allow users not to participate (whether opt in or opt out) then it skews the telemetry anyway.
What (reportedly) remains is: if the application craps out, it will ask whether to send an error report and show you what it would send if you allowed it to do so (which you can allow or disallow on a one-time basis or on an ongoing basis via a “remember this decision” checkbox on the send/don’t send dialog box). And the error reports are self-hosted by the project rather than using an untrusted third party (like Google), as originally proposed.
It looks to me that you could in theory also edit the report before sending (to censor out something) if you wanted to.
This gives the user the choice. Don’t send the error report - and at best work around the problem, or live with it, or hope that someone else has the same problem and does allow the error report to be sent. Or send the error report in the hope that someone on the project will fix the error.
And any given distro can choose whether or not to include that error reporting code at all.
I have Audacity installed but I only infrequently use it and I don’t know how to make it crash reproducibly, so I can’t verify the above statements about error reporting. Well, obviously I could verify by looking at the source code but I don’t want to spend that time.
It describes error reports being sent to their self-hosted Sentry servers.
There is also update checking, but that seems squeaky clean to me. Then, there is this build exception to those two implementations:
This issue does not address the privacy policy changes or Contributor’s License Agreement mentioned earlier, which deal with the far greater issue of GPL violation. As a result, the Audacity developers’ reputation has severely sunk, even with their 180 telemetry turn.
Not sure that update checking even makes sense if Audacity is provided by the distro. It should be taken care of by the normal check for updated packages in the distro’s repo (and won’t need to go anywhere near the Audacity project’s web server) - unless you manually install a later version of Audacity bypassing the distro’s repo, for example.
I think the decision to use a fork is a finely balanced one - since every fork fragments the user base and spreads the developer resources more thinly.
I see forks as necessary if the upstream project is no longer making any progress towards the public interest. In any case, choice is empowering for the user, as @Kyle_Rankin’s article highlights about the benefits of gratis and libre open-source software.
Well, I have an alternative citation from the Wikipedia article, which more or less rephrases the two of the three points mentioned, but notably omits the Contributor’s License Agreement:
It was exactly after this article from @Kyle_Rankin that I stopped using Audacity, so since then I have transferred to other music production software or hardware. I did use Tenacity briefly, which is why I mentioned it earlier.
I have version 2.4.2 and the Audacity web site lists 3.4.2 as what it offers to download to you if you download it directly. (So I’m a fair way behind the times and best not ask me.)
For an open source project, you can pretty much just “firewall” it if you really don’t trust whether it is sending telemetry or error reports without your agreement.
