Actions we propose to take on PR #835

[Tantacrul]

Hi everyone,

I’m going to describe the actions we propose to take to address the concerns raised about PR #835 (opt-in Telemetry using Google and Yandex as 3rd party hosts):

• We are dropping the telemetry features proposed in PR Basic telemetry for the Audacity #835
• Regarding features that require networking, we would like to include error reporting and the ability for Audacity to check for updates (details below)
• We will self-host all collected data from error reporting and checks for updates, removing any need for Google or Yandex analytics

What happened?

The creation and subsequent discovery of PR #835 was a bad communication/coordination blunder that caught us completely by surprise. We're very sorry for causing so much alarm. Our intention was to make an initial announcement about our plans to introduce telemetry on the Audacity forum, similar to how we discussed the topic for MuseScore in 2019. In that instance, I think the fact that we introduced the issue openly resulted in a lot less suspicion.

What are we proposing now?

I have spent the last few days working with the heads of Muse to try and reach a solution that would accommodate the requests of the community as much as possible. Apologies about the delay. These decisions took time to arrive at because - despite my role as the lead on the project - calls on this specific issue are not mine to make.

First, it is important to stress that we have absolutely no interest in harvesting or selling personal data and Audacity will always be free and open source. The response to PR #835 has brought about a realisation at Muse that the convenience of using Yandex and Google is at odds with the public perception of trustworthiness, so we will be self-hosting instead.

The next item is telemetry. I believe our communication mistake contributed to a lot of misunderstanding about our intentions here. Telemetry is a practical tool that tells us a lot about how an app is performing or underperforming (is this new feature being used a lot? Is this button being discovered? etc.) We assumed that making it opt-in would allay privacy concerns but since this isn't the case, we are dropping it. In the future, we may want to determine if there are any acceptable alternative solutions that could achieve the same goal. Feedback would be appreciated on this point. In the meantime, I will continue user testing, interviewing, reading feedback and conducting surveys to learn more about what our users want. I will happily discuss this in the comments section.

Before delving into the specifics, it is important to mention that we have been asked a lot of different questions. For the purposes of not muddying the conversation, I have stuck only to the most pressing issues raised about PR #835. There will be a lot more communication from Muse about its goals in the near future. I will be continually talking about Audacity and discussing what we are working on over the coming weeks and months. Please ask questions here. We're ready to answer.

---

Below is more specific information related to error reporting and update checking.

Error reporting

We are currently interested in SQLite errors, application crashes, and non-fatal exceptions. If one of these events is detected, a dialog will appear that explains the nature of the problem and offers to send an error report to us, the Audacity developers. This dialog will contain:

• An option to view the complete error report data before it is sent
• For crashes and errors, it will send the OS used
• For crashes it will send CPU data, like number of cores
• Equally prominent buttons to “send” or “don’t send” this particular error report
• A checkbox (unchecked by default) offering to remember the user’s decision and do the same for future error reports without asking
• The decision for future error reports can be changed in Preferences at any time

Error reports of course take place over the internet, which naturally allows us to see an IP address. The error report is stored in our self-hosted Sentry database on a server located in the EU. No information will be sent to any third parties unless required by law. Sentry stores crash data and system/hardware specifications. Here is a link to their source code: https://github.com/getsentry/sentry

Update checking

When the program starts, Audacity will check whether a newer version of the program is available for download. If there is a new version, the user will be shown a dialog to notify them.

• There will be an option to disable automatic checking
• This decision can be changed in Preferences at any time

Update checking reveals three things: the IP address, the OS version and the Audacity version. We will use a self-hosted geolocation database to determine the country the IP address is located in and nothing more. The raw IP address will not be stored or logged, but we will store and log a non-reversible hash of the IP address to improve the accuracy of the daily statistics. The server is located within the EU to comply with the GDPR. No information will be sent to any third parties unless required by law.

Compiling from source and Linux distribution packages

The behaviour described above for error reporting and update checking would only apply to official “release” versions of Audacity available from our website or GitHub page. In other builds, the error reporting and update checking code will be excluded by default via CMake options.

[Martin-Eckleben]

Thank you for this statement. Could you / Muse Group please also answer any time convenient to this discussion?

#880

Both the Audacity website as well as Muse Group's website states that Muse Group has acquired Audacity. However, hardly any details have been given. The information given on the Wikipedia page on Muse Group is also vague and questionable at best. All we have to work with is this quote from Tantacrul's video:

Audacity has just joined Muse Group, a collection of brands that includes another popular open source music app called MuseScore, which I’m currently in charge of.

This raises several important questions. To name a few:

Is it even possible for a company to acquire a free and open source project licensed under the GPL?
How exactly did Muse Group acquire Audacity?
What rights and power does Muse Group legally have over the Audacity project?
Can Muse Group even legally claim ownership over the project or do they simply own the trademarks to the name and logo?
Who exactly is behind Muse Group; what roles do these people have?
What are Muse Group's visions and goals for Audacity?
How does Muse Group plan on going about putting these goals and visions into practice?
How does Muse Group plan on handling situations where they want a new feature but the community rejects it (see PR 835)?
Are any of the core maintainers and team members of Audacity now on the pay roll of Muse Group?
What is the project father's and core maintainer's role and view of these events?

