Libre Arts - The audacity of privacy

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:

  1. Error reporting

  2. 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
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:

  1. 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.

  2. 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:

  1. You can use a build switch to disable phoning home entirely.

  2. You can run Ardour with --no-announcements switch to disable checking for updates.

  3. 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 and 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 ( 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:

  1. Some forks will continue shipping old Audacity code, without all the new features and without much (if any) original development going on.

  2. 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:

  1. 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.).

  2. Don’t build further releases of Audacity with networking features (they are disabled by default anyway).

  3. Opt out of networking features when using a ready-to-use package of Audacity as provided by the developers.

No concerns? Even better!


This is a companion discussion topic for the original entry at

:unamused: 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.

That’s a relief. :+1:

Thank you very much for your assessment of this delicate topic. There’s a lot of truth in it, but I want to add some additional comments as I feel that some aspects are not getting the attention I would give them.

Using software is all about trust and confidence. The software has access to all my sensible data such as the last bank statement and less dressed images of my wife (just to give examples, ymmv). Some people do trust big companies such as microsoft and apple. I personally trust the libre software community more for reasons that have already been discussed. I might be wrong, and the others might be wrong as well. The point is, it’s about trust.

So for me, there is some difference in what data I transmit to a website via my browser, which should properly prevent my other data from being exposed to the internet, and an arbitrary binary I am natively running which can access all data.

I do decide which browser I trust, and I do decide which data I give to web sites. This is under my control, at least to a degree that gives me confidence. Risky? Yes. More risky than trusting microsoft or apple in general? Probably not.

When a software company actively adds to their privacy notice, that they are collecting data, which they are going to use for whatever purpose, and in particular that they may give it to authorities for prosecution, rings all bells in my head. I mean, for the latter, there are laws. There is no need to add this to the privacy notice if there are laws.

I mean yes, this is for sure mainly a PR fail, and not a technical. However, it shows some attitude and therefore directly interferes with the trust and confidence topic. It’s not a big company, and if they are pro-actively telling what data they might use for purposes that are not quite required for development, they might not fight for the user data in case of a request from official side or if somebody waves a big check.

Removing from the privacy notice a hint that they are not interested in selling personal data also reveals an attitude.

Is there some consequence for me personally? Probably not, for the reasons you gave. Do I like the attitude? No.

Is all of this really a fail? Follows it a “also bad publicity is good publicity” thing? I can hardly believe that the triple fail is really a fail. I mean, how naive can one be? Weird.

1 Like

Don’t forget that laws are different depending on jurisdiction. So someone in America shouldn’t be expected to know about GDPR (an EU regulation). I think it is a good idea to be explicit even if it requires restating a local regulation in a privacy notice. Some laws even require you to state the law in the privacy notice.

Yes, these aspects also came to my mind. But with the proper wording and a more sensitive communication to the community, this had the chance to be a no-issue. Opportunity missed (or not, depending on what the purpose was).

This sounds like a non-issue to start with for me. I would have understood if the discussion was about update-checks and error-reports being opt-out instead of opt-in. I do not understand how everyone is mad about a privacy policy. Privacy policies are the same as terms & conditions: A load of bullshit to comply with bullshit regulations. In the end what counts is trust and if you have money & time: laws&courts. If you write anything into a privacy policy that isn’t lawful, the privacy policy is null. If you go against your own privacy policy, but stay within the limits of the laws - you will lose trust, but are otherwise fine. I recently needed to add a privacy policy to an app where one goal is to improve user privacy by syncing data without letting any 3rd party collect data on users. Well google made me write weird bullshit until they accepted the privacy policy, while the actual privacy policy could have been: “We care about your data, that’s why we don’t collect your data - bye.”.
Seriously: Focus on their action. Check what they are doing. If they are benefiting open-source software and not doing shady stuff (bad communication is bad, not shady), they are doing good. At least in my books.

I see no problems with update checking and crash reporting. This is exactly what we did in Natron, we got no complaints, users wanted this feature (and could easily disable it in the settings if they wanted to).


Nice to see a level headed, informative and well written review.
Minor correction. Steve Daulton actually said that “Better ability to update” was the 17th most popular feature request (referring to the old feature request log).
“Better ability to update” could encompass a variety of means, including auto-update, auto-update notification, notify on click …
Audacity has had a “click to check for updates” feature for quite a few years (it’s just a link to a web page that opens in your default web browser), but that relies on you remembering to check on a regular basis, which very few people do :wink:


This is a sane and good article that people should read. And I agree that muse group did the communication part wrong. It should be a case study for companies about how not to communicate with FOSS communities when taking over a project.

Another thing I came to know is that the audacity devs have forked some dependencies like Wxwidgets, and it has to be patched by the distribution packagers to bring the latest audacity to Linux users and arch people don’t agree with patching stuff so the version in Arch repo is outdated. I hope muse groups also learns more about how to work with FOSS communities and does things in open with consultation of the community.

Thanks, I’ve just amended that bit, will go live in a short while.

When I seen the news article headline online I was a bit shocked, but then as I dug I found out the “news reporter” who wrote it obviously blew things out of proportion, IMO.

As mentioned here, many apps do send info, etc to check for updates so it seems odd to get upset about Audacity doing it. I also agree with those that said it is a matter of trust and attitude -especially for a well-established OS project like Audacity.

The one thing that trips me up though, is the fact that there has to be an age checker. It feels like having to do a recaptcha outside of the browser…which seems silly for an audio editor.

Maybe the solution would be to have it OFF by default and allow users to “auto-check for updates” if they want. That way, it’s opt-in and no age checker needs to be shown to the majority of the users. :slight_smile:

The thing is, anything that is off and can only be enabled via Preferences dialog is barely discoverable.

Back in May, there was a plan to have a startup screen asking whether to enable networking features or not. I hope they will get back to working in that direction.

1 Like

Agreed. :slight_smile:

@prokoudine - Alex the latest alpha test build for release-3.0.3 build now shows this dialog on first launch of 3.0.3



1 Like

And Application prefs has this:


On by default - but easily turned off (before any data is sent)


That might just do it! Let’s see how users respond.

1 Like

The revised (finalised) Privacy Policy for Audacity 3.0.3 and later has been published by Muse Group today: Update to Our Privacy Policy & Apology · Discussion #1353 · audacity/audacity · GitHub

@prokoudine - Alex I hope you don’t mind but I put a link to this sane and sensible review of yours on The Wikipedia Audacity page: Audacity (audio editor) - Wikipedia

Thanks, I probbaly should write an update somewhere into this article.

I think CDM and Ars did a sensible coverage of that story as well.

1 Like

What used to be Audacity is now Tenacity.

Or this :roll_eyes: