Recent Audacity unusable in educational environments

[refutationalist]

Describe the bug

I teach introductions to broadcasting and podcasting in numerous contexts in public and private education, and I have made extensive use of Audacity. Under the new "Privacy Notice" to enable collection of app telemetry Audacity disallows use by anyone under 13 years of age. This prevents me from using the software completely-- both by the Muse Group "Notice" and by the legal requirements of the organizations I work with.

This is similar to issue #1226 but without rancor. Please keep in mind this is not merely a propaganda point in my case. Your new requirements have effectively stopped me in my tracks.

To Reproduce

1. Use Audacity in teaching environments with children
2. Try to comply with https://www.audacityteam.org/about/desktop-privacy-notice/

Expected behavior
The app should allow runtime disabling of any statistics gathering, and the privacy notice should be updated to allow educational use.

[tachyons]

Audacity is part of school education in Kerala. This is a breaking change for them as well

[danii]

Hey, I have a temporary, most likely permanent solution for educators alike. There are forks of audacity that are compliant with GPL v2 and v3, meaning that the people behind the forks won't get a class action lawsuit, er, builds don't ship with spyware excuse me, telemetry, jeez sorry, my typing skills aren't typically this bad, builds can be legally used by people under the age of 13.

Here's one; https://github.com/temporary-audacity/audacity

[atarukun]

This is going to be negatively impactful for a lot of folks. Either they won't notice that they are not in compliance with your new terms or they will be forced to stop using this software as described above.

It seems a trivial fix to simply allow runtime disabling of personal data collection; and more than that, it's the right thing to do. I occasionally use Audacity, but have no intention of doing so again while these terms are in place without the ability to disable.

[SteveDaulton]

It seems a trivial fix to simply allow runtime disabling of personal data collection; and more than that, it's the right thing to do. I occasionally use Audacity, but have no intention of doing so again while these terms are in place without the ability to disable.

Not only has this been in the code from way before this GitHub issue was started, it had even been documented!

[refutationalist]

Not only has this been in the code from way before this GitHub issue was started, it had even been documented!

I, as well as many other people, are aware of that option. It is hardly a complete solution. The option also predates the new privacy policy, which raises some questions about what other data is, or is going to be, collected, and whether it is optional. The answers given thus far do not at all cover my use case.

[petersampsonaudacity]

I, as well as many other people, are aware of that option.

It is unreleased software which is currently only at the alpha testing stage. And as it stands right now it is still possibly subject to change. The new Application prefs pane that Steve showed above, I only documented last week.

This new feature will also be documented in the "What's New in 3.0.3" page in the Manual for 3.0.3 and will be discussed in the Release Notes.

[refutationalist]

Of course you are unaware - it is unreleased software which is currently only at the alpha testing stage. And as it stands right now it is still possibly subject to change. The new Application prefs pane that Steve showed above, I only documented last week.

My apologies, but you are incorrect.

It is unreleased software on GitHub, and people associated with Audacity have fortunately undertaken some effort to promote how little phoning home Audacity actually does, and its configurability. There are also the compile time flags that presently leave out most of the code necessary to phone home. I'm aware of these things as I have to compile Audacity myself. I use Linux, my distro still packages 2.4.1, and I have students and producers already sending me aup3 files for various reasons.

Yet this is only half the solution, at best, and the majority of the issue remains in the unresolved component. Discussion of the configurable option without even making mention of the real problem is becoming notable as it has now happened twice. Unfortunately, I can't point a big red arrow at something that doesn't exist. I can point a red arrow at this, however:

This new feature will also be documented in the "What's New in 3.0.3" page in the Manual for 3.0.3 and will be discussed in the Release Notes.

This is good, but what we'll have is a perfectly functional app that both the parent organization of the developers and my varied compliance departments won't let me use with my students. This is a significant usability issue. Under the present circumstances, my kids quite literally could not do their homework. The checkbox could be the first thing a user sees and as big as a house, but it ultimately doesn't repair the problem.

As a result of these changes to Audacity, teachers in the International Baccalaureate and Advanced Placement programs in schools near me are retooling their programs to use other (mostly proprietary) applications to meet their audio requirements. These teachers would not count as developers even if you stretched the definition to include myself. But I'm "technical," so I'm looking into it. This issue is the result, and since it does affect me I spoke to my situation.

I have already had to field questions regarding the age limitation. Are teachers even prevented from using Audacity to record their students? I told them I very much doubted it, but the privacy policy is such a mess I can't answer authoritatively.