[domsson]

Another question that has come up in the meantime, is why the long-time, core maintainers of the project can't or won't answer any of these questions. It really seems like they aren't allowed to as became apparent from James Crook's comment:

You're going to have to rely on public statements from https://mu.se/ and what you can work out for yourselves form publicly available information.

Sounds like some kind of oppressive contract, like an NDA, is in place. Would very much appreciate some statement on that as well. If people are being silenced, then that's a huge red flag. And if they aren't, then the question still is why they don't answer of these question.

[domsson]

Similarly, Gootector has pointed our attention in the direction of potential fake reviews for MuseScore on Trustpilot. Would very much appreciate some comment on that as well.

[Qix-]

The Discord server chat also alluded to some strange behavior from the original maintainers.

From one of the old maintainers:

[15:33]
The "old team" is part of the current team. Don't think we are not taking care. We love audacity and so does Muse.
[15:34]
And that's all I'll say.

[domsson]

@Tantacrul Muse is now marching forward with the CLAs. Yet, I still don't see any answers to the above questions. I don't understand how some honest answers need so much time and consideration in order to "not get anything wrong", unless there are lots of things that, if answered straight and honestly, wouldn't go down too well with people.

[lengthwave]

@Tantacrul Muse is now marching forward with the CLAs. Yet, I still don't see any answers to the above questions. I don't understand how some honest answers need so much time and consideration in order to "not get anything wrong", unless there are lots of things that, if answered straight and honestly, wouldn't go down too well with people.

Answered: #880 (comment)

[Be-ing]

In the future, we may want to determine if there are any acceptable alternative solutions that could achieve the same goal. Feedback would be appreciated on this point.

@unfa suggested to make separate builds for testers that collect data about how the application is being used.

[crsib]

It doesn't work on the scale at all. There was a time when a certain popular calculator on Android was requiring access to the phone log and GPS and a lot of users were fine with it :-) Around 2016

So yes, it is not an issue for power users, I do not argue with that. But it is an issue otherwise.

[Be-ing]

There's a slight, but important difference: With the plugin you can be sure when it's installed. For the release builds you can't be really sure about it actually being disabled, even when the build feature should normally turn that part of the code off.

Sure you can if the telemetry build presents that it is the telemetry build clearly in the UI. There could even be a switch in the preferences to turn off telemetry for the telemetry builds if the user wants to stop participating in data collection without needing to uninstall and reinstall the release build.

[Be-ing]

Creating a pluggable interface for telemetry will bring the users at risk that some 3d party tricks them into installing a plugin that implements it. This is probably not an issue for Linux power users but is a major security concern.
We do have an interface for Effects plugins. As well as support for most of the major audio plugins standards. But these plugins are very limited in what data they receive.

Yeah, audio (and VAMP) plugins have a clearly defined scope and a standardized API which does only that and no more. I would think a telemetry plugin would have to reach deep into almost every part of the application.

[ccoenen]

That UI could be faulty in subtle ways. In #835 we already had the situation where the feature was on by default by accient (it was found, corrected and I do not believe it was intentional). This is not exactly rare. We had the whole goto fail problem that wasn't discovered for years.

This is why I'd like the actual networking code to be completely separate from the rest of the program.

[SndChaser]

Okay, since my name was brought up here, I think I should comment. ;)

First @crsib, the issue with Android applications accessing things they shouldn't be actually points to the solution: notification when installing / activating a plugin. The user should be notified what permissions the plugin is expecting. There could even be some control built into the plugin system to allow the user to control what a plugin has access to. (This could lead to cases where a plugin wouldn't work with the permissions granted by the user, but it should be a condition that the plugin fail gracefully when that is the case.)

@Be-ing The problem I have with this being part of the build process is this: how does a user know when they install Audacity from a distribution if it has telemetry (or similar system) enabled or disabled? I used to "distro hop" a lot (I think I've used somewhere around 20-30 over the years), and I could never tell you how an application was compiled when I moved from one distribution to another. I had to take it on faith that the maintainers of that distribution made the choices that would be best for me as a user, while making the choices that fit best for their distribution. If that wasn't the case, I wouldn't know until after the application had been installed and launched.

On the other side: how many users on other platforms are getting the application directly from the Audacity website? How many other collections of audio tools are out there that Mac and Windows users have access to for "ease of installation" or some such excuse? How will those users know if telemetry is or isn't included in their package? (I know this kind of thing should be rare these days, but I'd bet there are regions where it is still a practice...)

Separating this kind of functionality out into a separate body of code that isn't included with the distribution packages makes the situation more manageable from a user perspective, IMO. Also, it still wouldn't be impossible to have a first-run pop up that asks users if they are willing to participate in data gathering, and if the answer is "yes" it walks the user through the download and setup of the plugin.

