Clarification of Privacy Policy

[lengthwave]

A quick statement to address the concerns around our new Privacy Policy.

We believe concerns are due largely to unclear phrasing in the Privacy Policy, which we are now in the process of rectifying. In the meantime, we would like to clarify what seem to be the major points of concern:

• Selling Data & Sharing - We do not and will not sell ANY data we collect or share it with 3rd parties. Full stop.
• Data Collection - Data we collect is very limited.
  • IP address - which is pseudonymised and irretrievable after 24 hours.
  • Basic System Info - OS version and CPU type.
  • Error Report Data (Optional) - Sent manually by users as part of an Error Report.
• Additional Data - We do not collect any additional data beyond the points listed above for any purpose.
• Compliance with Law Enforcement - We will not collect or provide any information other than data described above with with any government entity or law enforcement agency.
  • Compelled by Court - Data is not shared upon an agency request; we will do so only if compelled by a court of law in a jurisdiction that we serve.
  • Limited Window - After 24 hours the IP address being collected is irretrievably lost.
  • Jurisdiction Requirements - We operate in many countries around the world and this is a standard policy requirement for providing services in many jurisdictions, regardless of the depth of data collected or nature of service.
• Offline Use - The Privacy Policy does not apply to offline use of the application.

We are working with our legal team to revise our privacy policy to more clearly communicate the above points and our intent.

--

About the term 'Personal Data'

GDPR classifies an IP address as something that potentially counts as 'personal data', which is why we use that term in the Privacy Policy. This is necessary for two features being introduced in the next version of Audacity:

• Automatic Updates - checking to see if there is a new version available
• Error Reporting - an opt-in feature for users to send error reports to us

As mentioned in the Compliance with Law Enforcement above, we take steps so that the IP address we collect is non-identifiable after 24 hours.

--

We do understand that unclear phrasing of the Privacy Policy and lack of context regarding introduction has led to major concerns about how we use and store the very limited data we collect. We will be publishing a revised version shortly.

In the meantime, the Privacy Policy doesn't actually come into force until the next release of Audacity (3.0.3). The current version (3.0.2) does not support data collection any data of any kind and has no networking features enabled.

[TechandMusic462]

After the telemetry, CLA, and now this, do you expect any trust from the community? MUSE still does not understand open source software at a fundamental level. I am holding out for a fork to gain momentum, and will stay on pre-MUSE Audacity until then.

[jdlesemajeste]

All they need to do is to make Audacity not crash every 5 minutes! That's all! To me, it's like a guitar getting telemetry so they can study what changes to make to the guitars UI..

[Rybec]

I use other software for synth and Audacity for mixing/mastering. Sadly, it has been a while since I've had time to do any of that, but the last time I used Audacity, I found it's synth capabilities to be lacking (or at least, sufficiently hard to use that it wasn't worth my time). I used to use Rosegarden for sequencing and synth audio "rendering". Last month I discovered LMMS and Helm, which are pulling me back in. Neither of those is really good for mastering though, so I do want to be able to use Audacity (or a fork) without a bunch of extra garbage coming along for the ride.

And yeah, telemetry is actually not that useful, if you use good design practices, like talking to your users. Part of the reason telemetry collection is more common with proprietary software than open source software is that users of open source software tend to be very willing to share their opinions, without even being asked, so long as you provide a place for them to do it. Companies like MS don't want open user forums, because they don't like to hear that they are wrong, so they feel like they need telemetry to get this information. I know a guy who used to work at MS, and he said that a good portion of the time, what they thought they were learning from telemetry was actually wrong. Frequent use of a feature might indicate that users are finding it really valuable (which is what they assumed), but it could also indicate that it is poorly labeled (thus people click because they think it is something else) or that the spacing in the UI is causing a lot of misclicks (which was the case in many circumstances). And a feature that doesn't get used much might not be very useful (what they assumed), or it may be a critical feature with a narrow but important use case. Telemetry doesn't tell you the intent of the user, and without that, it's useless. And talking to users will reveal the same information as telemetry even if you don't have telemetry, making telemetry almost completely pointless if you are using it correctly. It's easier to solicit feedback from users than to write telemetry code. It's cheaper than the bandwidth and server space for collecting telemetry data. And, collecting telemetry uses additional computing resources on the user's computer, significantly reducing performance. (This is also an issue I have observed with MS products. Some of them are prone to constant mild lag and periodic lag spikes, and those products also happen to be the ones with the most telemetry. When you are collecting comprehensive telemetry data in a program like MS Word, you are doing extra work for every single key press. The result is, if you aren't on a high performance machine, and you are a sufficiently fast typist, it is really easy to type faster than Word can handle, because every time you hit a key it has to check which key it was and increment a counter. It's not a lot, but it's definitely enough!)

[austux]

Hopefully a fork will be available quickly, I know LibreOffice seemed to happen pretty quickly when it was time.

both LibreOffice and MariaDB were responses to monopolisaton moves, in that when a mega-corp bought out the mini-mega-corp that was principle developer of the projects they forked from, the purchase (in Europe) was only permitted if the purchaser continued to support development — which they did, albeit dragging their heels as much as possible for commercial reasons.

after a time, many of the developers (in each project) took matters into their own hands, and each group forked.

one of the ‘parent’ projects is no longer completely FOSS, as in, the project as a whole now includes proprietary data dictionaries and other entities, even though the actual software itself is still GPL2 (except the Client Libraries have additional FOSS-related permissions), so the entire project is not; the other has added more database engines, including a crash-proof derivative of MyISAM.

[jamison-io]

I'm an open source music software developer (see - https://github.com/mtytel/vital https://github.com/mtytel/helm) and I'm pretty shocked at the public response to this.

Data privacy concerns stem from data brokers and data giants that make money collecting data like Google, Facebook, Twitter, Reddit and Microsoft. This privacy policy from what I can tell is pretty standard and any company that has any user data like email addresses or does any crash reporting has to have terms like these (including the law enforcement clause). Ubuntu and Mozilla have similar policies: https://ubuntu.com/legal/data-privacy/2016-02-08 https://www.mozilla.org/en-US/privacy/

Mainly though, doesn't everyone see how ironic it is to complain about this on Twitter, Reddit and GitHub?

Incredibly well put. This bit of data collection, which looks to be quite benign, is hardly the hill upon which to make a brave stand.

And, unfortunately, the irony of complaining on Twitter, Google and their ilk is likely lost on a great many of those who are so unhappy.

(also, Vital is amazing)

[differentprogramming]

Just because we can't change the fact that corporations are authoritarian doesn't mean that we should accept corporate sorts of practices when we DO have a say.

And the problem isn't the data collection, which at this point is non-existent, it's the foot in the door that the privacy policy creates by pretending that there IS serious data collection!