Retooling the privacy notice to reinclude children as authorized users-- and perhaps some further clarification-- would go a long way toward solving the issue.

[ProfesoraBecky]

I'm one of those not-so-technical educators referenced by Refutationalist above. I work in a diverse, mixed income district where more than 50% of our students live below the poverty line, so being able to advise the use of free programs is a huge equalizer in educational access. Not being able to use Audacity with our middle schoolers has a significant negative impact, especially in our English learners program and world language instruction. If this is not resolved to allow use by children, it will be very disappointing and further the education opportunity gap that Audacity was previously a part of closing.

[NNickey]

It seems a trivial fix to simply allow runtime disabling of personal data collection; and more than that, it's the right thing to do. I occasionally use Audacity, but have no intention of doing so again while these terms are in place without the ability to disable.

Not only has this been in the code from way before this GitHub issue was started, it had even been documented!

I rather have the people who currently 'own' Audacity give Audacity back to the respectful owners that know how to follow open source GDP regulations and what not. A huge chunk of the internet already have a sour mouth for Audacity over their dumb move to record information about it's users.

And for what purpose? To sell it that is.

[refutationalist]

I see the privacy policy has been updated to "draft" status until such time as the next version of Audacity is released, which is good. However, the draft still contains the age limitation and therefore this bug still exists.

[Drakeo]

Since this is Licensed under the GPL you can type what ever you want in policy.
Fact it is GPL. Anyone of any age can use it. So save the ink Team Audacity or pay the huge GNU fines that could come your way. https://en.wikipedia.org/wiki/Open_source_license_litigation

[themancalledjakob]

It seems a trivial fix to simply allow runtime disabling of personal data collection; and more than that, it's the right thing to do. I occasionally use Audacity, but have no intention of doing so again while these terms are in place without the ability to disable.

Not only has this been in the code from way before this GitHub issue was started, it had even been documented!

@SteveDaulton how is this related? As far as I can see, the red arrow in your screenshot points to a checkbox that enables/disables update checking for Audacity. I fail to understand how this should be a trivial fix to simply allow runtime disabling of personal data collection or should make Recent Audacity usable in educational environments . Can you clarify this?

[SteveDaulton]

how is this related?

When "Check for updates" is enabled, Audacity will periodically check to see if an updated version is available. To do this, it must connect to an online resource to see if there is a more recent version for your operating system than the one that you are using.
That requires telling the online resource, which version you are currently using, and what operating system you are using (otherwise the online resource cannot know if there is a more recent version available for you). It also requires your IP address, otherwise it cannot reply to let you know if an updated version is available or not (See: Internet Protocol on Wikipedia).

GDPR classes this information as "personal data", and so legally requires this use to be disclosed in a privacy notice. It also specifies that a child under the age of 13 cannot give consent for the use of personal data.

When "Check for updates" is NOT selected, then the app does not connect to the internet and no data is exchanged.

The other case where data "may" be sent over the internet is in the eventuality of a crash (either the entire app or a component within the app). If a crash occurs, a crash report is generated locally. I have not yet seen this myself (Audacity 3.0.3 alpha has not yet crashed for me), but my understanding from looking at the code is that it goes like this:

1. If a crash occurs, generate a crash report locally.
2. When next able to do so (the app must obviously be running), ask the user if they want to send the crash report to the Audacity developers.
3. If the user says "Yes", send the report. If the user says "No", don't.

None of this applies to any current version of Audacity as versions up to and including Audacity 3.0.2 do not have the ability to connect to the Internet.

[petersampsonaudacity]

The other case where data "may" be sent over the internet is in the eventuality of a crash (either the entire app or a component within the app). If a crash occurs, a crash report is generated locally. I have not yet seen this myself (Audacity 3.0.3 alpha has not yet crashed for me), but my understanding from looking at the code is that it goes like this:

1. If a crash occurs, generate a crash report locally.

2. When next able to do so (the app must obviously be running), ask the user if they want to send the crash report to the Audacity developers.

3. If the user says "Yes", send the report. If  the user says "No", don't.

I have tested this on 3.0.3 Release Candidates RC1 and RC2

1. and immediately after the crash I got a crash report dialog asking if I wanted to send the crash report - I clicked the Yes button

2. I did get a database error that generated an error report dialog (note that not all Audacity errors generate such phone-home dialogs)
   a) This happened from within the running Audacity
   b) I clicked the Yes button to send the report
   c) Audacity remained open and OK