[Daniel34M]

Very good alternatives! I personally thing an optional mailbox option included in the same app would be beneficial where you could decide what information to send and maybe preview the report. If there's already an option like that in the program, my apologies, I don't know of it

[Megaf]

Good stuff.
As long as the data is not going to Google, Yandex, Microsoft or Amazon we should be happy.
Collect the data you really need, self-hosted it, make it private, make it all opt in, and we shall help.

Thank you for clarifications and for listening to us.

[fhunter]

That still collects data and adds a network dependency for an app that didn't have one.

[infinitytec]

Absolutely this. I can understand the benefit of analytics. And maybe Muse has no interest in selling data, but they can't speak for Yandex and Google.

[geekredux]

This is a welcome and, I must say, surprising development. The questions @Martin-Eckleben mentions in his comment--especially regarding just what it is Muse Group bought--still need addressing (but I also understand @Tantacrul's caution as expressed in his response). Based on the limited info that's been provided so far, as well as the initial responses in #835, it seems like Muse Group thought they were buying Audacity the software when they were actually buying Audacity the trademark.

[Be-ing]

The ability to do this, however, requires written consent of each contributor to the code (or their code should be excluded). Contributors were individually contacted and the issue was sufficiently resolved.

This is concerning. But let's continue that conversation on #880/#844.

[Be-ing]

Firstly, some of the top legal experts on open source licensing were involved in this effort so there were no surprises.
Also, as we considered the future of the project it became clear that uplicensing to GPLv3 would be essential to supporting capabilities like VST3.
The ability to do this, however, requires written consent of each contributor to the code (or their code should be excluded). Contributors were individually contacted and the issue was sufficiently resolved.

There is no need to change Audacity's license to use GPLv3 libraries. Audacity is licensed GPLv2 or later. The one legitimate reason I can think of to gather permission from copyright holders of Audacity to change the license would be adding an exception to the GPL to allow distribution in Apple's iOS and Mac App Stores.

[Be-ing]

The situation here is pretty simple - a developer made comments that were obviously not official statements of the company, that they did not have authority to make, and were made without the consent or even awareness of the company.

Thank you for clarifying this. I would not expect a company to immediately jump to such intimidating rhetoric in an official communication.

[egasimus]

The situation here is pretty simple - a developer made comments that were obviously not official statements of the company, that they did not have authority to make, and were made without the consent or even awareness of the company.

Thank you for clarifying this. I would not expect a company to immediately jump to such intimidating rhetoric in an official communication.

What disciplinary action was taken towards that developer?

[mykohsu]

The language used (both the tone and actual words) should have made it clear that this was not an official statement from the company. It is very unfortunate that this happened.

If you follow that thread, it's clear further development on MuseScore itself made similar poorly worded statements.

[IGBC]

Error reporting

We are currently interested in SQLite errors, application crashes, and non-fatal exceptions. If one of these events is detected, a dialog will appear that explains the nature of the problem and offers to send an error report to us, the Audacity developers. This dialog will contain:

* **An option to view the complete error report data before it is sent**

* For crashes and errors, it will send the OS used

* For crashes it will send CPU data, like number of cores

* Equally prominent buttons to “send” or “don’t send” this particular error report

* A checkbox (unchecked by default) offering to remember the user’s decision and do the same for future error reports without asking

* The decision for future error reports can be changed in Preferences at any time

Error reports of course take place over the internet, which naturally allows us to see an IP address. The error report is stored in our self-hosted Sentry database on a server located in the EU. No information will be sent to any third parties unless required by law. Sentry stores crash data and system/hardware specifications. Here is a link to their source code: https://github.com/getsentry/sentry

Update checking

When the program starts, Audacity will check whether a newer version of the program is available for download. If there is a new version, the user will be shown a dialog to notify them.

* There will be an option to disable automatic checking

* This decision can be changed in Preferences at any time

This is a significant change for the better, Thank you to the developers and muse for listening to the communities concerns, and holding our values at the highest priority.

[Meriipu]

but are the update checks turned on by default? i.e. will audacity send a network request before you have a chance to turn it off?

[BenBE]

To avoid tracking each and every start, the update interval should be configurable. Also on first start you might want to ask the user about it. Having the options No automatic checks, Once a week, Other options present in such a dialog should be a compromise.

[mattatobin]

Just ask on firstrun (or first run of the version with AUS) if the user wants to enable automatic update checks.

RESOLVED FIXED

[juststur]

A prompt at first launch may solve your situation, but as a higher Ed institution who installs the software in labs update checks must be able to be disabled for all users, no checks.

[Rybec]

Yeah, automatic updates should be configurable during install or first run (before the first check). This wouldn't fully resolve the age limit issue with respect to the GPL, but it would provide a way for people who don't meet the age requirement to opt out of the automatic updates and avoid data collection, thus partially sidestepping the conflict and at least reducing the age restriction to only apply to the automatic updates.

[heavyelement]

I'm glad to see you guys have listened to the community's feedback here and have decided not to use Google/Yandex. However I think it's unfortunate that you are foregoing opt-in telemetry collection altogether. It's a useful tool that could benefit the project.

What's most regrettable about this whole fiasco is that people are probably going to remain outraged about the original PR and not even know that this update exists.

[eylles]

Welp, it is better to get rid of it entirely than to loose all trust from the community, if the community doesn't trust the software with the developers they will just fork it, there's nothing preventing that, and thinking that the community around a FOSS project won't have the drive nor skills to mantain a fork is a huge mistake.

[Qix-]

I agree. It's a pity that they are getting rid of it entirely

They are not getting rid of telemetry. Instead, they have added an even more invasion, enabled-by-default tracking system outlined later in the post (IP logging + geolocation + OS + audacity version + enabled by default).

This is still tracking you. Just because it's not saying which button you pressed doesn't make it any less of a problem.

[davidak]

@Qix- so is your position that you don't want your software to send any network request without your action or you would consider it malware? i would consider that a legitimate standpoint, but it is kind of radical (which don't has to be bad)

