Audio editor Audacity denies spyware accusation(bbc.com)
bbc.com
Audio editor Audacity denies spyware accusation
https://www.bbc.com/news/technology-57721967
85 comments
I thought it was more about the fact that it's opt-out (if I understand it correctly!).
Companies have existed for centuries without needing constant telemetry... we have many methods that do not require telemetry: surveys, emails, forums etc.
In fact, there is a subreddit here [0] that the devs/owners could easily ask questions.
[0] - https://old.reddit.com/r/audacity
Edit: Also, I think people are totally jaded with telemetry. There are some companies that take data whether you want them to or not so people are naturally wary... what's to stop them pushing out an update that grabs a massive pile of sensitive data and then when the backlash starts, they throw their hands up and say "sorry"... much like Google do/have done.
Companies have existed for centuries without needing constant telemetry... we have many methods that do not require telemetry: surveys, emails, forums etc.
In fact, there is a subreddit here [0] that the devs/owners could easily ask questions.
[0] - https://old.reddit.com/r/audacity
Edit: Also, I think people are totally jaded with telemetry. There are some companies that take data whether you want them to or not so people are naturally wary... what's to stop them pushing out an update that grabs a massive pile of sensitive data and then when the backlash starts, they throw their hands up and say "sorry"... much like Google do/have done.
Lots of open source software uses opt-out telemetry.
Sure, I also want it to stop, but there are so many doing it.
Sure, I also want it to stop, but there are so many doing it.
> but there are so many doing it.
Really? That's a weak argument if ever I heard one.
Perhaps it's time to take a stand and say "no more!"
What's to stop them adding in something else later that "accidentally" grabs IP addresses, and sends them "accidentally" to their third party analytics company who doesn't give a shit about your privacy. That company then takes their other data, joins it all together and adds to the picture of you that you never asked them to create!
When you open this door, there is no closing it.
The argument comes down to this (for me, at least): You got the software to this point without telemetry. Why do you need it now? Is the application all of a sudden unusable?
Edit: I forgot! They already take your IP address but my point still stands!
Really? That's a weak argument if ever I heard one.
Perhaps it's time to take a stand and say "no more!"
What's to stop them adding in something else later that "accidentally" grabs IP addresses, and sends them "accidentally" to their third party analytics company who doesn't give a shit about your privacy. That company then takes their other data, joins it all together and adds to the picture of you that you never asked them to create!
When you open this door, there is no closing it.
The argument comes down to this (for me, at least): You got the software to this point without telemetry. Why do you need it now? Is the application all of a sudden unusable?
Edit: I forgot! They already take your IP address but my point still stands!
I disable telemetry whenever I can. But the major vendors already use it everywhere (Firefox, vscode, the rust installer, just a few examples) - I've disabled it in all of those, but most don't, and we don't always pay attention to apps that add this as a "feature".
Correction: rustup (rust installer) did collect telemetry but it seems to be removed now. https://github.com/rust-lang/rustup/issues/341 The reputation may stick, as we know :) No worries now.
Correction: rustup (rust installer) did collect telemetry but it seems to be removed now. https://github.com/rust-lang/rustup/issues/341 The reputation may stick, as we know :) No worries now.
audacity have done a text book piss off the community on going commercial.
They have done everything wrong.
banning use of the for under 13s not a good move IMHO.
They have a load of money and want to know how audacity is used?
How about just ask?
They have done everything wrong.
banning use of the for under 13s not a good move IMHO.
They have a load of money and want to know how audacity is used?
How about just ask?
I mentioned this in the last thread here, but due to COPPA, generally it is illegal for businesses operating in the US to collect data on children under 13, even if you ask (there are exceptions but usually you need to prove that you have the parents' permission). They are doing what is required by the law, and in fact it was probably already illegal for children under 13 to use the product in ways that could generate personal data. So nothing has really changed, it seems they are only explaining what the situation already was.
If they hadn't started collecting data, the age of their users would continue to be irrelevant.
It still is irrelevant, if you use it offline, or you opt out of the analytics. Yes, an adult will probably have to set it up that way for them, but this has always been the case with any internet-enabled computer: it falls on the parents (or the school, childcare service, etc) to set up parental controls and oversee the child's online activity.
I think their approach is pretty sane - I don't know if it started out that way, but 'opt in only' seems like the defaults we want. But like parental responsibility, that's aside from the main point.
The fact that they are collecting this data now subjects them to COPPA requirements, thus the restriction to people over 13. If they hadn't started collecting data, they would not have had to comply with that restriction.
The fact that they are collecting this data now subjects them to COPPA requirements, thus the restriction to people over 13. If they hadn't started collecting data, they would not have had to comply with that restriction.
That seems to not really be relevant, if you want to have a data-driven development process, then you have to, you know, collect data. If you said they should just use email or github issues or something, and have people submit their feedback manually, those have the same deal, and they still would have to comply with COPPA regarding that data.
Yes, that is true - they would have to comply regarding the data collection. However, they would not need to impose limitations on the usage of application itself, only on the tools/platform used to submit the data.
> Companies have existed for centuries without needing constant telemetry
And if you're fine with software from the 1700s, you're welcome to use that, but if you want UX improvements to Audacity, there's only so much that can be done without telemetry.
And if you're fine with software from the 1700s, you're welcome to use that, but if you want UX improvements to Audacity, there's only so much that can be done without telemetry.
Quantitative (ie telemetry) data gives us the what, not the why.
Qualitative (usability testing and other observation methods up to and including ethnography) can give us the why (users seem to do what we didn't expect).
Modern UX design can make use of both modes of user research such that they support each other. I.e discover the what via quant and understand it better via qual, to land at a solution.
Or discover both why and what via qual, and then determine severity (how many users get stuck in a given way) via quant.
But of course, there needs to be explicit consent such that trust is not breached, no matter how inconsequential the data collected is considered to be. The decision belongs to users.
Apparently there wasn't consent.
Edit: Ideally, should anonymised usage data in OSS projects be public? Such that we can see the data and design decisions made based on it? Perhaps this would generate more of the trust that was desired here.
Qualitative (usability testing and other observation methods up to and including ethnography) can give us the why (users seem to do what we didn't expect).
Modern UX design can make use of both modes of user research such that they support each other. I.e discover the what via quant and understand it better via qual, to land at a solution.
Or discover both why and what via qual, and then determine severity (how many users get stuck in a given way) via quant.
But of course, there needs to be explicit consent such that trust is not breached, no matter how inconsequential the data collected is considered to be. The decision belongs to users.
Apparently there wasn't consent.
Edit: Ideally, should anonymised usage data in OSS projects be public? Such that we can see the data and design decisions made based on it? Perhaps this would generate more of the trust that was desired here.
Companies like Apple and digital research were producing great UI/UX in the 80s, well before widespread internet usage made telemetry a viable option for companies.
(I mean the 1980s, just to stave off any attempts to send me back in time to observe computing in the 18th century).
(I mean the 1980s, just to stave off any attempts to send me back in time to observe computing in the 18th century).
Apple OS pre OS-X, and Windows 3.1/95, used to crash all the time. A big part of the improvements in crashes (talking to people in the companies) is automatic submission of errors.
Also, Apple was selling Apple IIs for the modern equivalent of $5,000. I'm sure Audacity could achieve some great in-person UI studies is people were willing to pay that kind of money.
Also, Apple was selling Apple IIs for the modern equivalent of $5,000. I'm sure Audacity could achieve some great in-person UI studies is people were willing to pay that kind of money.
doesn't take $5000 to open a survey monkey account.
I don't understand this argument. "Apple did good UX without telemetry in the 80s, so you should be able to do good UX without telemetry now, Muse".
Like, what do people think they want the telemetry for? Are they planning to sell the treasure trove that is "how many people clicked on the 'select audio sink' button" to the highest bidder?
You can tell them "do it without telemetry" all you want, but in the end it's just not going to be as good as if they had feedback.
Like, what do people think they want the telemetry for? Are they planning to sell the treasure trove that is "how many people clicked on the 'select audio sink' button" to the highest bidder?
You can tell them "do it without telemetry" all you want, but in the end it's just not going to be as good as if they had feedback.
not any more, they've blown all their good will
I'm pretty certain Ardour and Reaper don't have any telemetry, and they have UX a million times better. Audacity can be muuuuch better with having to stoop to telemetry.
So is the UX unusable right now?
Edit: >but if you want UX improvements to Audacity
You insinuated that the only way to improve the UX (your comments insinuates that it needs improving) is to use telemetry
Edit: >but if you want UX improvements to Audacity
You insinuated that the only way to improve the UX (your comments insinuates that it needs improving) is to use telemetry
They're (reasonably, in my opinion) looking for telemetry in order to improve the program.
The original Reddit post (Discussion - https://news.ycombinator.com/item?id=27727150) stated Audacity would collect data necessary for "law enforcement, litigation". That doesn't sound like telemetry for improving the app.
The original Reddit post (Discussion - https://news.ycombinator.com/item?id=27727150) stated Audacity would collect data necessary for "law enforcement, litigation". That doesn't sound like telemetry for improving the app.
That line says "if any", it looks like they had to add it for legal purposes, but IANAL.
Even if it's only added to cover their asses or for legal purposes, with no intention to exercise that provision, it's already there, which means that changing their mind in the future and making use of the provision costs them nothing, and they won't have to tell anyone about it.
Since when do laws require anyone to state that they might in the future intend to comply with the law?
You're really bending over backwards here.
You're really bending over backwards here.
> They're (reasonably, in my opinion) looking for telemetry in order to improve the program.
By every metric they collect new Reddit is better than old Reddit.
From my perspective new Reddit is low density user hostile crap.
By every metric they collect new Reddit is better than old Reddit.
From my perspective new Reddit is low density user hostile crap.
There are only a handful (<1%) of people who care about having Sentry (crash test collection) or GA (click or view analytics without PII) in an app. But those people are very vocal about it. So it looks like a lot of people care about it.
We are not even talking about tracking for ads or for surveillance. It is only about logs for crash analysis and UX improvement.
We are not even talking about tracking for ads or for surveillance. It is only about logs for crash analysis and UX improvement.
Lots of closed-source software gets user feedback constantly, and it often becomes worse. I suspect this is due to a number of reasons:
- Users ask for things which are not actually good, and so the UI becomes worse.
- User feedback is difficult to consolidate, and so the mass of the user feedback makes the product worse.
- Users think they know what they want, but actually don't, and so the product becomes worse.
- Users ask for things which are not actually good, and so the UI becomes worse.
- User feedback is difficult to consolidate, and so the mass of the user feedback makes the product worse.
- Users think they know what they want, but actually don't, and so the product becomes worse.
No. And we've done well without telemetry for decades. And don't be daft, multimedia was one of the biggest drivers of technology over the last 5 decades. Telemetry has only been practically possible in the last decade or so.
Is it really so hard to just ask people? No need to spy on them. Also I don't think spying on them will improve the product. Telemetry has limited value in the first place.
Is it really so hard to just ask people? No need to spy on them. Also I don't think spying on them will improve the product. Telemetry has limited value in the first place.
> Is it really so hard to just ask people?
Having worked on a variety of user-facing products for several years, I can tell you that it is hard. It depends on your audience but typically many users don’t report problems. If they do, they don’t give you enough details to diagnose the issue. And why should they? They’re not knowledgeable in how your system works. So you have to reach out to them and ask for more information. Maybe they need to reproduce the problem to give it to you. If you’re unlucky, they won’t be able to reproduce it. Even if they were able to, you have now taken more of their time.
The ask could be as simple as “hey this went wrong, but you can click here to send us the error info and someone will get back to you” and many users will STILL not share the information. You might think that they must not care that much but often times you’d be wrong. Users can be surprisingly irrational at times.
Having worked on a variety of user-facing products for several years, I can tell you that it is hard. It depends on your audience but typically many users don’t report problems. If they do, they don’t give you enough details to diagnose the issue. And why should they? They’re not knowledgeable in how your system works. So you have to reach out to them and ask for more information. Maybe they need to reproduce the problem to give it to you. If you’re unlucky, they won’t be able to reproduce it. Even if they were able to, you have now taken more of their time.
The ask could be as simple as “hey this went wrong, but you can click here to send us the error info and someone will get back to you” and many users will STILL not share the information. You might think that they must not care that much but often times you’d be wrong. Users can be surprisingly irrational at times.
In a lot of the software I've written for businesses telemetry was critical in being able to get quick answers to things like "is anyone using this specific portion of the app?" Or "are the new users using the application yet? "
If you're expecting an answer different than "yes" to either of these questions, it means you've made a very expensive mistake much earlier in the process.
The right time to ask if anyone will be using a specific portion of the app is when the feature is being proposed, not after it's been implemented and released. Replacing discovery up front with post-release telemetry is a sure way to lose money.
Conversely, if you're not making that mistake, then you don't really need telemetry to tell you what you already know.
The right time to ask if anyone will be using a specific portion of the app is when the feature is being proposed, not after it's been implemented and released. Replacing discovery up front with post-release telemetry is a sure way to lose money.
Conversely, if you're not making that mistake, then you don't really need telemetry to tell you what you already know.
Why is it critical and what does it give you?
This will be a nice case study in if collecting telemetry actually works - will audacity actually have improved in a year from now?
I think there's plenty of data for that, given that it's how UX designers generally do things nowadays. What I'd like more to see is a telemetry library or service that respects your data, so we can say "oh, they're using OpenTelemetry, so that's fine", where OpenTelemetry guarantees that it will respect user data.
That sort of thing can't really exist. Consider this scenario:
A developer of an email client wishes to use telemetry to figure out which IMAP features are most worth supporting. They could, say, log every IMAP server you connect to. Or instead run an IMAP ID command and log the response. Or they could ship the CAPABILITIES response verbatim. Or maybe they could carefully parse the CAPABILITIES response and only report the existence of specific tokens (which may include capabilities not yet supported by the client) back as telemetry.
There's a gradient of scuminess going on there, all to (purportedly) track the same information. What matters for privacy concerns is the choice of data being tracked; how it's actually collected and transmitted is comparatively unimportant. So what you really want is someone to approve the choice of what to track, which isn't what a third-party library or service is likely to give you. And you don't need to necessarily route it through a third party; if we're talking about open-source software, the data that's being tracked is public knowledge--an organization that reviews telemetry and gives a stamp of approval would be sufficient to achieve the same ends.
But even then, I suspect many people are going to have different ideas as to what data is safe to track. Even the list I gave for tracking IMAP, I fully expect that there exists sharp disagreement about whether some of those entries would be okay for telemetry purposes.
A developer of an email client wishes to use telemetry to figure out which IMAP features are most worth supporting. They could, say, log every IMAP server you connect to. Or instead run an IMAP ID command and log the response. Or they could ship the CAPABILITIES response verbatim. Or maybe they could carefully parse the CAPABILITIES response and only report the existence of specific tokens (which may include capabilities not yet supported by the client) back as telemetry.
There's a gradient of scuminess going on there, all to (purportedly) track the same information. What matters for privacy concerns is the choice of data being tracked; how it's actually collected and transmitted is comparatively unimportant. So what you really want is someone to approve the choice of what to track, which isn't what a third-party library or service is likely to give you. And you don't need to necessarily route it through a third party; if we're talking about open-source software, the data that's being tracked is public knowledge--an organization that reviews telemetry and gives a stamp of approval would be sufficient to achieve the same ends.
But even then, I suspect many people are going to have different ideas as to what data is safe to track. Even the list I gave for tracking IMAP, I fully expect that there exists sharp disagreement about whether some of those entries would be okay for telemetry purposes.
Given the characteristics of data collection and deanonymisation, "safe" isn't a label which can be applied broadly to a product.
"Security is a process, not a product" applies equally to privacy, itself a domain of security.
"Security is a process, not a product" applies equally to privacy, itself a domain of security.
Having the choice to send and having transparency to see what is sent would be a great choice.
Sometimes projects take their cue from enterprise.
Hypothetically, if Microsoft can’t count how many SharePoint installations they have active and on what version, telemetry could help them plan a roadmap. Only that inch is often taken and stretched into a mile.
Sometimes projects take their cue from enterprise.
Hypothetically, if Microsoft can’t count how many SharePoint installations they have active and on what version, telemetry could help them plan a roadmap. Only that inch is often taken and stretched into a mile.
[deleted]
What's wrong with the feedback they get through traditional channels, though? There's already a GitHub issues page and the forums. There's no need to exfiltrate user data to figure out something they're already telling you.
They're looking for things like "how much usage does X thing get?", and this is hard to get from users for various reasons. You need lots of fine-grained feedback like menu clicks and things like that, you can't discover whether a button is easily discoverable from GitHub issues.
"how much usage does a feature have" is a wrong question. It is unqualified.
In an audio program one often uses a set of filter by default, which aren't that important.
Important is the filter I use once in a while and in that specific situation is making a huge difference.
Unqualified usage counters lead t wrong conclusions.
In an audio program one often uses a set of filter by default, which aren't that important.
Important is the filter I use once in a while and in that specific situation is making a huge difference.
Unqualified usage counters lead t wrong conclusions.
One way to do this is to make it a part of a beta program rather than baked into the main app. That makes it slightly more manageable for the developers too.
That's true, but I don't know how many would bother installing the beta, especially given that most distributions use stable. This would be the same as opt-in telemetry.
Windows Insider already had over 10 million users 4 years ago[0]. I'd say that approach works well enough. I myself used it on Windows Phone 8, because some upcoming updates came with cool features and being in the Insider program gave me earlier access.
I also used Firefox Nightly for a while because of the massive performance improvements at that time. As Audacity claims they're doing it for UX improvements, it would be easy to get frequent Audacity users interested in a beta build featuring tracking but also all the improvements being tested.
[0] https://www.networkworld.com/article/3185461/windows-insider...
I also used Firefox Nightly for a while because of the massive performance improvements at that time. As Audacity claims they're doing it for UX improvements, it would be easy to get frequent Audacity users interested in a beta build featuring tracking but also all the improvements being tested.
[0] https://www.networkworld.com/article/3185461/windows-insider...
I wish Musescore did this...
Github is in no way something that can be (or rather: is) used by anyone outside the tech bubble. Audacity however very much is. It is used by a lot of people that will never write a line of code and don't care (and shouldn't have to) about what github even is.
As someone who has done a little support work: The problem is that those channels require users to describe the problem to you. Many users are surprisingly bad at doing this.
It is possible to create opt-in, on-demand reporting tools.
Someone I know well created one such, based on a common reporting template of a major Free Software project, after realising that the template itself was based on information readily obtained from the system. Fleshing that out a bit resulted in an automatic syste self-documentation tool. They'd introduced it to the support group at one former company, and informal feedback several years later was that this was the principle diagnostic utility for the team. There was no ongoing telemetry, merely a "here's the script, run it and send us the output". (If necessary, the output could have been automatically emailed or transmitted by other means.)
There are now several of these, the "About This Mac" utility on OSX, as well as several for Linux, of which I'm aware.
No, they're not app-specific diagnostics, but precisely the same principles apply.
Someone I know well created one such, based on a common reporting template of a major Free Software project, after realising that the template itself was based on information readily obtained from the system. Fleshing that out a bit resulted in an automatic syste self-documentation tool. They'd introduced it to the support group at one former company, and informal feedback several years later was that this was the principle diagnostic utility for the team. There was no ongoing telemetry, merely a "here's the script, run it and send us the output". (If necessary, the output could have been automatically emailed or transmitted by other means.)
There are now several of these, the "About This Mac" utility on OSX, as well as several for Linux, of which I'm aware.
No, they're not app-specific diagnostics, but precisely the same principles apply.
Expecting end users to give you good useful data on how to fix an issue via a github issue or forum doesn't work at any meaningful scale.
Except it does, and has, for decades. Or how did Audacity get good enough to be usable, and bought. Random chance?
I would argue in OSS it doesn't work well, just because volunteers are going through and triaging most of the worthless reports (if you're lucky!) out it's still boiling the ocean, it's hard to put "this sucks and fuck you" on a backlog.
You can't really compare unstructured feedback in a forum / issue tracker to getting detailed Sentry data tagged with a version number and other metadata. Seeing quick spikes of issues of a new version at a glance is valuable data to have.
And having my IP address is going to help them how exactly?
Who needs (or asked for) your IP address?
The new Audacity owners are claiming they will only "hash" user IPs and throw away the salt after 24 hours.
So clearly they think they need them for some reason.
So clearly they think they need them for some reason.
You're conflating bug reports and error reporting, with telemetry and network access. Or even having network code in the app.
Look at how android can ask, and many OSS apps can ask, to send reports via approved side channels, like email.
Or how people can report wishes for apps to issue trackers.
Telemetry is more about usage patterns, and many don't want that.
Also, for decades devs have designed perfectly usable software, without telemetry.
It's just not even remotely required. Wanted maybe, but not required. And the whole bug reporting/user usage patterns thing is a red herring.
For example, how is it possible that Audacity even exists, got stable, and used enough to be bought, without telemetry, if it is so vital??
Look at how android can ask, and many OSS apps can ask, to send reports via approved side channels, like email.
Or how people can report wishes for apps to issue trackers.
Telemetry is more about usage patterns, and many don't want that.
Also, for decades devs have designed perfectly usable software, without telemetry.
It's just not even remotely required. Wanted maybe, but not required. And the whole bug reporting/user usage patterns thing is a red herring.
For example, how is it possible that Audacity even exists, got stable, and used enough to be bought, without telemetry, if it is so vital??
You're conflating bug reports and error reporting with telemetry and network access. You can't send telemetry via email or issue trackers, that's for bug reports.
> For example, how is it possible that Audacity even exists, got stable, and used enough to be bought, without telemetry, if it is so vital??
The obvious answer to this is "nobody said Audacity isn't good, this is about getting better".
> For example, how is it possible that Audacity even exists, got stable, and used enough to be bought, without telemetry, if it is so vital??
The obvious answer to this is "nobody said Audacity isn't good, this is about getting better".
This is an extremely unfair headline. The amount of data Audacity collects (or could possibly sell) does not compare to ANY closed source app on your phone. It's nothing compared to the amount of cookies the BBC website does not allow you to opt out of.
I totally agree that we should hold software to a high standard, and am upset that this is happening to Audacity, but this article implies that Audacity is somehow dodgier than TikTok, FB, Twitter, Google, etc. It's completely irresponsible.
I totally agree that we should hold software to a high standard, and am upset that this is happening to Audacity, but this article implies that Audacity is somehow dodgier than TikTok, FB, Twitter, Google, etc. It's completely irresponsible.
The BBC built the most cartoonishly evil spyware ever invented: roaming surveillance vans conducting van Eck phreaking on their users' houses.
https://en.wikipedia.org/wiki/TV_detector_van#Detection_tech...
https://en.wikipedia.org/wiki/TV_detector_van#Detection_tech...
[deleted]
Thank you for that link! It's interesting they're still claiming to be using something like this, in the digital era.
There is a meta-issue at play, as there is with many of these recurring stories that generate a lot of boring-to-read conversation. That is, "when is it acceptable to overreact to something?". Activism is based on the premise that it's acceptable when the cause is somehow good enough: one overreacts because most other people seem to be underreacting. This creates boring-to-read comment threads because (in the best case) half of the people are intentionally acting a bit unreasonably, and the other half are saying, "well, aren't you being a bit unreasonable?".
I'm not sure this is overreaction.
Don't get me wrong, I've grabbed my pitchfork at times in the past and some of them have been massive overreactions but I think this is people saying "Oh ffs! Is nothing sacred?"
Audacity is now joining the ranks (yes, the scale is much different) of Google, Microsoft, <Insert Evil Corp Here>. Whether their intentions are evil or not (I don't believe they are in this case) is irrelevant.
For me, it's another nail in the coffin of owning my own stuff and not having to be connected all the time.
For example, why do I want to use an offline application that can potentially send information about me to foreign countries? What possible benefit is there for me in that?
Of course, I'd imagine that telemetry won't break my app if I don't connect to the internet but it's all part of a pattern of software becoming more and more about what the owners of the application can do to monetise me and what they can get away with (whether that's the plan for Audacity or not... they're still playing in the same field and can easily take a stand and say "we will never use telemetry").
Even if it's made to be opt-out, what happens if an update accidentally (or deliberately) switches it on again? Will it be "oops, sorry about that"!
Don't get me wrong, I've grabbed my pitchfork at times in the past and some of them have been massive overreactions but I think this is people saying "Oh ffs! Is nothing sacred?"
Audacity is now joining the ranks (yes, the scale is much different) of Google, Microsoft, <Insert Evil Corp Here>. Whether their intentions are evil or not (I don't believe they are in this case) is irrelevant.
For me, it's another nail in the coffin of owning my own stuff and not having to be connected all the time.
For example, why do I want to use an offline application that can potentially send information about me to foreign countries? What possible benefit is there for me in that?
Of course, I'd imagine that telemetry won't break my app if I don't connect to the internet but it's all part of a pattern of software becoming more and more about what the owners of the application can do to monetise me and what they can get away with (whether that's the plan for Audacity or not... they're still playing in the same field and can easily take a stand and say "we will never use telemetry").
Even if it's made to be opt-out, what happens if an update accidentally (or deliberately) switches it on again? Will it be "oops, sorry about that"!
What if I told you that it is, in fact, opt-out and explicitly made easy to disable in the build config? Don't you think it is a bit of an overreaction to say that "Audacity is now joining the ranks [...] of Google, Microsoft, <Insert Evil Corp Here>" when you haven't actually looked at the source of the issue?
https://github.com/audacity/audacity/pull/835
https://github.com/audacity/audacity/pull/835
> Don't you think it is a bit of an overreaction to say that "Audacity is now joining the ranks
No. I do not.
They now have the ability to take any data they want "accidentally". They can now give that data to whomever they want (it's in their Ts and Cs I believe) and even if you switch it off, what's to say they won't turn it on? What's stopping them selling the product to another company that now has a bunch of data.
It has not been needed up to this point. The product works. It works well. Why can't they send surveys? Or ask in a forum? Or ask users to download their alpha/beta/nightly version with the telemetry in it?
Once they get that data, they may want more!
No. I do not.
They now have the ability to take any data they want "accidentally". They can now give that data to whomever they want (it's in their Ts and Cs I believe) and even if you switch it off, what's to say they won't turn it on? What's stopping them selling the product to another company that now has a bunch of data.
It has not been needed up to this point. The product works. It works well. Why can't they send surveys? Or ask in a forum? Or ask users to download their alpha/beta/nightly version with the telemetry in it?
Once they get that data, they may want more!
If you read their responses and messages then they tell you exactly why they are interested in certain data and how they decided to respond to the outrage -- the _Audacity developer's responses_, not random people who are misinformed.
"Overreact" may be too loaded of a term to have used - I was trying to get at the idea of purposefully acting more strongly than one's usual default (which, for shear lack of time and energy if nothing else, is to remain silent on most things which are wrong with the world).
I am dumbfounded why people who don't contribute anything to Audacity but merely use it act as if they have governance over the project. Maybe build your own?
I am tired of this mob/herd justice mentality.
ha!, you ought to go see what the 4chan mob is doing to the guy that decided to fork this project to undo those changes!
[deleted]
Sorry, too late. The WOKE has condemned it already.
At present, "personal data" in their privacy policy means 'IP address' as the GDPR calls it such. The under 13 line is due to COPPA in the US which states that it is illegal to collect personal data about someone under 13 without the verifiable consent of the parent/guardian.
Isn't that a telling sign that this data collection has no place in an open source app? With that said, how does Firefox or Chrome get around this rule?
I didn't express an opinion on that. I simply posited why the privacy policy is likely written as such.
That's fine
We can't both want OSS to improve and resist giving feedback. I think the possible UX improvements are worth giving them some data, as long as the scope remains limited (which it should, since it's OSS and we can see what gets sent).