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

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!)

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.

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)

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!

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.

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.

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

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.

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.

MUSE should rebrand it as "Streisandicity".

You are not the only one!

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!

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.

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.

@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?

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

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.

https://github.com/cookiengineer/audacity

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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

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.

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!

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

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

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.

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.

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?

See original post:

Offline Use - The Privacy Policy does not apply to offline use of the application.

Wouldn't that still be restricted use though? You're requiring that individuals (<13) either disconnect from the internet before using the application or recompile it without the problematic bits. I don't see how this resolves the "unrestricted use" clause, in any universe.

GPLv2:

The act of running the Program is not restricted

GPLv3:

This License explicitly affirms your unlimited permission to run the unmodified Program.

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

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

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.

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.

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.

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.

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

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.

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

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.

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?

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.

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.

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

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.

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.

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

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.

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

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

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.

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.

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.

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

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.