IP logging

they said:

The raw IP address will not be stored or logged

they only count how many installations there are per geolocation. it's not identifying you

they also store the hash of an IP to not double-count an installation

OS

in my case, the operating system could be NixOS 21.05pre288911.9057122e0f3 when i build it from a github pull request (nixpkgs/123519 in this case with commit id 9057122e0f38fbc3aa3b246550fd1d9efae503e2)

i might be the only person in the world doing that. when i publicly state that i use that version, for example in a bug report, that could be a clue that it's actually me and i could be identifiable, but it could also be a different person

@Tantacrul have you considered that?

audacity version

when this data can only be official releases, i don't see a problem collecting how many installations there are

the audacity-git package from AUR currently has the version 2.4.2.r0.g16d52f63a. when someone builds a custom package from a specific audacity commit and that version is then submitted, they might be identifiable

https://repology.org/project/audacity/versions

they said:

The behaviour described above for error reporting and update checking would only apply to official “release” versions of Audacity available from our website or GitHub page. In other builds, the error reporting and update checking code will be excluded by default via CMake options.

but the audacity-git package maintainer could enable these options

they could also provide a version for linux as AppImage, Flatpak or Snap

they don't state that they will save a timestamp. when you have it, you can create such a graph like here on the top

https://data.syncthing.net/

i think that is a pretty nice visualization of versions still in use

@Tantacrul have you considered that? you can make the data public and visualize it, so everyone can see what you are doing (transparency)

[Qix-]

An IPv4 address is trivially rainbow tabled (32-bits input)...

[ccoenen]

Also, IPv4 will both over- and undercount. Overcount because (at least in germany) IP addresses are reassigned every 24 hours on all major ISPs for consumers, so you'll count the same person many times. Undercount because any number of people could use the same IP address both across time (because of reassigned IP addresses) or at the same time (because of shared internet access). So, in the end this isn't even useful because all you are counting is "this many IP addresses were seen" which may be ten times more or ten times lower than the actual number of people using audacity.

And the two effects might or might not cancel each other out. So in the end you won't even know if your're over- or undercounting.

I really don't see the point in even doing this. The only thing that will come out of it is some meaningless vanity metric.

[domsson]

Very good! This shows that you have not only understood the concerns of the community, but also put forth a plan that addresses all concerns sufficiently. I have to admit, I did not expect this and I'm pleasantly surprised.

Only one suggestion/ question remains: Will the crash logs be open to all developers or only MuseGroup employees? I believe they should be accessible by everyone, as this would give community developers the means of fixing such bugs.

[kg]

Exposing crash data to the public is in general a very sketchy thing to do. It's hard to ensure that something like a coredump doesn't contain personally identifiable information, like comments from an opened project in the heap, or a user's personal information in the filename of the currently opened file. For textual log files there's existing tech and best practices out there for how to try and prune PII from them but anything beyond that is very difficult, so it's worth keeping in mind that "everyone should see crash logs" comes with some hidden costs when you ask for it.

[Rybec]

Something very few people outside of security fully understand: Correlation also carries personally identifiable information. There have been multiple security studies on this, and while something like your CPU or your IP address or some other information about your system won't carry much personally identifiable information, as soon as you start collecting them packaged together, it becomes far easier to identify the specific individual. IP address can narrow your location substantially. Something like your CPU and the amount of memory in your system can narrow you down quite a bit as well, since even if you bought a completely premade Walmart machine, odds are only a handful of people in your region bought that same machine. And if you are the only person of that group who has ever downloaded Audacity, your CPU, IP address, and memory size can be exactly enough to identify you specifically. It might not tell anyone your name, but it is still enough data to uniquely identify you, and if someone has that, it isn't always hard to get a name, if they can get some information about computer purchases and which internet service provide you use (which can typically be determined from your IP address).