I also tested with clicking the No buttons.

In both cases where I clicked Yes to send the reports the developers told me that both cases provided valuable debug information for them - and that's why this feature is being added.

[themancalledjakob]

@SteveDaulton Thank you so much for the answer, that does clarify why this is related.

I still do not entirely understand, why the online resource requires to be told information about the user's system or software version, since I thought it provides a list of available versions and the client could figure out if it can update or not. At least if I look at the implementation here: https://github.com/audacity/audacity/blob/release-3.0.3/src/update/UpdateManager.cpp

simplified, as I understand it, it would do this:

1. get https://updates.audacityteam.org/feed/latest.xml
2. parse the file and filter out relevant version number
3. compare versions
4. open browser with link to download

I cannot see in the code that it would transmit which version of Audacity you are currently using, and what operating system you are using. Maybe I'm looking at the wrong snippet, but isn't this a simple get request (as in GET requests should only retrieve data and should have no other effect. )? Does it send another request, or are there parameters transmitted that I am overlooking? Maybe in the header?

I am a bit confused, because if there are additional parameters containing user information transmitted, then I can't see why. I was trying to check the content of latest.xml to dig a bit deeper, but it leads me to a 404 page. Though, does the xml not simply contain the current version numbers for all available operating systems, and then the proper info is filtered by the parser?

    // https://github.com/audacity/audacity/blob/release-3.0.3/src/update/UpdateDataParser.cpp:91
   
    // here it is checking for a linux tag, and for the other platforms are similar conditionals
    // so the figuring out of the operating system happens locally
    if (wxStrcmp(tag, mXmlTagNames[XmlParsedTags::kLinuxTag]) == 0)
    {
        if (info.GetOperatingSystemId() & wxOS_UNIX_LINUX)
            mXmlParsingState = XmlParsedTags::kOsTag;
        return true;
    }

So, the only thing you need to send, is the GET request and receive a generic xml, the same for anyone and everyone.
Can't see a problem here.

The transmission of the IP address which comes with a GET request, cannot possibly be the reason for the updated privacy notice and age restriction.. right? And if this would be the case, wouldn't it be an idea to have it opt-in, and make the privacy notice appear the moment you check the box? This could possibly make people freak out less, it would explain itself and you wouldn't need to agree to a privacy notice that you are not using. For example, if you have your applications managed by a package manager (apt, pacman, yum, brew, etc). I do not really propose to do this, I guess you thought about these things long and hard. But I just love using Audacity and want to understand what exactly is going on here.

[SteveDaulton]

I cannot see in the code that it would transmit which version of Audacity you are currently using

Someone posted a partial answer to this earlier ("somewhere" in one of these recent discussions).
I made a note of the example update request:

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)

[themancalledjakob]

Thank you for your efforts.
I see, so the information is indeed in the header.
And that explains also, why I got a 404 when trying to open it from a browser. The online resource checks if the User-Agent string contains "Audacity". If not, the request gets blocked.

TL;DR: There is more information in the header about the users system, than is required for check-update functionality. It is not much, but it is there, and there is no transparent reason for it. Statements like

"That requires telling the online resource, which version you are currently using, and what operating system you are using (otherwise the online resource cannot know if there is a more recent version available for you)." - (see above @SteveDaulton )