[masumahmed]

[shoogle]

We make no secret of the fact that update checking enables us to collate limited bulk statistics (i.e. total number of people using Audacity across each country / OS / Audacity version). This was the exact compromise we proposed in #889 and was accepted by the majority of people in that thread.

[Summertime]

also worth noting that, much like the APIs of the rest of the world, some easy defense against buggy clients is appreciateable. If an implementation of the update check code hit a bug and in turn spammed the server, being able to target a specific version for special treatment is very useful.

[jimsalterjrs]

The question remains as to why collect that information at all? Has law enforcement already asked you for IP addresses regarding the update mechanism?

How, exactly, do you propose to do update checks without exposing the user's public IP address...?

[575johnson]

If you live in China or Hong Kong, and you have a piece of audio that is critical of the government, you're probably going to think twice about using Audacity if MUSE shares your IP address with the government, which detains you.

That's the problem of collecting and sharing your IP address with law enforcement - even if it's available for just 24 hours.

[goodevilgenius]

The question remains as to why collect that information at all? Has law enforcement already asked you for IP addresses regarding the update mechanism?

How, exactly, do you propose to do update checks without exposing the user's public IP address...?

You don't have to collect the IP address just because you have it. You could just not record it. As a web developer, I can tell you that there is a lot of information that I could collect about my site visitors, but don't. I have the data, and just leave it.

[gunqqer]

It is too late, you know. You've already destroyed any good will the community had. With the CLA and the proposed privacy policy and the (failed) attempt at adding telemetry, us nerds know exactly what you are trying to do. As you've no doubt seen, none of us are having any of it. Forks are being made already. MUSE has no idea how the FLOSS community works, and the community knows it. Good job burning Audacity to the ground.

[thediveo]

MUSE should rebrand it as "Streisandicity".

[jdlesemajeste]

You are not the only one!

[VidiotGeek]

I'm clearly in the minority of people willing to give MUSE the benefit of doubt on the initial stumbles. As a user on macOS, I'm already much less of a FLOSS hardliner than, say, someone compiling their own Linux kernel from source on Arch. I've no doubt that the hardliners will proceed with a fork, and applaud them for it! But I am not immediately ruling out ever using the main line Audacity version going forward. Worst case scenario, we end up with TWO first class, open source, feature rich, simple audio editors to choose from. If nothing else, the lesson learned here is that you only get ONE chance to make a first impression!

[JakobBruenker]

What is the reason for having Error Report Data collection be optional but Basic System Info collection not be optional?

[databoose]

Both are optional, but update-checking is opt-out whereas error reporting is opt-in. The system info sent during update-checking is similar to the information your web browser sends during an ordinary HTTP request.

Example check for updates 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)

That, and of course your IP address, is all that gets sent during a check for updates (you can check for yourself here and here). The IP address is stored as a hash and becomes irretrievable after 24 hours when the salt is discarded.

Outside of updates the application should not be communicating with the internet without opting in flat out, it is an audio editing program, not a web browser, not a chatting application, not a video game.

It's also questionable as to why these hashes of IP address would be stored on the server anyways, the only reason i can think is ddos protection, but again, this is a required connection, the user didn't consent to it, and it isn't necessary to exist, it just puts a users privacy more at jeopardy with no option to opt out.

[shoogle]

Outside of updates the application should not be communicating with the internet without opting in flat out

Indeed, all network features are opt-in except check for updates.

it just puts a users privacy more at jeopardy with no option to opt out.

There is an option to opt out of update checking in the Preferences.

[dancojocaru2000]

@shoogle Why store the data in the request? I mean, yes, the User-Agent is there, and the IP is in the connection, but just, y'know, don't save them?

[goodevilgenius]

@shoogle Why store the data in the request? I mean, yes, the User-Agent is there, and the IP is in the connection, but just, y'know, don't save them?

In particular, an IP address is sensitive information. It has been stated several times that the address is stored for 24 hours before being anonymized. Why is that information, which is the most sensitive, stored at all for any length of time? If you're looking for aggregate data, you don't need to store the IP address for any amount of time, hashed or not.

If you didn't store the IP address, which you don't need at all for this feature, than your draconian privacy policy wouldn't be necessary at all, in particular, the requirement against individuals under 13 years old using it, which is ridiculous.

[StefanCristian]

If you didn't store the IP address, which you don't need at all for this feature, than your draconian privacy policy wouldn't be necessary at all, in particular, the requirement against individuals under 13 years old using it, which is ridiculous.

It's completely alright if they we can opt-out, even though Audacity has literally no need for data in order for users to get updates.

[i1u5]

Time for forks.

[AndreiSva]

https://github.com/cookiengineer/audacity

[SkaveRat]

or, y'know, not collect that data in the first place and you don't need all the legal stuff

[austux]

I use Audacity only on a midi-tower desktop (Lubuntu), and on a laptop (DebIan), neither of which are directly exposed to the broader Internet.

The midi-tower sits behind a NAT and is router-firewalled.

The few times the laptop has connected directly have been via hotspot-over-USB plugged into a mobile (cellular) phone (which is seriously dynamic IP, and also effectively NAT in that no inbound connections are possible), have not involved Audacity running (I typically take the laptop to a quieter outdoors location for recording narrations, then using it only there).

My position is similar to stevemagruder, except I prefer the option of auto-updating software, and generally dislike mandatory updating. Even the youtube-dl Python script is updated by hand (-U) occasionally, as this is always more up-to-date than the packaged editions.

[Wombat-AU]

Once was a user. So because the level of childish paranoia here is absolutely mind blowing I wish to disagree with some that apparently MUST be believed. So if you dont like some honest judgment voting... stiff. Thank you.

[bl-ue]

Really, it's mostly opinion-based. Some people don't like telemetry, others don't mind it. Some people are very vociferous about their opinions. The folks here who think they dislike it only represent a small fraction of Audacity's users, and lots of those users are non-technical and I bet don't care a cent about analytics and such.

[differentprogramming]

The current argument isn't over telemetry, it's over the privacy license.

[bl-ue]

Yes, but lately it's been evolving towards telemetry...

[ohno9119]

Stop going "uh oh we got caught again.... sorry we wont do again..." and actually fix your mistakes.
Even if you wont pull something like this again we have lost all trust with the current maintainers of Audacity and people are already using forks. Audacity will be the new OpenJDK/OpenOffice/XFree86.

[shuffleQ]

I don know if they are deleting comments, but can you all please understand that he is a designer and not involved with this. If you want to complain do it here or elsewhere, but Tantacrul's comment sections are really for discussing his videos, and last time I checked there is none about Privacy Policies.
And about that "you": MUSE has no business in Tanta's YouTube channel. He is an employee, not the other way around. They are not his social media team.