Basically, once you start grouping metrics together, you can start cross referencing them to get very specific identity information. (I have a brother with red hair, who is left handed, who used to live in a specific lower population state, who is a member of a particular religion. I did the math, and found the the odds suggested he was one of only 9 people with all of those attributes in the state. Narrow it down to the specific city, and he was probably one of two. And this is 5 metrics. The studies mentioned suggest that in most cases only 3 attributes are sufficient, especially if one is IP address.)

In short, exposing crash data to the public will probably provide unique identifying information 9 times out of 10. No individual piece of data needs to be obviously personally identifiable, because the real information is in the connections. (You want some personally identifiable data? My desktop has both an ATI video card and an Nvidia video card. That alone probably narrows me down to well under 100 people in the whole world. Add my IP address to that, and you probably have a unique identity. You might not be able to attach my name to that identity, but that's still enough for targeted advertising.)

[snoolian]

Thank god this response is not a tactical evasive maneuver...

[serebit]

I'm on board with this approach. I can see a clear benefit to both explicit error reporting and update checking, and I'm glad that a self-hosted system is being considered rather than a third party. Thank you for walking back PR #835 and listening to feedback.

[tralph3]

Well, the biggest problem I had with the previous PR was the use of Google, self-hosting is fine by me. And as I said, I'm perfectly fine with telemetry existing, I'm aware that its needed to aid development and improve the program for the good of everybody. All I ask is to have telemetry be ALWAYS OPTIONAL, and ALWAYS OPT-IN, and be clearly told that it's happening in the background. As long as everyone is aware of what's going on, and they give consent to allow that, I see no issue.

[mdedonno1337]

When the program starts, Audacity will check whether a newer version of the program is available for download. If there is a new version, the user will be shown a dialog to notify them.

Apparently it will be OPT-OUT, which is not OK for me.

[Rybec]

Also, opt out still requires the blanket age restriction, which is illegal in the context of the GPL.

[Kellegram]

This is significantly better than the OG PR, very sane approach, thank you for listening to the feedback. Telemetry is absolutely ok and is crucial for software development, I think the main problem was Google/Yandex, I would absolutely enable telemetry if it was fully anonymous and self-hosted (or at least with sane host, but self-hosted would be very ideal).

[falkTX]

I want to say that not everyone is okay with telemetry. It easily gets into a slippery-slope type of situation, as once a tool has network and analytics/metrics in place, extending the tracking is very easy.
Some of us are against the actual concept of analytics/tracking, full-stop, not even opt-in.

[ccoenen]

"ubiased" cannot be achieved for the simple reason that you will at least have the bias of people opting out, and of the people installing from packages (where this telemetry would have been disabled).

So, at best you have a false sense of security with a heap of collected telemetry that you talk yourself into being representative of something.

All the telemetry in the world also can't do the job of a designer. It may inform the choices of a designer, but there are better ways to make informed decisions.

[riking]

All the telemetry in the world also can't do the job of a designer

I hear there's a top notch interface designer with music experience around, wonder if they're available?

[Qix-]

unbiased insights

Please explain how a small, specific sample of data coming from only power users/those without privacy concerns constitutes as "unbiased".

[AntiSol]

Please explain how a small, specific sample of data coming from only power users/those without privacy concerns constitutes as "unbiased".

pffft, you just don't get it, do you? It'll have telemetry! Just like all the spyware on android!

I mean, sure, the data will be a little bit biased, but It'll have telemetry!

And OK, fine, because of the bias the data isn't actually useful, or will skew the UX towards kindergarten-grade users who don't know how to disable telemetry. But It'll have telemetry!

And yes, fair enough, it is a whole bunch of work for almost no actual improvement to the software, and that (and better) improvement can be achieved by other, less-invasive means without any of these downsides, but It'll have telemetry!

And yeah, sure, it'll be a little bit of a security risk, but It'll have telemetry!

You're obviously just a reactionary and not paying attention to what's really important here, which is: "how many buzzwords can we add to our quarterly report for management", and "think of how much we can sell this data for!", and "if I put 'added spyware to a prominent FOSS project' on my resume maybe I'll get a job at facebook!"

[Rybec]

I've discussed telemetry regarding things like button presses and feature uses with someone who used to work at Microsoft (on a project that used it fairly heavily). He expressed mixed feelings about it. On the one hand, it is nice to know how frequently features are used. On the other hand, it can be incredibly misleading. Specifically, they were considering removing a particular feature, because it wasn't used very much. During a focus group meeting with actual users, they ended having to quell a mutiny over the proposed removal, because it turned out that while the feature was rarely used, when people did use it, it was critical. Removing it would likely have lost them as much as 50% of their customers. Similarly, another feature that was used very frequently came up with another focus group, and they found that all of those clicks they were getting were mostly mistakes, because the feature was misleading and appeared to be something different from what it actually was. Both of these facts they would have learned from the focus groups with or without the telemetry, and it turned out this was generally true across the board. While the telemetry did give them useful data, the majority of the time, that same data was available merely by asking users how they were using the software. And in the cases where the data wasn't verified by the users, their interpretation of the telemetry was totally wrong, and this was only revealed by asking the users.

Telemetry in open source projects has never been that valuable, because users feel more comfortable sharing their opinions. You want to know how people are using the software, instead of trying to spy on them, just ask! Not only will you avoid the stuff hitting the fan like this, you will also get higher quality information.

The one thing my friend told me that MS does that is kind of like telemetry that actually provides useful information is inviting users to come in and demonstrate how they use the software. Unlike telemetry though, this has the added advantage of being able to ask users why they do things a certain way, which he told me was another source of actually useful information. (Also, he said that they learned that one of their users used a trackball, on the floor, with his foot, so he wouldn't have to take his hands off the keyboard when working. Yeah, that caused a lot of consternation for the employee who helped him setup his hardware, including touching the trackball...)

Anyhow, the moral of this story is that telemetry like this is actually far beyond the point of diminishing returns, and the cost is often not worth the benefits. Sure, there are occasional places where it is useful, but it can be very misleading just as often as it is useful, and the vast majority of the time, you can get the same data without the huge development effort merely by asking your users. And in open source software, you don't generally have to go out and solicit information from users. Just give them a place to do it, and they will happily provide information without even having to be asked.

[sykhro]

What about the concerns with vendoring libcurl and similar? Will the error reporting/updater component be separate from the main application?

[SISheogorath]

The raw IP address will not be stored or logged, but we will store and log a non-reversible hash of the IP address to improve the accuracy of the daily statistics.

What hash algorithm was up on your mind? The input space for an IP hash is rather small and could be trivial to brute-force. I hope you take that into consideration.

[crsib]

Sure, the state space will be reduced. Thank you a lot for your input!

[Be-ing]

You could do a GeoIP lookup and store the result of that instead of a hash of the IP.

[phire]

A regular changing seed is a great idea. Just make sure it's not logged anywhere.

If you only want daily uniques, then it can easily be rotated every day without any loss in infomation, while making brute-forcing near impossible.

[neobenedict]

Please truncate IPs to /24 for IPv4 and /48 for IPv6. Also either use a regularly changing seed or even better use something like argon2 to make building mappings back to the input value infeasible.

I would just truncate to /24 or /16, since IPv4 is limited to 4 billion IPs you can always build a lookup for it, and a changing seed makes storing it at all completely useless.

[Rybec]

This is a good point. At least for IPv4, the data space is only 4 bytes (actually much less, if you take out all of the private network and reserved sections). That makes it fairly easy to generate rainbow tables, to allow for trivially cracking any hash.

[AntiSol]

Is it just me, or does

"These decisions took time to arrive at because - despite my role as the lead on the project - calls on this specific issue are not mine to make"

sound a hell of a lot like a diplomatic way of saying "I have been instructed to add spyware to audacity"?

[SndChaser]

TLDR: This proposal is a big improvement over the original PR. However, there
are still quite a few issues that need to be addressed. (NOTE: I've been away
for a few days, so this is my initial feedback on Martin's (Tantacrul's) post. I'm
going to read the discussion and see if there are more issues that I feel need
to be addressed.)

Regarding features that require networking, we would like to include error
reporting and the ability for Audacity to check for updates (details below)

An option to view the complete error report data before it is sent

Questions:

1. Will the error reporting link to a ticket / case number? Will the user know
   this (it would be useful for the user to potentially add comments / context
   to error reports).

2. Will there be a system where users can see the information that has been sent
   to Muse Group? I mean this is both contexts: (a) reviewing the information
   before it is sent (as proposed), and (b) being able to see the previous
   information that has been sent. This is one of the features that make
   Firefox's reporting features very strong - the ability for the user to go
   through all reports.

3. Is there any further information around the use of this information: life
   cycle (How long is it stored? Can the user request it be removed?),
   administration (who will have access to this information?), etc.

We will self-host all collected data from error reporting and checks for updates

This is a much better approach than using Google and Yandex. The choice of
Senntry is a little on the iffy side (currently the server compoenent is under a
"Business License" that is not an Open Source license, but it will convert into
an Apache Licensed product in 2024. At least the SDK's appear to be under an
open source compatible license.) But it still begs for answers surrounding #3
above.

as a bad communication/coordination blunder that caught us completely by surprise.

Please recognize that it was more than bad communication. It was a downright
disaster as there was very little thought or planning in terms of implementation
that went beyond adding code to dump a bunch of information into third-party
databases.

As I've written before: the levels of thought and planning need to be carried
out on a level similar to that of Mozilla, KDE, and The Linux Foundation.
Anything short of this level of consideration, planning and administration
leaves a lot to be questioned.

Our intention was to make an initial announcement about our plans to introduce
telemetry on the Audacity forum

Moving forward I would suggest that this be expanded a bit. The Audacity Forum
is a great place for a discussion, however, on it's own, it doesn't have the
same level of reach that Audacity has itself. I've estimated that there are 11
Million installations of Audacity on Linux (questionable numbers, but not
unlikely), yet there are around 150,000 registered users on the forum. The
website averages around 2.9 Million hits per month.

I would suggest that all major changes, features, etc. be announced on the main
website. The article posted there could just be a teaser / short description,
with a link to a forum post with more detailed informtion and discussion. This
could serve many goals: (a) getting more traffic to the website (and potentially
downloads), (b) getting more interest and input from the user base, (c) getting
more contributions from the user community.

...the convenience of using Yandex and Google is at odds with the public
perception of trustworthiness...

Not just perception, relatively well documented issues with how information is
mined and used.

In the future, we may want to determine if there are any acceptable
alternative solutions that could achieve the same goal. Feedback would be
appreciated on this point.

I think for anything of this nature to be reasonable there needs to be complete
transparency along with well developed, documented and discussed procedures and
processes around this type of data collection. There should also be very
fine-grained user control over the information that is gathered - even more than
the control Firefox offers.

The reason? I can see situations where, for example, a user has developed a
private extension for Audacity in a business or research environment. Knowledge
of that extension existing could be a sensitive piece of information that
shouldn't be known outside of their working environment. This could even extend
to something like macros: the process or the effects of a process that a
researcher or employee uses to extract information from audio files could be
very sensitive.

In other builds, the error reporting and update checking code will be excluded
by default via CMake options.

This was an item that was in question with the original PR. There were comments
in the code review that there were conditions in which the code would have been
included regardless of the CMake option. (Specifically there were include
directives with no checking of passed in options from CMake.)

One of the things that can break trust is sloppy code. Even just including this
code, even if it isn't active, in an application can bring about fears of there
being a backdoor, or other untrustworthy possibilities. The dilligence around
this code needs to be checked and double checked constantly in order to allay
any such fears.

[mdedonno1337]

When the program starts, Audacity will check whether a newer version of the program is available for download. If there is a new version, the user will be shown a dialog to notify them.

Why is this not OPT-IN, or at least not clearly indicated as OPT-IN ?
Moreover, on stables distributions like Debian, this will be a big problem after hard-freeze.

Be aware that the FOSS community could hard-fork the project and add patches to change this behaviour, like it is the case for ungoogled-chromium; the main development of features for audacity will be done here and propagated in the downstream project if forked, patched as needed.

[juststur]

Update checks must have the ability to be turned off for all potential users of a system.

[jahway603]

I love how "Muse Group" is really called "MUSECY HOLDINGS LTD", as seen in their "Privacy Policy", and yet no else sees that as "shady" or "dishonest"... thoughts?

[Eugeny]

Why should anyone?

[ccoenen]

Nobody called it "Apple Computer Inc." when they were legally called that. (they dropped the "computer" part in 2007)

[ccoenen]

The results are in: users hate tracking. When offered the choice, the VAST majority chooses not to be tracked.
Methods that statement are based on seem pretty solid. Whichever number you look at, not a single stat is even remotely close to being up for debate.

https://www.flurry.com/blog/ios-14-5-opt-in-rate-att-restricted-app-tracking-transparency-worldwide-us-daily-latest-update/

[mdedonno1337]

@falkTX

Being realistic, I know this is a losing battle that there is no point even trying anymore.

I disagree with you on that. We can always fork and patch, like it's the case for example for ungoogled-chromium: link to the official repo (where the developpment is done), add some patches, and compile.

[mdedonno1337]

@ccoenen

And then you proceed to post three studies by companies offering ads and or cookie-consent banners aligned with their interests as counter examples?

I did not see that, I use the plugin "I dont care about cookies" which rejects all cookies by default ;)