are technically wrong. (Since there has no reply to this post for two weeks, I must assume this is the case. You could of course, adjust the functionality in a way, that the server does need to know these details to function properly, but the following post - and common sense / logic - shows that it would be unnecessary. Again, I am happily corrected, but then, I think I'm sadly correct.).

Now for the slightly longer read:
The information transmitted in the User-Agent about the Audacity version and used OS, has no influence on the functionality. Even when you completely omit the information, you get the same result. This would be an xml file, that contains latest versions for all platforms. Example:

$ # first, the header with information
$ curl -A "Audacity/3.0.3 (Windows 10_0_19042; x64)" https://updates.audacityteam.org/feed/latest.xml
<?xml version="1.0"?>
<Updates>
  <Description>Audacity 3.0.2 fixes some important bugs and improves diagnostic reporting. We also added a new preference for macro output, and a 'Save' button on the manage macros dialog.</Description>
  <OS>
      <Win32>
          <Version>3.0.2</Version>
          <Link>https://github.com/audacity/audacity/releases/download/Audacity-3.0.2/audacity-win-3.0.2.exe</Link>
      </Win32>
      <Win64>
          <Version>3.0.2</Version>
          <Link>https://github.com/audacity/audacity/releases/download/Audacity-3.0.2/audacity-win-3.0.2.exe</Link>
      </Win64>
      <Macos>
          <Version>3.0.2</Version>
          <Link>https://github.com/audacity/audacity/releases/download/Audacity-3.0.2/audacity-macos-3.0.2.dmg</Link>
      </Macos>
      <Linux>
          <Version>3.0.2</Version>
          <Link>https://github.com/audacity/audacity/archive/refs/tags/Audacity-3.0.2.zip</Link>
      </Linux>
  </OS>
</Updates>

$ # then, omit all information, only keep "Audacity" to avoid being blocked
$ curl -A "Audacity" https://updates.audacityteam.org/feed/latest.xml
<?xml version="1.0"?>
<Updates>
  <Description>Audacity 3.0.2 fixes some important bugs and improves diagnostic reporting. We also added a new preference for macro output, and a 'Save' button on the manage macros dialog.</Description>
  <OS>
      <Win32>
          <Version>3.0.2</Version>
          <Link>https://github.com/audacity/audacity/releases/download/Audacity-3.0.2/audacity-win-3.0.2.exe</Link>
      </Win32>
      <Win64>
          <Version>3.0.2</Version>
          <Link>https://github.com/audacity/audacity/releases/download/Audacity-3.0.2/audacity-win-3.0.2.exe</Link>
      </Win64>
      <Macos>
          <Version>3.0.2</Version>
          <Link>https://github.com/audacity/audacity/releases/download/Audacity-3.0.2/audacity-macos-3.0.2.dmg</Link>
      </Macos>
      <Linux>
          <Version>3.0.2</Version>
          <Link>https://github.com/audacity/audacity/archive/refs/tags/Audacity-3.0.2.zip</Link>
      </Linux>
  </OS>
</Updates>

Therefore, the transmitted information about Audacity version and OS is not crucial to the functionality of checking for an update.
If I don't have a logical error somewhere - please help if I do - it does not require telling the online resource which version you are currently using, and what operating system you are using. The online resource does not need to know if there is a more recent version available for you, because the response contains the last version number for every supported system. Also, comparing the versions happens locally in a class called UpdateDataParser.

Consequently the transmit of additional data in the User-Agent string can be seen separate from the check-update, and could ideally be a separate setting that would reflect on its function (e.g. "send data about Audacity version and operating system to Audacity"). If the setting is unchecked, Audacity could send a generic User-Agent string (e.g. just "Audacity") in, and still keep the check-update working.
Currently, the User-Agent string is generated by libraries/lib-network-manager/curl/CurlHandleManager.cpp:224, on application start (I guess, because it happens when CurlHandleManager is initialized). So this is where you could hook up the creation of a generic template in case you don't have the users consent yet. I will stop getting into technical details here though, because it's pretty self explanatory and boring. Also, I do strongly believe that you would be technically more than capable to figure out solutions for this that keep the desired functionality without having to adjust any privacy policy for the generic offline user (for example your generic seven year old computer genius child, or let's say a student within an educational environment).

With this I would like to come back to the topic of @refutationalist, that recent Audacity is unusable in educational environments. This concerns me as well, since I want to teach Audacity in my class, and that a (for me) meaningless feature throws sticks between my legs, is weird.
I realize, that by unchecking the box "check for updates" there is no connection to the internet. And this is clearly reflected in the code. But it does not help, if this feature is checked by default when the application starts. It is impossible to navigate to the settings and uncheck the box before the request is sent and the damage is done. I wish this box would be opt-in, and on the moment of opting in, a privacy notice would be shown, and why not an age verification. Then it would be clear what the notice is about and you could use it completely offline. Also, network access is already configured as opt-in on compilation time (#935), why not have it opt-in on runtime? Most people will use precompiled binaries, and won't have the luxury of opting in on compile time.

So, that's it from me. Hopefully this can give insight into how a random non-expert would analyze the situation, though I would be surprised if this post contains any information new to you. Which is why I am a bit puzzled that the findings are not completely in line with your statements before. I assume that this whole discussion is quite a lot to handle, and technical specifics can be unclear even to someone close to the development. It is possible that I misunderstand something, but I can't see what.

Anyways, thank you so much for your patience and replies, I think I understand the issue now a bit better.
To my understanding this issue remains valid, and I hope that the Audacity team can successfully work this out with the community. Good luck!

PS: edited formatting for clarity, link to UpdateDataParser, and added TL;DL at the beginning

[petersampsonaudacity]

The Privacy Policy has been updated to remove the restriction on use to 13+ - there is no age restriction on Audacity use

[themancalledjakob]

Huh? I am now looking back after a while at this discussion, and it is puzzling.

The user agent string is still generated as before, and therefore is transmitting the same information about the users system as before.

It it still opt-out, which means that the privacy violation happened before you can possibly open the settings. I just downloaded the latest application and verified that this happens without asking the user for consent.

quote @SteveDaulton

GDPR classes this information as "personal data", and so legally requires this use to be disclosed in a privacy notice. It also specifies that a child under the age of 13 cannot give consent for the use of personal data.

Since you didn't change anything technically, but removed the privacy notice... are you now illegally collecting personal data from children under the age 13 without their consent?

[SteveDaulton]

quote @SteveDaulton

My views are my own, and I am not a lawyer.
I'm guessing that you are not a lawyer either.

On first run:

[LWinterberg]

What also changed is that crash reports no longer allow to enter comments on what happened, so the major source of PI which got saved got removed. Audacity also doesn't store any personal information, IP addresses get truncated and truncated addresses together with the remaining info isn't enough to identify an individual.

Further, yes, the processing happens on the basis of legitimate interest rather than consent (§2.5 of the privacy policy). And I'm also not a lawyer.

[themancalledjakob]

thanks for the answers and also I just read my own post again and the last part sounds quite aggressive. Sorry about that, I want to apologize for the tone. I have utmost respect for your work in developing this application.

There is still information about the users' system transmitted while checking for the update, while it is not necessary or even used for the purpose of checking if a newer version is available. It's not a lot of information, but it is there. I have honestly no idea how and if this affecting the legal situation. As I understood legitimate interests can’t be relied on as the legal reason for data processing if there is another less intrusive way to achieve the same end, which is clearly not the case here. Though, I am definitely not a lawyer and I would like to avoid getting into a legal discussion. What bugged me, the communication about it was misleading and so far it was ignored that you can just leave the user agent string empty and achieve the same functional result. I am sure that this was not done on purpose, and the fix seems super simple to me. You could just leave away the user agent string, make it opt-in and ask for users' permission before the first connection. At least for this, it would technically solve the issue.

I am not referring to the crash report by the way, just to the way that it is checked for an update.

I am aware that it is possible to deactivate the automatic check for an update from within the program. This you can only do though after it has already checked for an update and transmitted the information in the first place. So, it is not possible to use the current release of Audacity without it trying to phone home and transmit the User Agent String as described above.

Just to make sure this is really true I filtered network traffic with wireshark, and as you can see (and probably already know) it connects to updates.teamaudacity.org (104.26.1.108) already before I am able to click on anything.

I am not happy with the way the last part of my previous post sounds, (as it literally asks for getting into a legal discussion :) ) but I'll leave it there just so that your answers make sense. I am sure you checked this is legal, but it still is uncomfortable.

[crsib]

This behavior is a bug and it is fixed in the master branch. The fix will be included in the 3.1.0 release, coming in the following weeks

[petersampsonaudacity]

thanks for the answers and also I just read my own post again and the last part sounds quite aggressive. Sorry about that,

We've heard a lot worse in recent months ;-)

[petersampsonaudacity]

There is still information about the users' system transmitted while checking for the update, while it is not necessary or even used for the purpose of checking if a newer version is available. It's not a lot of information, but it is there.

Audacity could, if it had wished, asked for a registration or an account to be set up in order to download the software:
a) the old volunteer team (of which I was a long-standing member) studiously avoided that approach
b) when Mus e took over the project they continued in the same vein
c) not that plenty of other free and commercial apps demand such information.

If you are really concerned/obsessed with not revealing your IP address even the once on initial launch you can
a) download Audacity
b) disconnect you PC from the internet
c) launch Audacity
d) select the option to not get update checking
e) exit Audacity
f) reconnect to the internet
g) launch Audacity - and there you go

The setting you made at step d will remain extant and unchanged unless and until you manually purge the contents of your Audacity settings folder (a hidden folder).

In particular note that using Tools > Reset Configuration will NOT reset that particular setting - I QA tested that quite thoroughly.

Personally I don't care too much - most things I use on t'interweb gather data about me. my phone gathers information about me - the amount that Muse gather is small in comparison to many others.