[lne01]

Stop going "uh oh we got caught again.... sorry we wont do again..." and actually fix your mistakes.
Even if you wont pull something like this again we have lost all trust with the current maintainers of Audacity and people are already using forks. Audacity will be the new OpenJDK/OpenOffice/XFree86. (Also we know that you guys are wiping all negative comments about Audacity under Tantacrul's videos. Dont try to hide that aswell)

Also you can disscuss anything in a youtube comment unless it violates youtube's terms of service or gets filtered by the word filter put up by the creator.

[shuffleQ]

Also you can disscuss anything in a youtube comment unless it violates youtube's terms of service or gets filtered by the word filter put up by the creator.

thank you I didn't know that /s
The point is, there is a legit reason to do that because thats simply not the topic and he might not want to get bothered with that, as said he has nothing to do with this, imagine people raiding your home because your employer did dipshit.

The "you" im talking about is referencing MUSE (the current maintainers of Audacity) and not Tanta.

yes I know. And I was saying that I am 99.99% sure that they have no access to his channel whatsoever, because its tantas and not theirs. They cant delete comments on his videos, why would they have access to it? Its his personal channel and not the MUSE or Audacity one. Does your employer have access to your social media channels? Can they delete comments below your posts? No.

[goodevilgenius]

the current maintainers of Audacity and people are already using forks

#1213 (comment)

Four devs seem to have quit yesterday, from what I can tell.

[a-hurst]

We believe concerns are due largely to unclear phrasing in the Privacy Policy

I think what a lot of people are also taking issue with, especially after all the backlash against the basic telemetry and CLA issues, is that these major, scary-sounding changes are popping up seemingly out of nowhere without any sense of community consultation. Right now, I think people feel caught off-guard yet again and are frustrated that the maintainers aren't demonstrating that they care about what the broader community thinks of their decisions. Not saying you don't, just that it's quite clear people don't feel like you do.

Even having a project blog where major decisions are announced and explained well in advance of their implementation would have dramatically decreased the blowback from all these incidents, as the broader community wouldn't feel like the maintainers are trying to sneak things in while no one's paying attention. The more transparent you are about this stuff, the shadowy and sinister people will make you out to be.

[Kavaeric]

This is what I feel is the crux of this issue. Stated plainly most (not all, see the GPL considerations with under-13s) of the changes implied by the new privacy policy are pretty agreeable: this is the infrastructure you need for automatic update checking, IP address collection is needed because that's how the internet works, 24-hour retention is understandable to debug faulty update requests or just a plain DOS attack, you can't refuse a request from law enforcement no matter how trivial your collected data is or how unlikely you think it is. It's ultimately mostly legalese that just reads really scarily to the uninformed.

But, yeah, the fact that people reading this stuff aren't terribly informed isn't a good look as it is. Pushing changes, no matter how minor you think they might be, even if they are policy-based without any code to back it up yet, without consultation to a user group isn't great in any circumstance, but I'd imagine it stings particularly badly when it comes to the FOSS development community. I'm not really a programmer myself, but my understanding that the entire git system is based around consenst with code: you can't randomly force code on anyone if they don't want to merge, and for the most part (with open source projects anyway) you can't hide anything. The system forbids a "quiet update" in any real sense and so the act of pushing what is effectively a quiet update to the privacy policy that people just accidentally found out about over the course of the weekend is going to be a bad look to say the least.

I should probably take the time to reiterate that blaming Tantacrul for "ruining Audacity" is misplaced at best; the guy's job is to make buttons look pretty, and I'm doubtful he has any hand in writing these policies or handling PR. Wouldn't be surprised if he just learned it around the same time we all did. In any case, directing critcism at him isn't just stupid, but also means criticism wouldn't be reaching the people actually responsible for these kinds of changes. The last thing I think we all want is for someone who really has no concrete say in these matters becoming the meatshield sponge for criticism while the people actually in charge can get away with whatever.

[goodevilgenius]

Even having a project blog where major decisions are announced and explained

https://www.audacityteam.org/posts/

They have a product blog, and didn't really use it.

[geekredux]

Tantacrul put himself squarely in the line of fire when he posted his YouTube video called "I'm in charge of Audacity". (It says "designing Audacity" now, but it didn't originally.)

[AsuMagic]

If error reporting is opt-in and those points are required to implement automatic update checking:

• Why is logging IPs for 24h a requirement at all?
• For how long is the OS version logged? You do not mention for how long that data is kept, which looks like mandatory telemetry to me.
• What does the OS version string contain (e.g. on Linux specifically)? Some custom kernel version strings could possibly identify someone.
• Is automatic updating opt-in/opt-out/enforced as a popup on first launch, i.e. would it be possible to get Audacity to not initiate any connection to your servers?
• When installed through a package manager, hence not requiring automatic updates through the conventional channel, will Audacity initiate any connection to your servers (when not reporting an error)? I assume this is usually patched by maintainers themselves though.

[darkstar]

IANAL, but I guess the answers to your questions are:

• 24h IP logging: Because basic IP logging for a limited time is required in certain jurisdictions if you provide any "online service" (which automatic updating and crash-reporting apparently counts as, according to their lawyers)
• retaining OS version: an OS version is not PII and thus there's no requirement of deleting it. being able to correlate different reports by means other than PII (e.g. a unique kernel version string) is not against the GDPR
• OS version string: you can check that in the source code for yourself (note that it might change before release, so check often)
• popup on first launch: you can also see that in the code, but I guess until the release arrives nobody will know for certain
• package manager: that is a question you have to ask the package maintainers, not the upstream developers

[wafles38]

Their privacy policy says

Other information we collect, such as OS version or CPU information is not identifiable.

Basically, they don't think it's identifiable, or because it's not legally identifiable, then they feel like they can track this.

[Atemu]

Really, all of that info should be in the privacy policy.

Best just put them into "maintainer stories": "As the maintainers, we want to retain your IP adress for max. 24h because we are required to by ", "As the maintainers, we want to collect error logs if you agree to send them in order to make Audacity better. We will delete your log once we've reproduced your issue ourselves and fixed it or 3 months" etc.

This way it's clear what information is being sent where for what purpose and under which conditions.

[goodevilgenius]

24h IP logging: Because basic IP logging for a limited time is required in certain jurisdictions if you provide any "online service" (which automatic updating and crash-reporting apparently counts as, according to their lawyers)

IANAL either, but I am a web developer who has built online services that must, for basic functionality, record user data.

Never in my 15 year career have I ever been required to log IP address for any reason at all. If a boss wanted to do so, I would strongly push back against it, and demand an explanation.

I have used third-party telemetry services (at my bosses insistence) that record the IP address, but I have never collected it myself within my services, and I have certainly had services that don't record even have any third part collection of them.

[PizzaCube]

I dont buy it.

Time to start a new software i dont want to get sued by the music industry or something when you tip them off i am making an audio file because for some reason it is sending data out on the internets even though it has worked fine offline for years.

for some reason you care about what audio wavs i am cutting for some reason who knows and want the data on everything i do.

[ddawson]

Also, differences in compiler version and even local hardware could produce differences in the builds, unless you go out of your way to build the exactly the same perfectly generic build, with the same compiler version and build. For small scale stuff, this is probably very practical. For something being used in all sorts of machines, with different kernels, different compilers, and so on, I'm not sure this is practical.

Well, this sort of thing is being done already elsewhere, in some well-known projects. Apparently, GNU tools (including GCC, a pretty big project that is used all over) was made reproducible in the '90s, though it's not clear what the status of that is these days. Debian (which, for those who are unaware, Ubuntu and some other distros are/were based on) has seriously tried to do reproducible builds for a few years. There's also mention about how it has been implemented for Bitcoin and Tor.

but if you are building locally already...

Yes, that's a good point. I myself am using Gentoo, where (almost) everything is built from source on the local system as a matter of course, so this issue is (almost) moot on my systems. So, what is the point of reproducible builds? Well, not everyone is able or willing to build everything themselves. But if there are people they trust, those people can do the verifications for them (probably with digital signatures too).

A very well designed build system might be able to make this sort of verification easier though.

Just as an example, the software mentioned in connection with Bitcoin is Gitian. Not really a build system per se, but wrapping everything in a VM that provides a consistent environment. Not vouching for how useful it is, and I'm not sure just how trust works in it (something about a bunch of people independently signing their builds). But it sounds useful, at least, if you can actually run it.

But yeah, the real concern is that we even have to be worried about this in the first place. When you can't trust the software to the point that this becomes an issue, there is already a much deeper issue that caused it.

I can't disagree. Well, we're talking about a corporation here now, so there should automatically be some distrust, IMO.

[differentprogramming]

Do I remember right that libraries for Golang are always distributed as source instead of in some directly executable form?

Maybe a certain kind of security risk could be dealt with by having a system where source is the only way to distribute files.

[Rybec]

That makes sense. The one thing I don't like about reproducible builds is lack of optimization. I am sure part of the reason you use Gentoo is that compiling locally means your software is optimized to your specific system. I'm currently using Debian, and I do compile locally sometimes, sometimes for performance but others because no pre-built binaries exist for what I want on Debian's repos. I once even did Linux from Scratch (which only went up to a functional terminal), to see what optimization benefits I could get. (It was good, but lack of a GUI was a problem as well as maintainability issues.) I have considered Gentoo and may eventually do it.

That said, I can see wanting reproducible builds for Windows (where platform specific optimizations are extremely rare anyway) and for users who can't compile locally or just don't want to.

The Bitcoin thing seems odd to me though, because local optimization seems like an extremely valuable thing, when performance correlates directly with profitability. Maybe there's something I don't know about it...

[ddawson]

The one thing I don't like about reproducible builds is lack of optimization.

Isn't that just a problem with pre-built software in general, though? To ensure the greatest number of people can actually run the software, they have to be conservative about instruction set extensions, and they probably don't want to be too specific about non-compatibility-impacting optimizations, either. GCC, for example, has its -march= option that controls the instructions output and -mtune= that controls machine-specific optimizations that don't affect instructions used, and they have a long list of specific CPUs, but using any of those, especially with -march=, is not possible when you don't know what CPUs your users have the software is going to be used on a variety of CPUs. You just have to stick to generic minimums like e.g. "i686" or whatever is appropriate. At least, that's my understanding. I don't think reproducibility has any effect on this. But I suppose I could be missing something.

I am sure part of the reason you use Gentoo is that compiling locally means your software is optimized to your specific system.

That, and having control over which features are built and which are not, without having to build things manually (unless you want to, of course). The package manager, Portage, uses "USE flags" for this, which can be set/unset both globally and per package.

I'm currently using Debian, and I do compile locally sometimes, sometimes for performance but others because no pre-built binaries exist for what I want on Debian's repos. I once even did Linux from Scratch (which only went up to a functional terminal), to see what optimization benefits I could get. (It was good, but lack of a GUI was a problem as well as maintainability issues.) I have considered Gentoo and may eventually do it.

I think if you can do LFS, you can certainly do Gentoo. It's less bare metal, thanks to Portage's automation (EDIT: and the initial system tarballs they provide to get you started), though there's a bit of configuration you still have to do by hand.

The Bitcoin thing seems odd to me though, because local optimization seems like an extremely valuable thing, when performance correlates directly with profitability. Maybe there's something I don't know about it...

High performance mostly only matters for miners, but Bitcoin mining requires cutting-edge specialized hardware (SHA-256 ASICs required) to compete at all. I'm pretty sure having a slightly unoptimized Bitcoin node is less of a concern for them than out-of-date hardware, which operates in the range of... I think it's now around 100 terahashes/sec in one rig. I suppose exchanges need good performance too. But for most running regular, non-mining nodes, it's not a big deal; their role is mostly to verify transactions and already mined blocks, which is not time-critical.

[Rybec]

You are totally right. Pre-built software generally has to be pretty generic, unless you want to provide binaries for a bunch of different versions of each major architecture. That's part of why reproducible builds can be a problem though. If you are building for different versions of the same major architecture, that's a lot of builds that have to be reproducible. I don't know of many projects that do this though, so maybe this is just pedantic.

Good point on having control over build options. I don't have any experience with Gentoo, but it sounds like it is really well organized to give the user a ton of control over how things compile, without having to do much manually. That's pretty awesome! And yeah, I'm not worried that Gentoo would be hard for me. It's just a new system that I would have to learn to work within, which means an initial learning curve that I just haven't had time to deal with.

For non-mining nodes, that does make sense. Performance is only really critical for mining, so if they aren't mining, it won't make much difference. And yeah, when it comes to verification, I can see how reproducible builds would be important to ensure no one is trying to leverage the node software to cheat the system. Thanks for the explanation!

[catboy-oss]

You could always just not log the IP or retain it at all, just drop it on the floor? You still get your counts.

[tvmanus]

@Rybec Well, your IP is logged by ISP, by every server, providing pretty much any service on the Internet, maybe except those, which are intended for hiding identity. There is a technical need to keep those logs, if you ever worked in operations, you would know this, it is not about democracy, it is about ability to fix that damn server if it breaks. In my opinion, if we speak about democracy, secured storage for 24 hours, is a very reasonable approach. The fact that keys are destroyed in an irreversible way, pretty much guarantees that cops would have to be very well organized and obtain a search warrant ahead of time. Unwarranted search will not produce any results, since keys will be destroyed by the time they would be able to explain to a judge why the whole infrastructure was seized and the operations halted.

[Rybec]

I've been running my own web servers for over 15 years. There is not and has never been a "technical need" to log IP addresses beyond sending out the responses to the requests they came with. And no, always-on recording IP addresses doesn't significantly help fixing broken servers. The only time IP address ever mattered in fixing server issues was for test requests I sent myself or had other people send remotely, and capturing those requests was trivial, without ever having to get into the logs.

And again, you don't have any special authority to decide what is ethical or reasonable here. You can pretend everyone else is less competent than you if you want, but even real competence wouldn't qualify you to decide what is fair privacy and what isn't.

(For the record, I agree that 24 hours is probably reasonable, but I acknowledge that the only authority I have to decide what is fair privacy is my own vote. I recognize that this is only my opinion, and that I have no special authority to unilaterally define morality. This is really an issue that needs public dialog because again, no individual has any special right or authority to make this kind of decision. Honestly, odds are the public would agree that 24 hours isn't a problem. I mean, if you call me on my cell phone, it will log your phone number permanently. If you mail me a letter, I'll have your return address for as long as I please. IP addresses are only different in that dynamic ones change now and then, so they aren't reliable in the long term. But, the ultimate decision isn't mine or yours. It should be made by everyone collectively, because that's the way civilized society works. If the majority thinks IP addresses should be treated as highly private data, that's how they should be treated, regardless of people whining about it making it harder to debug or catch criminals.)

[elsandosgrande]

Public dialogue of this nature relies on people being well-informed, or otherwise the person or group that's best at fear mongering likely wins, though that's a whole other can of worms that I'm not qualified to open.

[tvmanus]

IP addresses are only different in that dynamic ones change now and then, so they aren't reliable in the long term

ISPs keeps this as part of accounting and billing records for years. They also keep the "flow" data from their edge firewalls for months, typically the flow data contains source/destination IP, source destination ports for TCP/UDP, duration of the flow, average packet rate, number of packets, packet size distribution, number of octets in each direction, and some other metadata, like correlation with other flows. This is a massive amount of PII. Lawful intercept is using all this data in conjunction with additional data sources, such as logs from the service, in a nutshell, it is relatively easy to pinpoint who, when and what has been doing on the Internet, unless you get into "Onion" type of the cloud, which purposely randomizes and mixes traffic in order to erase individual signatures. I'm not approving those practices, but this is like driving your car with a license plate, everyone can see it, and potentially not only cops, can figure out who it belongs to.

[Rybec]

Lots of text to merely support exactly what I already said. The Postal Service keeps track of physical addresses pretty much indefinitely. Phone service providers keep track of who had what phone numbers as part of accounting and billing indefinitely. So, like I said, the only difference with IP addresses is that the dynamic ones automatically change now and then.

So I guess, thanks for agreeing with me?

[overcast07]

I'm disappointed that you didn't address the GPL compliance issue that was brought up in the comments of #1213 (i.e. whether children will still be technically allowed to use Audacity once the privacy policy comes into effect).

I'd prefer to give you guys the benefit of the doubt where possible, but I think we all expected better than whatever this debacle is.

[lengthwave]

We're still working out the actual mechanics, but functionality of the application will not be restricted.

[nyuszika7h]

The problem is that they're legally not allowed to collect PII from children under 13 (see: COPPA, GDPR).

[differentprogramming]

So, that means that if you're collecting that data, then you've made the wrong decision.

[Rybec]

The GPL doesn't say the functionality cannot be restricted. It says use of the program cannot be restricted, and it is pretty explicit that this is in the context of the license agreement.

Indeed, someone posted an excerpt that says if some license restriction is added, it is invalid and may be summarily removed. And that means that the age restriction actually has no bearing whatsoever on COPPA and GDPR. What this means is that an age restriction won't protect you, because it is completely invalid according to the terms of the license.

[Rybec]

I would suggest that you get a real open source lawyer to help you with this, because on the one side, you are creating a massive liability for yourself by violating the GPL, and on the other side, you are creating a liability for yourselves by risking the collection of data from people whom it is illegal to collect data from, with no legal protection, because the restriction you put on the software to protect yourself is completely invalid and thus cannot offer any legal protection.

The right solution here may actually be to formally pass this off to those working on the fork, so that you don't put yourself into a legal position where you absolutely cannot avoid losing. That, or you could just not collect data at all, and remove all if your anti-features that "require" you to collect data. I mean, it's your choice, but you've placed yourself very firmly in a position where you have legal liabilities looming from both sides.

[majestrate]

have you considered moving development to be incorporated in a country that is a little less pushy about "lawful interception"? The Russian Federation is probably one of the worst choices to be located when it comes to such legislation, besides maybe mainland China.

[majestrate]

It also seems that one of audacity's dependencies have use of cryptographic primitives that are restricted by Russian import law and USA export law, specially AES. If you really want to be true to the spirit of the law audacity's inclusion of these are potentially in grave violation. I have heard the Russian Federation is very pedantic on this issue. This would probably be yet another reason to not incorporate in the country you are currently located in. If compliance with law enforcement really is an issue it would be wise to get some clarifications on the inclusion of these.

[kosumosu]

I'm pretty sure Russian import law only relates to devices, not software.
And what country do you consider less "pushy"? NSA will get you anywhere. Russia and China are probably the only places to hide your data from it.

[trumad]

[trumad]

Deleting because github made it seem like my comment didn't get posted. And the thing I said about minors was addressed above.

[trumad]

Please explain why you need an ip address at all.

It's hard to believe what a mess is being made of this. Why not run a beta program, with a version of audacity which sends error reports and data, which beta users are happy to share along with their feedback? Why force it into the main product like this and alienate everyone?

[zelch]

Frankly, you want the IP address for at least some short period of time to handle things like DOS attacks, and in figuring out if you even are facing a DOS attack vs say, you screwed up a release and it's flooding your system with update checks.

Removing it after 24 hours is definitely better than keeping it in your apache/ngnix server logs for however long you happen to keep them. (Could be a week, could be years.) Which is what most entities would have done pre-GDPR.

[AverageHelper]

Ah, that makes sense. Thank you for clarifying that for me

[differentprogramming]

This is nonsense, DDOS prevention can be done at a firewall level, or at a network level, it doesn't have to connected to audacity in any way and it doesn't have to be coded into update software.

[tommytran732]

Frankly, you want the IP address for at least some short period of time to handle things like DOS attacks, and in figuring out if you even are facing a DOS attack vs say, you screwed up a release and it's flooding your system with update checks.

Removing it after 24 hours is definitely better than keeping it in your apache/ngnix server logs for however long you happen to keep them. (Could be a week, could be years.) Which is what most entities would have done pre-GDPR.

But then why would they keep the hash for 1 year?

[thomasf]

Which is what most entities would have done pre-GDPR.

Most companies that are serious about security still keep stuff like access logs a long time and I have been told by specialists that keeping those logs fall within "the legitimate interests pursued by controllers in specific contexts" (article 40.2b). You often need to be able to audit things that happened months or sometimes years ago.

According to the GDPR 72 hours of a breach you are required to report the breach to the supervisory authority and having logs of what source requested which kind of data going back in time having logs could help you answer a lot of https://gdpr-info.eu/art-33-gdpr/ .

I personally know of two cases (which I won't disclose) where criticism has been put forward after a breach because companies got scared by GDPR and started purging too much of the wrong kind of log data so they could not really answer exactly which data has been breached, better audit logging kept for more than a month would have been able to answer those question with precision.

These kinds of logs should of course be focused on only logging whats needed for the security concerns, not being shared with any third party except for the purpose of security related investigations and be focused on logging only what it needs to.

[ROBERT-MCDOWELL]

@carmatope
Oh, one brain awake, more? let's hope....

[fennectech]

Is the IP being collected in the software itself or as a byproduct of sending the data to your server and simply dumped to a log thats nuked every 24 hours resulting it being unpaired with the records that were sent. The IP address is by far the most concerning to most people.

[fennectech]

It changes things in terms of intentions. Its what they are doing with that ip that matters. Honestly i don't see anything wrong with collecting a user agent string like this. Its incredibly minimal and useful data to determine what versions still need to be maintained and what platforms to focus paid development time on. This is the kind of thing that can legitimately be used to improve the product for the primary user base. Also. Crash reports are INCREDIBLY valuable and having a built in way for users to send them goes a long way for those who don't want to manually raise an issue to still help improve the product.

[goodevilgenius]

@fennectech They've stated a couple of times here that they actually collect the IP address for 24 hours, and then hash it after that. They don't get rid of it, they just hash it, presumably so that they can group requests from the same IP address together for their logs.

[tvmanus]

collect the IP address for 24 hours, and then hash it after that.

I read it differently, they hash IP addresses in the logs, so you can group the requests and run statistical analytics, but they keep the salts of the hashes for 24 hours, so the IP addresses can be reveled for the troubleshooting or other purposes stipulated in the Privacy Policy. So the logs are kept longer, and since they don't contain PII, the retention policy is not disclosed. In a nutshell, they lose ability to recover IP addresses after 24 hours, but keep the logs longer.

[Rybec]

Anyone want to explain to me how throwing away the salt makes any difference whatsoever? I am very well educated in how hashing works with respect to passwords, and having the salt only matters if you also have some other unique identification (a username) associated with the salt, so you know which salt to use. If all you have is hashes and no other unique identifier associated with them, the only way the salt matters is if you hash the IP address with every salt you have recorded, to find the right one.

Since I am certain they are not going to hash every IP address thousands of times for every request to find the right salt, if the salt actually makes any difference at all, then they have some other uniquely identifiable information as well, that they are using to determine which salt belongs to the connection. And if this is the case, then they will still be in gross violation of EU law, because they haven't said what that uniquely identifiable information is.

[Rybec]

Also, they really haven't been clear on how they are recording the IP address. At first they just said they record it and then throw it away after 24 hours. Then they said they keep a hash permanently but throw away the IP address after 24 hours. Then they said they throw away the IP address immediately but keep a hash and throw away the salt after 24 hours. At this point it is very unclear what they are actually doing.

As far as the hashing goes, let me clarify: Hashing is supposed to be irreversible, by design. When applied to passwords, the intent is to secure the password in case an attacker gets access to the database but still allow the service to verify new logins. This is done by storing the hash (but not the password), and when a new login comes in, that password is hashed and compared to the original hash. If the password is correct, the hashes will also be identical. Now, salt is added to avoid rainbow table attacks, where common passwords are hashed, and then the passwords and hashes are stored in a database, allowing an attacker to merely lookup the password using the hash. A salt is extra random characters added to the password before hashing, but the salt has to be stored, because it will also have to be added to the password before hashing when logging in. Now this is the critical part: The salt is recorded with the other user information, and the salt is different for every user. If you don't know the username, you don't know which salt to use. This is part of why you can't login with just your password. For salt to work, you must have some uniquely identifiable information about the user that isn't hashed, so you know which hash to use.

Thus, if Muse is using salt with their hashes, and they have the ability to match IP addresses from different requests, then they are also storing some uniquely identifiable information in plain text, which they are using to lookup the salts, so they know which salt to use for which request.

(They may be using a different technique that is not called salting, where a rolling modifier is used that changes every 24 hours, which they use the same way as a salt. If it isn't unique and random for each user though, it isn't a salt. I forget what this is called, but I've used something similar as well, in my own authentication systems, to further increase password storage security. If they are calling it "salt" though, I am going to assume they know their terminology and are calling it what it is, especially since a Privacy Policy that says they are using salt would allow them to do so even if they aren't now.)

[ROBERT-MCDOWELL]

@zocker-160
ok so you are using a VPN although you are complaining here... Sorry I don't catch it.

[Rybec]

I'm not using a VPN, and I am complaining. Quit acting like the problems one person has don't apply to everyone. One person using a VPN is only relevant if everyone is using a VPN, and we shouldn't have to use VPNs to maintain reasonable privacy.

If you have a good argument, go ahead and present it. So far though, all you've done is argued that Google and FB doing bad things justifies Muse doing bad things, and that people already using privacy mechanics have no reason to complain. These are both disingenuous and logically false arguments.

[fennectech]

Logging IP (for even 24 hours) can go a long way to detecting and preventing abuse. Lets say one user decides to maliciously generate thousands of reports in a short period of time. With no way yo identify this you could easily loose this in traffic. But seeing that the same IP range (even if its just 3 octets) you can know something is fishy here and throw out the data between their first and last connection attempt. This could be used to thwart artificially boosting stats on ones platform to attempt to get priority support for their OS or many other nefarious things. Sure. There are ways arround it. But its something. If you have an idea that its happening you can start to log more temporarily too find out what IP is abusing your system and blacklist it. All servers should have a temporary (even if just a couple days) log of IP addresses connecting and look at it every so often to identify signs of abuse.

…

Sent from my iPad

On Jul 7, 2021, at 10:30 PM, tvmanus ***@***.***> wrote:  I am not aware of any jurisdictions that require IP addresses for every connection to be retained. In Russia, every online operator is mandated to keep the log for 5 years, and the full session content for a year, literally, you have to run traffic recorders. Plus all ISPs must record all the traffic, including transit operators. Realistically nobody does it, as it is technically challenging to collect and keep many copies of ALL the traffic, but you can be sentenced in a very real prison for non-compliance if a cop does not like you personally. On the other hand EVERY web server keeps a technical log for diagnostics and troubleshooting. I have not seen any single web server which does not store logs for at least some period of time, with typical retention from 24 hours to few weeks. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[Rybec]

Unwarranted police searches can go a long way in catching criminals. That doesn't make it right.

[ROBERT-MCDOWELL]

I'm always astonished by the rate of ignorance of how the matrix we are trapped works, despite of all the absurdities we are enduring since march 2020, despite of the intelligence of computer developers.

[ROBERT-MCDOWELL]

@Rybec, you are marking 3 mistakes in your judgement:

1. if ignorance among people is evil, well, so help me to fix it asap or we are all going to hit the fan
2. Mix google,FB,Tw (CIA/GOV corporation support) and Muse (open source free developers) is indeed evil
3. You are completely missing the fight, look at what we are living today because "lazyness" of ignorants, trusting evil and hating angels, our entire freedom rights are collapsing, not becuase of Muse, but because of massive mind corruption.

[Rybec]

I don't see the mistakes. I don't care who Google, FB, Twitter, or Muse are. I judge based on merit and behavior. Being a company of open source developers doesn't magically absolve Muse of any wrongdoing. Evil is evil.

Not sure what you even mean by 1. You certainly aren't trying to fix ignorance. You are trying to promote a narrative that big companies doing bad somehow justifies small companies doing the same thing.

As far as 3 goes, again, evil is evil. Muse is making itself part of the problem. Evil massive corporations aren't somehow more evil that evil small businesses. Evil is evil. Muse is part of the problem, and it is part of the problem I can contribute to fixing. I'm already doing all I can against Google, Facebook, Twitter, and so on with another project. That doesn't mean I shouldn't do something about Muse, even if it is just engaging in the conversation.

Just in case you missed it, Evil is evil. Being big doesn't make big businesses inherently more evil that small businesses. If Muse is trying to behave like Google, FB, and Twitter, it is no better, regardless of who it employs and the licensing on its software. Indeed, I am more concerned about a company that claims to care about open source software doing this. At least Google is honest about its crimes against our privacy. Muse appears to be pretending to be something it isn't.

So no, I've made no mistakes. You have merely misunderstood what I have said, or you disagree with the idea of judging based on behavior or merit.

[ROBERT-MCDOWELL]

Ok dude, are you a user or a code maintainer of Audacity?
if you are a user:

1. did you already make a donation to help the developers from all the years you use Audacity for free? like you did with corpomafias, you just leave Audacity for another open source software, there are tons of this kind.
   Btw Mister Rybec (or maybe are you a kid for me) the developers need to debug the code and avoid further bugs and crashes.
   and the only way for them is collect data or it will take another decade to fix them...

if you are a code maintainer.
2) better to chat in private with the main developers and make an agreement with them.

[Rybec]

Not sure what or why you are asking. Donations are irrelevant. I use the product, and it is free and open source. That means I have a stake in it, whether I have donated or not. And while I am not a maintainer for Audacity, that is neither relevant nor any of your business, just like whether or not I have donated. Indeed, your two requests here for my private information tells me a lot about your position on privacy.

As a very experienced software developer, I am fully aware of how debugging works. Somehow, in nearly all projects I have worked on, we have managed to fix bugs based mainly on reports provided completely voluntarily by customers who contacted us, without any automated data collection, and fairly quickly, so it is completely false to claim that the only way to fix bugs in less than 10 years is to collect data. And for the record, IP address was never part of the data we needed to resolve bugs, even in the web based products I've worked on. (And for the web stuff, I was working in Q&A, so I was directly involved with both the data collecting and the debugging.)

Maybe you work in a company where the developers do not have sufficient competence to debug without involuntarily collecting tons of crash data, but I've always worked with competent developers who can manage with reports voluntarily submitted by customers. And to be totally honest, the actual output of crash reports has very rarely been helpful in debugging for me. What actually helps is asking users what they were doing when the crash happened, which is typically not include with automatic reports, even if you include a dialog asking customers this exact question. The ones willing to contact you without being asked or coerced, however, tend to be far more forthcoming with that information. In short, no, coercively collecting data doesn't actually contribute that much to fixing bugs. Having a good relationship with your customers, however, is incredibly valuable when it comes to getting the information you need to fix bugs quickly.

TL;DR You are wrong. Automated crash reports are a lazy alternative to talking to your users and having a good relationship with them.

[RawrBag]

oh no another company has my dynamic ip address, boo hoo

[ROBERT-MCDOWELL]

To Audacity developers, why not to offer to the user like chrome and other software to accept or not the option "crash report"?

[petersampsonaudacity]

To Audacity developers, why not to offer to the user like chrome and other software to accept or not the option "crash report"?

@ROBERT-MCDOWELL - that is EXACTLY how MUSE have it already in RC2 (and RC1) for the upcoming 3.0.3 for both Crash reporting and error reporting. I have been testing both of those Release Candidates. It''s optional each time you get a crash or relevant error report.

The Update checking is easy to opt out of from the new Application preferences - I have been QA testing that too.

[Pokechu22]

To my understanding, it works exactly that way already:

audacity/crashreports/crashreporter/CrashReportApp.h

Lines 15 to 19 in 6f5ed6b

	//! Crash reporter GUI application
	/*! Used to send crash reports to a remote server, or view them.
	* Shows brief report content, and allows user to send report to developers.
	* Reporting URL and other parameters are specified as a command line arguments.
	*/

audacity/crashreports/crashreporter/CrashReportApp.cpp

Lines 280 to 281 in 6f5ed6b

	auto okButton = new wxButton(frame, wxID_ANY, XC("&Don't send", "crash reporter button"));
	auto sendButton = new wxButton(frame, wxID_ANY, XC("&Send", "crash reporter button"));

[petersampsonaudacity]

To Audacity developers, why not to offer to the user like chrome and other software to accept or not the option "crash report"?

[ROBERT-MCDOWELL]

@petersampsonaudacity
so why so much noise from the users so? :-\

[petersampsonaudacity]

@petersampsonaudacity
so why so much noise from the users so? :-\

I'm guessing they haven't actually tested the Release Candidates

[nicemicro]

Thank you for the clarification!
Will there be an option to compile Audacity without version checking? I use Arch Linux, and the package manager keeps it as up to date as the maintainers I trust deem to be sufficient to be updated.
Will there be a way to do error reporting via e-mail instead of directly sending the data over? Would be helpful in terms of privacy and also, for machines that are not connected to the internet (exporting the error report to a file, take it to an other PC, send an e-mail...).

[shoogle]

Will there be an option to compile Audacity without version checking?

Yes, this option exists and is the default when compiling from source, so Linux packers would need to explicitly override this option if they want to use our update checking.

Will there be a way to do error reporting via e-mail instead of directly sending the data over? Would be helpful in terms of privacy and also, for machines that are not connected to the internet

We have no plans to accept error reports via email at this time, and I'm not sure how doing so would help with privacy compared to a dialog within the app that shows you exactly what data will be sent and then gives the option to "Send" or "Don't send" the error report.

A machine not connected to the internet is really an edge-case and you wouldn't be able to send emails from such a machine anyway. I wouldn't expect many people would bother to carry data over to another machine via USB stick just to send an error report via email, and doing so on an air-gapped machine would undo some of the security benefits.

If you experience a crash/error and don't want to use the error reporting feature, I would suggest creating an issue on GitHub that describes what you were doing just before the error occurred. In many (but not all) cases, this will be enough for somebody else to reproduce it and potentially submit an error report of their own. GitHub issues are public, so you shouldn't include add any report data to the issue unless you are absolutely certain that it contains nothing sensitive. You might consider uploading the Audacity file you had open at the time of the crash, but again, only if it contains nothing sensitive.

[Meyers07]

Really shocked until i realized it was 2015 (i keep legacy versions regularly) and most recently 2020 since i downloaded and used Audacity and most importantly as stated:

...two features being introduced in the next version of Audacity:

Automatic Updates - checking to see if there is a new version available
Error Reporting - an opt-in feature for users to send error reports to us

The fact that Audacity didn't have auto-update functionality to at least 2020 is a blessing i think.

[differentprogramming]

You know I keep writing that the law isn't what the privacy policy pretends it is because if it was the entire internet and all of the web servers would be illegal.

And I think that comment gets deleted over and over and over because I can't find even one of the many places I said it.

[Pokechu22]

The comments (or at least some of them, such as #1225 (reply in thread); I'm not going to check every single one of them) are still there; they're just collapsed under the "view more" links. Only the first 3 replies are shown by default it seems.

[differentprogramming]

I actually looked by opening all of those.
3 or 4 times.

[RawrBag]

God the amount of ignorance, People read the fking source code,this so normal for so many companies, Muse is trying to cover their ass with a privacy policy, which they legally have to do. as far as im concerned this data collection is literally miniscule.

[Rybec]

And if you were the only user of the software, your personal opinion would mean everything. As far as I am concerned collecting telemetry data isn't "literally miniscule". And evidently many thousands of other users agree. Your opinion isn't the only one that matters, so quit pretending that it is.

Also, I am really getting tire of the "everyone is doing it" argument. That's not even valid. Find a good argument or quit showing your ignorance.

[themisir]

Thanks for clarification. The people will never understand that without knowing what's wrong with app you can't improve it. Most of audacity users aren't developers nor using GitHub, so they probably won't going to open issues or include log files. So putting automatic bug reporting is a great idea towards improvement. And probably most of you already know that web works with identifying clients using IP addresses. So to send bug reports to their server they will get to know client IP address anyway whether they store it or not. Even if they don't store, the governments probably will already know that X.X.X.X client connected to audacity server either from dns query (not everyone uses dns over tls) or connection logs.

If anybody doesn't wants that they might opt out or firewall the app since most of those people probably already familiar with those tools.

[fossdd]

No, MUSE simply can't provide Open Source. For the open source community Audacity is dead. You aren't open source anymore. See you at Tenacity!

[matteoturini]

Telemetry isn't the biggest issue. The CLA is very scary. Free ~~forever~~ until some company buys the project. Em ter., 13 de jul. de 2021 12:56, fossdd ***@***.***> escreveu:

…

No, MUSE simply can't provide Open Source. For the open source community Audacity is dead. You aren't open source anymore. See you at Tenacity! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1225 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQRVPRLMLVDCA46CJJPIF5TTXQLUVANCNFSM47236UIQ> .

[Alex4386]

At least, Code (of audacity) itself is open source.
And this made sure that MUSE Corp is now taking similar position with Microsoft-style "Open Source" Approach.

Since there are already cases of people using VSCodium instead of Visual Studio Code purely due to telemetry concerns,
I personally think This backfire is totally expected. Also I think this should not be silenced and calling it as "MISUNDERSTANDING" at all.
(P.S. I am the one who uses original Visual Studio Code with Telemetry enabled though, and also I don't think Telemetry is total evil. but I think this is important to be pointed out and to be clear since this is a collective project from contributors and Audacity community, And also, People saying no to telemetry means "no telemetry at all". Even though you think it is totally reasonable to collect one. The proper response should not be "We did anonymizing and We only collect data that's insufficient to track down each individual user". It should be "You can turn off all telemetry by compiling with this option" or "tick the disable all telemetry checkbox during installation process".

(Sorry, but Microsoft has done better at this one. VSCode does allow disabling all Telemetry (including total disabling of all online services) on their "official" build by just ticking a checkboxes)

At this point, I don't care you (MUSE Corp) doing any anti-pattern for telemetry or something. Just make sure people can completely opt-out from the "Required" telemetry (including OS/IP collection) entirely.)

---

For this moment, I think
only viable option for people (with privacy concerns at the moment with this type of response from MUSE Corp) is just creating a fork.
and backport some "features" from audacity without telemetry.
(In case MUSE Corp think this is stealing, This is very normal in FOSS spaces, Remember GNU/Iceweasel and Mozilla Firefox?)

(but it seems MUSE Corp looks like they are going with literally same track with FastHub Pro License Commercialization Drama Non-sense happened in 2017 according to new CLA. Yuck. Have fun time contributors suing each other.)

TL;DR: Audacity is now basically an equivalent of Microsoft's "official" build of Visual Studio Code.
For anyone concerned, Just use the fork. There are some cases that forks became better alternative than original tho.
(MariaDB and MySQL)

[Alex4386]

But by the way, can't you just use GitHub Releases or with GitHub-provided API for automatic updates?
You guys do releases on GitHub, tho.

Was it totally necessary to use YOUR SERVER and STORE IP Address for 24h?
For telemetry, Sure. Just make sure users can opt-out from it on the very start-up of application.

But why....? You guys were already using GitHub Releases for distributing your software.
Was it just linking users to https://github.com/audacity/audacity/releases/latest or Integrating with GitHub API and automatically download binary a pain?

I'm very curious about that auto-update design.

[AudacityTeam]

An update on this issue can be seen here: #1353