[ccoenen]

Being realistic, I know this is a losing battle that there is no point even trying anymore.

I disagree with you on that. We can always fork and patch, like it's the case for example for ungoogled-chromium: link to the official repo (where the developpment is done), add some patches, and compile.

The sad thing is, that this will still make tracking the default. Because people by and large will probably stick with Chrome rather than Chromium. With Audacity rather than with <insert fork name>. I would really rather have a world where this wasn't the norm. This was not normal, and it should not be normalized.

[falkTX]

Being realistic, I know this is a losing battle that there is no point even trying anymore.

I disagree with you on that. We can always fork and patch, like it's the case for example for ungoogled-chromium: link to the official repo (where the developpment is done), add some patches, and compile.

Oh on that you are correct, but I was referring to more general terms.
I truly think it is a losing battle trying to get people to care about their own privacy and the implications of current software trends.
Well, they do care about their own privacy, it is just stupidly difficult to explain the issues. And if people have to make a choice between being tracked vs not using certain services, they go with the tracking but still use whatever they have an habit for already. For some services we no longer have a choice anyway, where companies have all the power and user data, like SaaS stuff. The only choice is not to use them, which sometimes it is not a choice anyway (when governments require SaaS deals)

[mdedonno1337]

Being realistic, I know this is a losing battle that there is no point even trying anymore.

