These past few days, wherever you look, there’s a lot of bickering around Audacity and its new desktop privacy notice. If I wanted cheap attention grabbing, I’d probably follow in the lead of some other news outlets and go for something like “Audacity Is Now A Possible Spyware, Remove It ASAP” (an actual title, you can look it up). But I think it’s time to have a level-headed discussion. Let’s try this in an FAQ manner.
Audacity team is introducing two networking features in the next release of the application:
-
Error reporting
-
Checking for updates
Because both features involve transmitting your IP address, and IP address is considered private information under GDPR, Muse Group is legally forced to take certain steps to protect themselves from million dollar fines in case something goes pear-shaped with the data they collected.
Your IP address and basic data about your computer (see below) will be transmitted to Audacity’s server because 1) it’s how HTTP works, and 2) it’s what makes crash reports useful.
IP address is claimed to be preserved for 24 hours only. The basic data about your computer will be stored in the bug tracker until it is destroyed for whatever reason.
That is currently the extent to which your personal data is affected.
One of the problems that software developers face all the time is that some users would not upgrade to a release with fixes because they don’t know there’s a newer version available. That’s why it’s a common practice to add an update checker — to notify users that a new version is out.
Linux users who commonly get their updates from a centralized software repository have less incentive to use this feature. But most Windows and macOS users don’t have this sort of centralized software repo where you can upgrade all software in one go, so they actually could do with this. Steve Daulton, one of Audacity’s contributors, claims that auto-updates are 17th all-time most commonly requested feature.
Naturally, some people pointedly avoid upgrading, which is why it is also common to provide a toggle to disable phoning home to ask if an update is available. The next Audacity release is going to have this toggle. Here it is in the 3.0.3RC2 AppImage build:
Another common problem that software developers face is getting sensible bug reports from users.
“Your program crashed! Help!” — not an immediately actionable report.
“Your program crashed! Here is how and where you can reproduce it” — an immediately actionable report.
For a crash report to be useful, it has to contain basic information about the machine this crash occured on: CPU, operating system name and version. This is how errors can be reproduced by developers. If a bug only happens on e.g. Linux running on an ARM64 processor, this significantly reduces the amount of time it takes to look into the issue and fix it.
The report will also have to contain error messages produced by the program at crash time. Sometimes the crash log would contain paths to files, but this can be obfuscated (in a trivial or not so trivial manner). The Audacity team, however, does not say if obfuscation would be done (or needed).
Crash reports will be submitted in minidump format that Google borrowed for Breakpad from Windows. There is a public specification of that format available. You can study it in your leasure time.
Not really.
Transmitting basic data like an IP address is how Internet works. Whenever you visit a website, the server it runs on will see your IP address and your user agent (e.g. Mozilla Firefox). So whenever Audacity requests information about availability of a newer version, it also sends your IP address and your user agent (which is Audacity). Peter Jonas provided an example of that:
GET /feed/latest.xml HTTP/1.1
Host: updates.audacityteam.org
Accept: */*
Accept-Encoding: deflate, gzip
User-Agent: Audacity/3.0.3 (Windows 10_0_19042; x64)
If you see someone suggesting that you should remove Audacity if you care about privacy, ask them, if they also removed their browsers, their email programs, their Twitter mobile apps etc. All these programs know vastly more about you than Audacity does, and they send the same data to respective servers (way more data, in fact).
Seriously, one of the news outlets that went for the throat of Muse Group over privacy actually uses Google Analytics to track visitors. But I digress.
A crash report without basic environment data is possible, but not really helpful. Even if you submit it, you will likely be asked by developers to specify your operating system name/version, version of the program etc. anyway.
More bug reports. Better bug reports. Instantly available useful data to investigate a crash.
The point of free/libre software is not to gratify those users who get to send a detailed bug report manually. It’s to make great software that is free to use and study for everyone, forever.
Yes, you can rebuild Audacity with all networking features disabled. You don’t even need to use any build configure switches for that. On the contrary, you need to enable networking if you specifically want that in your custom build.
If you rely on the official build for Windows or macOS, you have to opt out of networking features.
If you rely on you distro’s build of Audacity, you most likely won’t have to do a thing. They will probably just build it without networking features. That remains to be seen.
Both options are technically possible. You probably want asking yourself some questions here though. Like this one.
What kind of advertising agencies would want to enrich their databases with information on availability of Audacity on someone’s computer? Audacity project isn’t Facebook, or Twitter, or YouTube. It has no way to figure out your interests, your income level, what car you drive, whether you are down on your credit card payments, how many kids you have, whether you are faithful to your partner etc. All it knows is that you have Audacity installed on your computer and you ran it within the past 24 hours.
Moreover, Audacity does not collect information about your use of copyrighted music to send it to copyright holders. It’s GPL code, you can audit it.
I’m not sure how much use it would be for a law enforcement agency to know that someone sitting on a particular IP address recently had access to Audacity, but please do share ideas with me if you can think of any. I like a good theory as any other guy.
GDPR article 8 says:
Where point (a) of Article 6 applies, in relation to the offer of information society services directly to a child, the processing of the personal data of a child shall be lawful where the child is at least 16 years old. Where the child is below the age of 16 years, such processing shall be lawful only if and to the extent that consent is given or authorised by the holder of parental responsibility over the child.
Member States may provide by law for a lower age for those purposes provided that such lower age is not below 13 years.
The controller shall make reasonable efforts to verify in such cases that consent is given or authorised by the holder of parental responsibility over the child, taking into consideration available technology.
IP address is considered personal data under GDPR, and update checker is an opt-out feature. Which suggests that a minor using Audacity with default settings is a potential legal nightmare. Hence the recommendation, I assume.
Now, one solution I’ve heard — and I find it a generally sensible idea — is that Audacity could ask the user for age confirmation and then enable or disable networking features accordingly. Judging by 3.0.3RC2 build for Linux, the expected consent confirmation dialog hasn’t materialized yet.
It’s unclear. You’ll hear a bunch of “IANAL” followed by assumptions both supporting and dismissing this idea. But until FSF weighs in with commentary, it’s hard to say.
Yes. E.g. both GIMP and Ardour have an opt-out update checker. Both apps will ask project’s server for a number of an up-to-date release number, and if the currently installed version is older, user will be notified of an update.
GIMP’s implementation is done on two levels:
-
You can disable update checker entirely as a build option (it is on by default). Linux users who mostly rely on binary packages in their distribution repositories will probably use a build of GIMP where this feature is disabled. Windows and macOS packages are provided by developers, this feature is built into the software.
-
If this feature is built into the program, you can disable it in the Preferences dialog.
Ardour’s implementation is now a three-level one:
-
You can use a build switch to disable phoning home entirely.
-
You can run Ardour with
--no-announcementsswitch to disable checking for updates. -
Since last night, you can also disable this feature across sessions even when it’s built into the program, there’s a new option in the Preferences dialog for that.
With update check enabled, respective gimp.org and ardour.org servers will only see an IP address and user agent. In case of GIMP, the request header data will actually go through a network balancer first. I’m given to understand that it makes the header data less meaningful, and it’s stored until the next website rebuild (gimp.org is currently running on a static website generator called Pelican).
Also, what do you think happens when you click any help links on FreeCAD’s start page, and the web site opens? What happens when you enable news feed on your Krita startup screen? Your IP and user agent data gets transmitted.
Yes and no.
They haven’t done anything new in the free/libre software domain. It’s not the first free/libre application to phone home to ask if an update is available. It’s also not the first free/libre software to generate a crash report and send it to developers.
Audacity is still available under the terms of GPL. All the networking code is opt-in at compile time, as well as free to study and modify at any time.
Where they failed is communication of changes to users. I thought they learnt the lesson after the first telemetry controversy. But, once again, they provided some basic explanation only after the proverbial shit had hit the fan. This could be easily avoided, same as the first time.
Similarly, they didn’t have to be so vague about information that would be transmitted to authorities upon request.
Personally, I do not like their way of handling public relations. But not liking their (lack of) PR strategy and accusing them of all the things people accuse them of are two things that are worlds apart.
There is technically no way to know for sure if access log to the website would stay intact and never sold to anyone. But this is speculations territory, one I’m personally not comfortable with. But give me facts, and I’m a happy puppy.
When explained badly to people with little knowledge on how things work IRL, the networking features in Audacity sound like surveillance, and noone really likes that (unless it’s part of the plot in a good cyberpunk movie, meaning, it’s not real and you are watching it from the safety of your couch).
The news is also commonly blown out of proportion by the part of the media that thrives on clickbait.
One thing I certainly don’t get is how several vocal commenters on the privacy thread refuse to let Audacity submit their IP adress to Audacity’s server, and yet they had no problem submitting their real name, city and country of living to GitHub, that is to say, to Microsoft.
Too early to tell. Both new forks of Audacity were done by people who don’t seem to have experience programming software of this kind. So far, their changes boil down to rebranding and removal of networking features they dislike. They are also asking for help.
If any of that sounds familiar, that’s because it is. Earlier this year, Glimpse project was put on hold because it failed to attract any actual contributors willing to maintain it (let alone write new code). So two likely scenarios, in my opinion, are:
-
Some forks will continue shipping old Audacity code, without all the new features and without much (if any) original development going on.
-
Other forks will attempt to follow upstream development of Audacity, re-patching it for networking features removal.
I’ve seen both scenarios with GIMP over the past 10+ years where people forked it because of toolbox menu removal, save/export separation etc. None of that ended well for the forks.
So no, I don’t believe in a sudden rain of contributors all over the forks. But I don’t mind being proven wrong (wouldn’t be my first time, either). And I absolutely support exercising one’s software freedom to fork and modify.
If you still have concerns, you have three obvious options:
-
Don’t upgrade to a newer version of Audacity as provided by the project in a ready-to-use package (Windows/macOS installer, AppImage etc.).
-
Don’t build further releases of Audacity with networking features (they are disabled by default anyway).
-
Opt out of networking features when using a ready-to-use package of Audacity as provided by the developers.
No concerns? Even better!
Babkes.
This is a companion discussion topic for the original entry at https://librearts.org/2021/07/audacity-privacy/
While a user expects that those programs use something as a communication medium (e.g. the internet), that’s not the case with offline tools. Me, I wouldn’t expect GCC to phone home on every run or share a bug report on ICE, and would be negatively surprised if it did so.