I disagree with you on that. We can always fork and patch, like it's the case for example for ungoogled-chromium: link to the official repo (where the developpment is done), add some patches, and compile.

The sad thing is, that this will still make tracking the default. Because people by and large will probably stick with Chrome rather than Chromium. With Audacity rather than with . I would really rather have a world where this wasn't the norm. This was not normal, and it should not be normalized.

You are sadly right. I fight as I can...

[mdedonno1337]

I would like to have a bit more details regarding the access of crash and telemetry data for non-muse contributors (i.e. all the people that contribute to Audacity with a PR).

I think that all the data should be available freely, without any access-control restrictions.
This will be usefull for people to enhence performance and stability by contributing with a PR (from your point of view) and limit the incentive to collect and store undisclosed data (from my point of view).

[Rybec]

I disagree. Crash data can easily contain enough information to be uniquely identifiable. Security researchers have shown that even 3 pieces of apparently non-uniquely identifying data can together be used to uniquely identify someone. Crash data that contains information like CPU, OS, and memory amount, comes out to four pieces of data (the fourth is that the person has downloaded and is running Audacity) and thus has fairly high odds of being uniquely identifiable. Add IP address to that (which narrows it down by region), and you are pretty close to a guarantee of unique identification.

[davidak]

Have you checked out OpenTelemetry? If you want to use telemetry, it probably makes sense to use an open standard. I just found it by accident today and haven't used it, so no idea how usable it is.

[alyti]

OpenTelemetry is designed for cloud microservice architecture, not applications running on millions of desktops.

[chrschmidt]

Hi Tantacrul,

With regards to the GDPR, I would argue that a non-colliding hash of the IP address is not sufficient. There are roughly four billion IPv4 addresses; assuming a non-colliding hash that's a pretty small table, e.g. 32GB for SHA256, for a simple reverse lookup. In this case it can only be considered the same as storing the address in plaintext. There are reasons why e.g. Google's Analytics has to blank out the last octet to comply with GDPR.

What is the point of an update check anyway? If your linux distribution manages audacious, the user won't be able to update it, because they aren't root, and any form of update that bypasses the package manager is wrong to begin with.

I can only recommend you make the update checking code a compile-time option, giving distro managers a way to deactivate it, while keeping it in to remind people compiling themselves, or running common pre-packaged versions like windows, flatpack, etc to update.

[ccoenen]

here we go again... please let's not make exceptions that make this kind of data collection a "windows only" or "regular user only" thing.

Can we please take a stand for everyone, not just for us linux users / developers?

[keith-macleod]

Here's my stand: I loathe applications that check for updates, automatic or not. But, more importantly, I don't have any inherent trust for software that includes networking code if networking is not a part of its core function. Proprietary software will usually leave you with no choice, but hopefully this move will prompt someone to fork, and maybe actually bring the codebase out of the stagnation and developer intransigence which it has seen for the past decade.

[Rybec]

It's worth noting that the public address space of IPv4 is actually considerably smaller than 4 billion, because there are several ranges of reserved addresses as well as some ranges of private network addresses that you wouldn't need to include in a rainbow table.

(Everything from 224/8 to 255/8 is multicast or reserved. That's 12%. 10/8 is reserved for private networks, as is 192.168... 127/8 is reserved for loopback. 0/8 is also reserved for local identification. Just those are 13.3%. You've also got ~18 other /8 addresses allocated to companies like Intel, Apple, Daimler, and Ford and government agencies like the U.S. Department of Defense, the U.S. Postal Service, and the U.S. Army, that can probably be excluded, for over 20% total exclusion. That's barely more than 3 billion addresses to generate a rainbow table for, and if you start digging a little deeper, you can find /16 level address ranges used by other governments and companies that you can probably also get away with excluding. I would estimate that if you start excluding large businesses that own large ranges of IP addresses (not including ISPs), you can probably get that down to fewer than 2 billion addressses.)

[kompowiec]

Telemetry is a practical tool that tells us a lot about how an app is performing or underperforming (is this new feature being used a lot? Is this button being discovered? etc.) We assumed that making it opt-in would allay privacy concerns but since this isn't the case, we are dropping it. In the future, we may want to determine if there are any acceptable alternative solutions that could achieve the same goal.

just ask the user during installation or after, it's not a big deal.

[xabhax]

Tldr: sorry we go caught. Now we are changing our plans completely because we got caught. Now that we can't make money off tour data, we are currently deciding how we can add telemetry so we can sell it.

[DuckBergen]

this aged horribly

[medmedin2014]

You killed one of free open source apps by your actions, please buy other propriety apps and let our precious open source app alone.

[p0s0]

this statement aged like milk LOL

[ghost]

i dont like audacity anyways but fuck you

[Eugeny]

What are you, 12?

[anka-213]

Will we get a response to the actively anti-copyleft CLA that has now been instated? The thread about it was locked without any answer to the many concerns that were raised.