Audacity fork without any sentry telemetry or crash reporting
github.com
github.com
1. error reporting - the user has to click a button to share crash logs. It's basically a macro to help the user create a support ticket.
2. version checking - no PII information being kept, literally just helping the developer get an idea of what versions they need to be supporting--you do want them to support the version you're running, right? Well, if not, you can turn it off.
What's the big deal?
It's not clear what sort of thing you're referring to, it's generally not possible to make a service where you have accounts and billing, that simultaneously doesn't store your information. The whole point of it is that you want it to store your information.
Yes, they probably also know that I usually connect from an IP address in Chicago. And, while storing that information isn't strictly necessary, I'm also more-or-less 100% confident in saying that anyone who might want to keep tabs on me already knows I live in Chicago, and that would have been true 30 years ago, too. (Well, 30 years ago it was another town, but still.)
I suppose a lot of this is maybe just a halo effect due to all the (quite legitimate) upset about surveillance capitalism? Which is fair. And perhaps we want to say that it's easier to try and shut down all telemetry than it is to distinguish legitimate telemetry from abusive telemetry. Lord knows, if we try to carve out any concept of legitimate telemetry, adtech companies will immediately go about probing it for loopholes.
Also, GitHub is Microsoft and LinkedIn.
Count me on Team Crash Report, for sure. Anyone who's worked on any kind of project like this knows how valuable live user telemetry is. These features make software better for all of us. If you really don't like them don't use them and carefully audit the opt-out mechanism to make sure it works. Don't throw poop on the walls.
Unless you do not collect said information in the first place.
Try to live in a society where everyone, including your closest family members, might collect such information.
Compromising a telemetry server is a one-off operation, would work at scale and is much less risky as the targets have no way to detect it.
Also, since you can fork it, as has been previously mentioned, there seems to be no purpose in objecting to this type of FOSS acquisition. Worst case, the project ends as it was before the acquisition, with no corporate support or funding whatsoever, at which point it seems it won't make any difference whether there was a complaint or not.
Leaving the data collection on all the time, makes data-collection part of the terms of use of the software. Which makes data-collection part of the business model. Which makes the software spyware. It is always watching you.
If I followed you around all day, you’d label me a stalker, If I didn’t approach you, didn’t proactively threaten you, didn’t tell anyone else what I knew about you, you could still legally bring sone level of force against me. How is constant telemetry any different?
For some reason free (gratis) software attracts the most entitled users ever. If I were in charge of Audacity I'd be inclined to charge a $1 "distribution fee" just to weed these users out.
I think rather it is rather an example of an external company (Muse group) not understanding the community behind the piece of software they have taken over.
They could do the data collection themselves and chose not to store personal identifiable information, in which case they can remove the legal boilerplate since it won't be needed. This suggestion naturally already exist in the GitHub issue.
This - audacity - is supposed to be a bloody offline desktop app.
No connection to ANY online service, including telemetry.
That is what I meant.
Do you have any examples for OSS? Because i do not believe that to be true.
> When do we share your information with others? ...When the law requires it. We follow the law whenever we receive requests about you from a government or related to a lawsuit.
Software should not collect information in the first place if it may get necessary for law enforcement, litigation and authorities to demand it. If the information is interesting for a third-party then the collection filter is not fine grained.
Live user telemetry does not have to mean Personal Data. If I know that 80% of users who download version 1.2.3 got a crash within 5 minutes, which living person can I identify with it? If I however get download logs of IP addresses, browser identity tags, file names, windows profile names, user directory names (and so on), then that cash report is providing unnecessary personal data.
If I have access to the crash reports, can I do business intelligence gathering? Can I discover information which gives stock market insights? If the answer is yes, then you are collecting too much information.
The only reason to not publish all crash reports openly on the web for anyone to download should be undiscovered security vulnerabilities. The data itself should be inert.
However, Audacity is cool and all, but I wonder if it would be better to create a simplified frontend based on Ardour, the way GarageBand is for Logic.
The telemetry has always been opt-in (though they didn't communicate that very well) and their privacy policy is just standard stuff.
Again I haven't followed it. Honestly it looks a bit to me like the playbook you see when a project is sold to a private equity firm.
Even if we assume there is no malicious intent from either the developer nor their infrastructure provider (their initial telemetry attempt was using Google Analytics which is definitely malicious), it can still be coopted by a malicious actor who is able to observe the network traffic or compromise the telemetry infrastructure and put the users at risk.
What's wrong with Windows 10? I think it's great
What's wrong with Google Analytics? As long as the ad retargeting bits aren't enabled ( they aren't by default), it's just a regular anonymous analytics solution.
This assumes you trust Google? Why would you trust an entity that's both got a business incentive to stalk people, is able to hide it (given how many factors go into ad targeting it's impossible to reliable prove from the outside which data was used to target an ad) and is big enough to successfully fob off regulators and get away with it (their current data processing consent flow violates the GDPR for example)?
The latter though? Somehow the industry got by for decades without intimately knowing what version every single user of the software was running. I think they'll survive without it.
Anyways, how is it "petty" to make a version of the software for which there is clear demand? No one stomped on their birthday cake, they just took an OSS piece of software and modified it, compiled it, and released it. In what world is there any malice in doing the exact thing an open source license exists to allow you to do?
Luckily if this bothers you then OSS works as intended, everyone can be happy.
I can see why the developer wants it, but a person wanting something is not inherent evidence of it being "good". I want lots of things that are bad for me, and even some things that are bad for other people.
Here's the thing: In order to track version numbers, this developer now subjects its users to potential police surveillance. Even if that surveillance is "harmless" on its own, they have still made that bargain. And I feel like we're well past the point of credibly taking any given individual act of surveillance as being isolated and unentwined with more problematic kinds.
Is that bargain really worth it?
I don’t think it’s clear that there is any demand for a version that doesn’t collect crash reports or version usage. The outrage was about the vagus clause about information necessary for law enforcement or similar.
I’m perfectly happy to see that code (if it exists) being thrown out, but to remove user confirmed crash reporting?
I’d expect every app I use, OSS or not, to have automated crash reporting (a confirmation dialog is a nice touch) and version usage tracking. It’s possible to maintain software without it, just like it’s possible to maintain software without other feedback like a bug reporting system or a profiler.
If it weren't collecting version info what possible reason could it have to have a clause in the EULA about giving info to the police? You have to be phoning home for that to even mean anything.
This is the same argument that was used about seatbelts and the internet. You might have survived without it before, but that doesn't mean it isn't going to be better with it in the future.
So far no one in the many replies to my post have given even a single reason why the world is substantially better with data collection on versions. The argument is either this kind of attempt to substitute an Obvious Good Thing and then not explain how this thing is like that, or that "it's just a harmless bit of data collection, as a treat."
I think data collection should probably be held to a higher standard than that. Come up with why it makes my life better first, then pitch me on it. Otherwise you're just pissing in cornflakes and calling it breakfast.
I don't think the scale nor the features of modern software is comparable to what we used to have.
Back in the days you didn't have such a diverse numbers of versions/machines combinations, software were much simpler, much less updates, &c.
We also survived just fine without cars, electricity, central heating, processed meat, &c. this isn't a valid argument
I guess this changed long before Audacity. Today many programs, including open source tools, bundle some sort of telemetry.
I think that instead of opposing Audacity we should talk about other projects in similar situation; we should treat them the same and think about a more general solution. There are already discussions like this, e.g.: https://consoledonottrack.com .
Claw back the privacy on high-profile applications, get an amount of attention that’s significant enough to either lead the application to change or for the other fork to become the go-to. This reminds other companies that people do care and that the cost of tracking is in taking privacy from users who then leave when they can.
If the maintainer had waited out the initial flurry of attention, they probably could have chosen the name they wanted without much drama at all. Instead, they overreacted, deleted the first thread, and then immediately started editing and deleting user comments in the second. Ouch.
That's not what I expect from a software that require no remote server to function.
2. No, off by default or ask on first boot.
3. What data are they collecting that would be shareable to law enforcement? The feds need to know I’m on an outdated version?
I will not use or recommend Audacity anymore. It’s a shame, I really like Audacity and I’ve been using it since high school.
Their new changes restricted use by individuals under 13. This is probably because they could run into trouble with GDPR with the personal data they are storing on users, which they have no good reason to store except that they can.
Audacity is used in public schools. Forking to keep the project usable by children learning the craft is not petty, it’s a worthwhile thing to do.
Ruining community trust so you can unnecessarily collect private information on your users, that is petty.
While I do understand the underlying cause and indeed hate things that violate my privacy as much as the next nerd.. you guys know most software phones home for update checks right?
Hell I'll tell you what. Unplug your router from the WAN side and wait a minute. See that popup there on all of your devices telling you you're offline? There's a connectivity check that's been giving out the exact same information the entire time you've had your OS installed
I really do appreciate the vigilance and don't want to discourage the raw energy on display at all but this one might not be the cause to go all in on
On the other side of my own argument it definitely won't hurt to chuck them a GDPR request in a month or two to see what they are gathering :)
I thought it was pretty obvious but yea you got me. Good point, well made.
Muse group, a russian for-profit company that seems to have a shell-headquarters in Cyprus (see https://www.crunchbase.com/organization/muse-group), recently acquired Audacity as part of their expansion into the broader audio-production world.
As a first action, they changed their contributor License Agreement making a future change from a GPL license to a closed-source License possible. (it also allows for dual-licensing a paid version) https://github.com/audacity/audacity/discussions/932
They currently say they're not going to do that, but if they wanted to (and Muse-group is for-profit) they could without the contributor having any recourse. (They have already confirmed a cloud-service for Audacity, which for me already reeks like "we want to have closed-source tools that use our open-source contributors code").
Having a CLA isn't a problem in and off itself, for example, as they correctly state: the FSF requires a CLA because they want to license all their stuff as "GPL 3 or above", which is only possible using some CLA-mechanism. (it's also easier for them to defend GPL related lawsuits if they are the copyright holders)
What MuseGroup forgets to mention, is that they are a for-profit company (https://opencorporates.com/companies/cy/HE411908) while the FSF is a foundation (specifically a 501(c)(3) non-profit organization), which shifts their incentives a lot.
Now, barely a month later, they add the option of collecting data from users and people aren't happy. It is, at the very least, very tone-deaf/stupid from them to add telemetrie only one month after (IMO) showing their hand for what we can expect for the future.
That said, I personally think this fork is a clumsy attempt thus far. If there truly is a rift so wide as the parent comment claims, it probably calls for a total rebrand. The way it's currently positioned makes it look like the author is simply attempting to apply pressure to get Muse to change its behavior, but based on this context I doubt that's going to be a viable long-term strategy.
It would be a big boost to free software if some org like Freedesktop had a standard telemetry library, data collection policy, data collection and publication service, and a distro-wide master switch to opt into data collection, and it was socially acceptable to use that framework.
No, we do not need a "standard telemetry library". A standard crash reporter might be OK. It should ask the user if you want to submit a crash report, and give you a ticket number which allows you to visit a web site and see what's been done about it.
Also it matters how much people use rr. If a lot of people download it, use it once and never use it again that's important information (especially if you also report when it worked and when it didn't work).
Mozilla does it . Nobody is forking Firefox over just that, I don't think everyone is against it.
If it opt out and part of the install process and uses know what kind of data will be used it should be fine.
Audacity seems a exception here. They are broadly following this kind of rules , however there is blowback which other projects don't seem to be getting. Perhaps there are underlying issues in the community ?
It's a perfect storm of mistrust and crisis mismanagement. And the sad thing is that there are talented folks like Tantacrul, Head of Design at Muse Group, who could really benefit the community with opt-in telemetry guiding their product decisions, who have now been thrust into a crisis management role by this botched rollout, and are unprepared to give the transparency now required. Did nobody else at the company learn from WhatsApp's debacle on this?
It's especially sad because while few would shed a tear for WhatsApp's missteps, Muse Group's holdings in MuseScore and Audacity are literally the lifeblood of hobbyist and student music creators. Mistrust in that software can easily lead to "you know what, I heard bad things about Muse stuff, I won't pick it up" and that would rob the world of so, so much creativity. Muse Group, rein in your lawyers, swallow your pride, and act like the stewards of the future of music that you are.
At this point, however, the age restriction should have given it away. If it's not allowed for children, it's because of COPPA. And if you're trying to avoid COPPA, you're doing something nefarious. The employee should know that by now.
WhatsApp probably a not right comparison ? It is not like there was ever going to be opt out in WhatsApp even, and Facebook's reputation and history of abuses is at different league than pretty much anyone else.
Mozilla is a non-profit whose mission is promoting end-user control on the Internet, and they have a long track record. People trust Mozilla.
The owners of Audacity haven't earned that trust.
[roca corrects the ordering, but there is still a for profit in there]
Of course, people can still pay themselves fat checks, but that's possible at a regular non-profit too.
Any nonvolatile bit is a public bit. It's only a matter of time.
I mean, you kind of do -- to the extent that the data is used to prioritize fixing features you use, you benefit from being part of the survey sample.
Audacity is an end application and really isn't likely to accidentally send something sensitive short of packing up entire audio files (which would be stupidly obvious if it were being done).
The best I can think of is to incentivize it other ways; e.g., telemetry only for bug reporting, or a "you ping us, we give you a nice hat" or something.
This personalized request always felt so warm and casual to me, and I appreciated the thought that Harald Alvestrand cared to know that I, personally, was using Linux.
My suggestion would be to give a reason, however small, to send that email. For example, "Would you like to vote on which of these four issues from our roadmap you would like us to prioritize?" (best asked after a bit of usage, rather than on first installation).
Edit: How about routing it via something people trust, such as a trusted proxy like Mozilla (if they would host such a thing) and over the Tor network (if that could be bundled easily).
1. Collect the telemetry to a local file. The file must not be encrypted, be human-readable and contain only anonymized data. I should also be able to confirm all this by just reading the file.
2. Bug the user every time rr finishes or something like that. Ask them to send the telemetry by running a curl command that you will print out right there.
3. Have a sensible log collection policy on the telemetry servers and explain that too.
Oooh, we're redescovering nagware (https://en.wikipedia.org/wiki/Shareware#Nagware ), but now for privacy instead of money!
How would you know that? It seems quite plausible that there are statistically significant differences between the subset of users who enable it and everyone else.
- Communicate clearly and discuss openly before writing code, asking for feedback from the community.
- Make very clear from the beginning that this is opt-in (Audacity failed this, IMO)
- Give specific examples of the actual benefits of telemetry in concrete terms (e.g. "leverage with hardware vendors"), not just "make $product better".
- avoid dark patterns (the screenshot Audacity has added now to the pull request has a highlighted "yes" button - that already will make some people hate you, anything worse than that will rightfully make most privacy conscious people hate you)
- Avoid controversial third party providers (this likely amplified the outrage in the Audacity case a lot)
- If you screw up and/or get unlucky and a shitstorm starts, back down. Even if Audacity actually fixes the issues to a point where everyone would consider it reasonable had it been like that from the start, trust has been lost to the point where any telemetry feature will be controversial.
Audacity screwed up in multiple ways:
- poor communication in general
- Still doesn't intend to make the data collection opt-in. (The update check sends OS and version information, and that part is supposed to be opt-out.) The privacy policy also makes clear that it wasn't supposed to be opt-in (uses legitimate interest instead of consent, tells people who are under 13 to not use the app).
- introduced this shortly after other controversial changes (change of ownership, CLA requirement)
- collecting data "For legal enforcement"
- "If you are under 13 years old, please do not use the App." (following from COPPA limitations - it should be "please disable analytics" instead)
- used controversial third party providers
(Pretty much 100% predictable by now: the issue is hot, and complaining is easy—so it will be done.)
1. Users enjoy product for free.
2. Users pretty much never tell maintainers what is going wrong for them: no messages (much less proper bug reports), no contributions in any way!
3. Something invariably goes wrong for users that do the above.
4. Users immediately hit social media and try to tar the entire project, developer/company reputation, whatever. “Zero stars”, doesn’t work in their use case. You have surely seen these “reviews” before, and mindless tweets.
THIS is why I am torn on telemetry to some degree. IF you demand no auto-feedback in the name of privacy, THEN you should help out voluntarily OR not use free software! Yet software maintainers can’t count on this at all. They risk being hanged in the public square for every bug.
Now we can send all of the privacy seeking developers over to the new project where they can demonstrate their productivity.
I see this fork as a wonderful thing as the Audacity people can finally kick the excessively whiny to the curb--I mean the new forked project.
You got this part wrong. Users contribute to the project and/or draw contributers to the project. This happens to proprietary projects like twitter as well, where key features were invented by users. https://qz.com/135149/the-first-ever-hashtag-reply-and-retwe...
If users 'tar' a product, it likely deserves it.
Does something have to go wrong and do maintainers have to know about it?
I mean, if users are using the software, even if it's not perfect, what's the big deal - is that not good enough?
> IF you demand no auto-feedback in the name of privacy, THEN you should help out voluntarily OR not use free software!
The point of free software is that I can use and modify it as I want. I do not "owe" feedback (or anything else for that matter) to the developer.
As I see it, your options are:
- Decide the software is not for you, for some reason, and silently uninstall it, or...
- Try to make the software better, working with the maintainer somehow (tell them what is wrong, contribute a fix or a bug report, etc.). People would be surprised how sometimes a fix is really simple but the use case may be really obscure, and it is literally just a matter of finding out that the problem exists.
My problem is that people seem to employ a “3rd option” of just deciding all by themselves that software must be poorly implemented and trash, and worthy of public scorn, because they can. If developers go long enough without any real feedback, while enduring negative “press”, you’d better believe they will at least consider something like a telemetry tracker to tell them what the heck is going on. At least that way, they can find these problems and actually fix them, to preserve their reputation.
The way the free software community treats its own is reminiscent of progressives in America: constantly eating your own kind while letting your opponents flourish.
There’s a reasonable amount of telemetry, and without it the free, OSS side can’t compete with closed source products on a level playing field.
I’ll even go further and suggest that light telemetry should be on (and able to be disabled) by default.
https://github.com/microsoft/calculator
An application universally ridiculed for it's inclusion of in-depth telemetry. It's time to challenge your preconceptions: find the roadmap items, features or bugs informed by the gathering of the telemetry data.
Here is what's really happening:
* Migrating the codebase to C#
* Iterating upon the existing app design based on the latest guidelines for Fluent Design and WinUI
That last one is probably going to be obsolete by the time they are finished. What's the value here that telemetry is delivering?
This is the story all over the industry. Fancy dashboards everywhere, but the people shaping products haven't made an evidence-based decision in years.
Audacity: Clarification of Privacy Policy - https://news.ycombinator.com/item?id=27739596 - July 2021 (80 comments)
Audacity 3.0 called spyware over data collection changes by new owner - https://news.ycombinator.com/item?id=27736151 - July 2021 (70 comments)
Audacity may collect “Data necessary for law enforcement, litigation” and more - https://news.ycombinator.com/item?id=27727150 - July 2021 (254 comments)
New [July 2, 2021] Audacity Data Collection Policy - https://news.ycombinator.com/item?id=27724389 - July 2021 (34 comments)
If there isn't a leading suggestion for the new name yet, I offer "Temerity". It's a close synonym for "Audacity", and highlights both the boldness of this new project, and the recklessness of Muse Group's changes. It also cleverly alludes to (avoiding) "Telemetry", which is a distinguishing feature of the fork.
Is Sneedacity somehow a dogger whistle?
"Sneed's Feed & Seed (formerly Chuck's)"
Edit: non-dead link https://github.com/temporary-audacity/audacity/issues/33
Many of the people on /g/ are regular programmers. You may be underestimating how much overlap there is between readers of this website and /g/. Remember that there is more to 4chan than just /b/ or /pol/.
He then claimed that he was called 70 times and was sent 3000 mails as harassment but never showed any proof and deleted some of his tweets regarding it. Interestingly the 4chan threads he posted on his twitter as proof of the alleged harassment didn't contain any personal information or people requesting his personal information. He was even caught lying about the phone calls in the comments here which lead to him deleting his posts, https://postimg.cc/BPXX26W1 https://web.archive.org/web/20210706000825/https://twitter.c... . I don't know about you but refusing to provide proof, changing the story when asked and deleting posts when it gets noticed looks suspiciously like pretending to be a victim.
He's putting some vile stuff on his github bio currently(changes often) so I don't know what's going on. It's a shame the needless drama this guy caused with his inability to manage a project is getting more attention than the current situation with audacity.
Branding any of this as telemetry then creating a bunch of immediately abandoned forks is a joke.
Before you say “well make this opt-in” - that doesn’t work for crash reporting nor does it really work for auto-updating.
Things change. The internet needs Javascript, distributing desktop apps using electron makes a lot of sense and developers need automated feedback. Please stop.
This part is not inherently true. Only time will tell how Audacity reacts, and they could very well have an UnGoogled-Chromium/Codium situation on their hands.
My point is that a fork can be abandoned by users even if the project is still active.
Edit: to be clear, other software is often used instead of audacity. It isn't as well known as say photoshop, or maybe even inkscape.
https://public-001.gitsense.com/insights/github/repos?p=comm...
The user crsib appears to be the main contributor to audacity, so I would have to imagine others would have to pick up the slack for a fork to be viable.
cookiengineer also changed 71 files
https://public-001.gitsense.com/insights/github/repos?p=comm...
so he/she will have to constantly monitor these files moving forward, for the fork to be stable/similar to audacity/audacity, which I am not sure if he/she/others are interested in doing this for the long term, but I guess time will tell.
Full disclosure: I'm the creator of the tool that I linked to
Similarly, crash reporting being opt-in works very well. On crash you present the user with a crash report, they review it - and can send if they desire to. Throw in a lil’ “don’t ask again” checkbox and you’re good to go.
I don’t see anyone forking that in outrage.
It's like this because it is an overwhelming benefit to someone who is selling something. Not because it is necessarily overwhelmingly what people want.
Some other market outcomes I'm unhappy with: ad tracking, excessive plastic packaging, cheap goods - expensive repairs, all sodas are at least twice as sweet as they need to be.
When there are options, I choose otherwise. If an option I've come to rely on changes to be something I don't prefer - i'll raise a stink.
Audacity doesn't need to phone home for that.
Very different
This is funny because usually whenever i see that mentioned to excuse negative behavior it isn't really about the market speaking but about the market staying silent :-P
The project lead said he had no say about the telemetry and couldn't turn it down. For me, that makes is a business decision and not a technical one. This is to monetize, not to help me.
It’s crash reporting and update checking. Stop getting so outraged over such minor things.
More people think open source means “I can be VP of product without showing up to work” than “I can roll up my sleeves and help make the hard thing I want happen”.
- system instability - just plain data deletion and/or loss - features not working at all, or quarter-baked - previous free feature moved to premium or behind the paywall - incompatibility with previous files - just plain resetting my previous settings and customizations to defaults - arriving with the wrong language (based on keyboard layout or location vs my OS-chosen one) - somebody was frelling bored, so decided to move the position or change a keystroke of the function in the menus - just "because" or "it boosts engagement" or some similar crappy excuse - plain spyware/malware delivered as an "update" (with app betwixt updates being sold to spammers/scammers) - app/program sold in the mean time, with the new one preferring to siphon all the telemetry possible (all options conveniently on by default) - messing up my file or action associations
...and probably 12 other things that don't cross my mind at the moment.
I will bloody update my hardware and my installed (or portable-d) software whenever the frell I please. I cannot stand the mommy-gloves and mommy-stance I am subjected to
I do not have will nor time to battle with that. My largest "attack surface" in any/all meanings of the word comes from auto-updatijg. So, off with your hea-- auto-updates.
I've been blocking/filtering all auto-updates and all Internet access to all apps/programs/OSes where ever possible. Whenever possible, I use portable versions that don't require installation, and I have a huge software library; letting things run amok is not an option.
I've been doing it for a decade now (in different, but ever enlarging scope), and I've never been happier. Nothing breaks. Things work. AS THEY SHOULD. And nobody forcefeeds me the crap 95% of the "common folk" are subjected to.
Yes, this is a rant. And the topic is a sore one. I'm just so, so, so bloody sick of it.
I thought it self-evident in my post that I expect the software in question to notify me of a new version, provide the cumulative change log, and offer me an update (plus even an auto-update, but only as an option).
Software that did that (let's call it "polite" software), got its net access (for limited aforementioned uses). And if it was a piece of software I particularly found useful and non-clashing with my stances, I sometimes even enabled the telemetry (because it might help improve it).
What I cannot stand is being forcefed those. They break everything when I least expect it, and when I most need the things to function and function fast (e.g. auto-update on program start VS offered update on close). Most (90? 95%?) of my catalog is specific (and offline) use only, so eventual issues usually do not affect me.
Often used software I update on a more regular schedule, but still - almost exclusively manually (by downloading the new portable version). OS is updated once I'm done with a project or whatever I was doing in that duration - meaning when I can temporally afford to be frelled in the posterior by Microsoft's updates, and spend an hour fixing stuff... such as figuring why the bloody gamepads are now suddenly preventing my monitors from going to stand-by, thus messing up my presence & tracking software, thus messing up my home automation recipes. (If you are impacted, it's the 2019-timestamped XBox driver; revert to something ancient [find it somewhere], and "lock it" down by listing device identifiers via group policy.)
To sum up, in simplified terms - any frell-up resulting from an auto-update impacts me 100% (and costs me time, nerves, will to live) VS extremely low percentage of being affected by the critical security vulnerability du jour (and especially taking into account security and precautions I practice).
Constantly-used and online-required software has its own, different set of "rules" (security, precautions, guidelines, etc.). Don't mistake my ire at a certain type of an unfortunately too common (mis)use of a feature (in my specific circumstances and use cases and scenarios) as an irrational blanket refusal of absolutely everything under that category.
(Note: typing on a phone, so due to editing troubles my chain of thought might be all over the place.)
However, what I do not stand for is auto-updates without my explicit knowledge and explicit consent, because it regularly messes up my... well, my "anything and everything". (Insert specific xkcd instance about breaking-workflow here.)
Therefore, due to personally-experienced and ever-widening common abuse of the mechanic (and ever-encroaching march on my privacy and rights on & from all fronts), I am less and less willing to even consider giving the pieces of software I actually enjoy the benefit of the doubt (aka useful telemetry).
Please notice - my original reply was (exclusively) addressing the specific portion of one of the preceeding user's comments "pushing" for the auto-update mechanism as mandatory (and not to the Audacity's issues/attempt/approach specifically). From my perspective, it seems that you and the previous commenter are addressing my replies as a full and all-encompassing description of the whole of my approach and practices (and I have specifically said that isn't the case in the comment above this one).
Additionally, there is an assuming of the non-use of any (or a combination, or all) of the myriad of the additional layers of protection available to any semi-advanced user [e.g. Tor, purpose-configured browser, proxy, VPN, etc.] while obtaining the software in the first place (and/or subsequent instances), and that the software in question could be "gotten" from alternative and directly unrelated locations if need be. If true, that assumption would be in error.
Those are my needs, not the software's. The software has no needs. And if I don't mind the bugs and aren't interested in "improvements," I'm not actually concerned with the software's feelings.
When I say this, I'm assuming I'm not talking about networking software, but if you had your way, every piece of software on my computer would be networking, and reporting my usage (however it opaquely defines that) to strangers. I don't want to have a lifelong relationship with the person who wrote the sudoku program I installed from my distro's repo. I really don't want to get owned five years from now because that person needed to "improve" it when I didn't ask.
Software needs not do any such thing. Developers may want this thing, but users absolutely do not need it, and neither does software.
You don't need to perpetually run the latest release to "stay relevant". All of my workstations are still on Catalina and they're fine.
This is a fundamental principle of human interaction -- ask first before touching someone's stuff.
Imagine if there is a buffer overflow in Audacity, meaning someone can take over your machine with a malformed sound file. I'd want to know about that ASAP -- not after a month.
On average, I believe most users benefit from an automated check for updates. It should be possible to disable it, but we should first worry about keeping users safe.
They should still ask first, at first run. I actually enable update checks for a lot of things, if I'm given the option up front. I'll submit crash reports and even periodic telemetry if I know that the crash reporting system doesn't download and run arbitrary code, shows me everything that will be submitted, and allows me to omit needlessly identifying details (e.g. custom kernel strings).
Some projects (KDE) make it really hard to submit crash reports, by requiring an account, etc. It must be optional, it must be easy, and it must be transparent. Then users will volunteer crash reports and stats. Respect breeds respect.
Nowhere in that paragraph was their any technical reason that someone concerned with both getting crash fixes but avoiding crash reporting themselves should be told they can't have them both.
Also, opt-in silent updates don't inconvenience anyone. The user gets whichever situation they are most comfortable with.
Opt-in crash logs and opt-in silent updates should both be logged for easy user perusal.
--
None of this inconveniences developers or users.
--
The problem with any centralization of non-opt-in unlogged data gathering is it creates completely unnecessary hazards and trust problems.
Once an organization is pulling data, that data is now available to (1) incentivize the organization to use it in ways the subjects many never have considered, (2) incentivize the company to increase the amount of data they pull for good or ill, (3) is potentially a target for security breaches, and (4) is a potential target for governments to coercively surveil users by accessing the data or encouraging more data to be pulled.
None of the problems in the last paragraph will be apparent to users until they have already suffered damage. So concern about non-opt-in unlogged data gathering is extremely prudent.
Audacity hasn't really changed in the last 5 years. It's still good.
I doubt I would miss anything I need if I somehow didn't update for a couple of years.
Even on consumer desktops these kinds of updates are simply not critical.
It doesn't seem so weird to me to have an application ask for permission first. Something most applications do anyway.
Nevertheless, it's good to know they've chosen an opt-in construction for Audacity!
Do you think the SQLite developers have ever felt like they need automated crash reporting from their users? (see https://corecursive.com/066-sqlite-with-richard-hipp/ , which got discussed recently: https://news.ycombinator.com/item?id=27718701 ) And SQLite accepts way richer input (SQL queries) from users than Audacity does (audio files).
There are many ways to reduce bugs. Extensive coverage-guided testing, like SQLite does, is one. Automated fuzzing is another. Writing in languages with strong type systems that let you statically verify the program's behavior is another. Collecting crash reports is another, and it's certainly one valid way, but it's not the only way.
It's pretty clear that Audacity's users, in aggregate, aren't that concerned about needing crashes fixed - or at least are less concerned about it than about their privacy. Maybe Audacity already is sufficiently bug-free for their needs!
While I also think that the "telemetry" argument is overblown, and I think automated updates are basically table stakes, and I wholeheartedly agree with you re JS and Electron, I think it's entirely reasonable for users to say that they don't find automated crash reporting valuable, and I don't think that it's particularly reasonable for developers to say "We know better than you."
Also, with SQLite, it seems the major people reporting bugs are people who have paid support contracts with drh, which most likely requires sending identifying information.
I don’t think the rest of the comment warrants much discussion, but I wanted to point that out.
You mean Fossil? We use it, it works great for us, doesn't get in the way, doesn't require constant rtfm. Also you could just clone the repo if you want to test. It exports to git.
If SQLite is low-quality software, but the manner in which it is low-quality does not involve crashes, then that does not contradict my claim. There are a lot of ways software can have bugs other than crashes: incorrect behavior, confusing defaults, missing features, inaccurate or nonexistent documentation, poor API design, etc. Automated crash reporting can't help with any of that. If you discovered that "SELECT * FROM users WHERE paid = 1" returns unpaid users too, that's a really bad bug, but no automated crash reporter could possibly tell the SQLite developers about it.
I do agree with you that users of software at scale don't report bugs and so you can't rely on them reporting bugs; I'm just pointing out that there's no reasonable way around it except for crashes, and there are other ways to address the specific use case of crashes.
There is an unreasonable way around it: add an analytics framework that tracks every click and mouse movement and keystroke your users do. There are web analytics libraries that do exactly this and let you replay your users' behavior. I hope we all agree that Audacity should not do that.
(By the way, if I go to https://sqlite.org , there's a "Support" link at the top that tells me to use their forum. You can then click on the forum link, click "New Thread," and click "Remain Anonymous," and there's apparently a way to post things. I guess this forum does actually use Fossil internally according to the message at the bottom, but it seems really straightforward to me, so I am surprised at your claim that this is confusing....)
I don't want any software on any of my machines to auto-update.
Auto-update is a remote code execution vulnerability, as Solarwinds demonstrated.
> Things change. The internet needs Javascript,
I browse the web with javascript off, on Edward Snowden's recommendation.
No, you stop. It absolutely does NOT need this functionality. Is it nice? sure. But it should be opt in and prompted, not opt out and automatic.
> that doesn’t work for crash reporting
It does.
> nor does it really work for auto-updating.
Good.
> The internet needs Javascript
No it doesn't. The ad economy depends on it to bypass consent. Do not confuse that with the ad economy requiring it to function nor does it mean the internet requires it. Again, is it useful? of course, there are many instances where it can (keyword can) enhance the experience, but it is not necessary for 99% of applications (no, your infinite scroll SPA is not a necessary function). Is it necessary? Absolutely not.
> and developers need automated feedback
No they dont.
The only things you're referring to are necessary for are forcing things by your users without their knowledge or consent, and for superfluous flair and form. It's possible to build opt-in, privacy respecting, informed consent software diagnostics and telemetry without forcing this nonsense on them, especially with respect to the topic at hand, which is not a web application, but an offline native desktop application.
The web and mobile world is plagued with prompts stating that "X needs to access your data Y" or "X needs permission Z" to "do the job".
Worst part of it? Developers and architects are often the first ones to believe this nonsense.
When you're surrounded by developers, users and managers who believe in werewolves, best thing to do is just to nod :)
> No it doesn't.
Do you prefer the web from 1995? No youtube, no github, no google docs, no google maps, no real-time in-browser messengers/chats, no hangouts/google_meet/jitsi, etc. etc.?
However the Internet isn't the Web, so certainly the Internet doesn't need Javascript.
Also neither does the web, but for sites that can provide functionality which wouldn't be possible without javascript it can be a nice optional feature. Though all of the examples you gave either do not need javascript (youtube, github) or are better as native apps (google docs, google maps, IMs).
I mean, even if you were fine with that, nowadays pretty much everything is available on Linux too and crossplatform development tools for native applications existed for decades already.
Industry practices collapse under the weight of their own complexity and people argue on HN about it with absolutely no context on the real issue, just presupposed bugbears like “privacy”. Video at 11.
JavaScript is the single worst thing to happen to computing in its history. Maybe not the language itself - it’s fine enough for its purposes - but the industry deciding that its purposes overlap with a wildcard glob is a huge mistake that we will be paying for long after everyone in this conversation is deceased. It’s annoying that you credit that situation to JavaScript and laud it given what else comes with doing everything in a browser (enabling the surveillance economy, inadvertent network dependencies, computers running at about 5% ability, etc etc)
They exist since decades, but apparently C and C++ are even more hated than JavaScript.
Since you’ll probably pedant me with several names I can already think of, it’s worth remembering that existing does not imply easing burden nor being useful beyond a README and a weekend jog.
So lets spend ourselves some time that you can get yourself improving your Electron skills instead.
I can give you computers running slower. As for the surveillance economy, I am not sure why you think that installing someone else's crap on your computer is preferable compared to running that crap in your browser and blowing most of it away every time you leave the site (or blowing it away completely by clearing your browser's storage). As for network dependencies, websites are now perfectly capable of running offline, while native apps may need network access for doing anything useful as much as a browser app does.
As a developer, I would rather write once and run everywhere. As a user, I would rather not install hundreds of megabytes of someone else's "apps" that could have been a web page on my computer, other than the bare necessities that I am comfortable with. Nor do I particularly care to update those installed apps locally, downloading hundreds of megabytes more or having the risk to run into software version issues. Having vim on my machine is fine. Having Facebook, or Twitter, or Reddit is not.
Each distribution is a snowflake, and now GNOME even considers UI design tooling something worthwhile killing in name of GtkBuilder with raw XML, exactly what UI/UX designers have asked for.
You can use HTML, Canvas, and CSS to do just about everything you mentioned.
Video is easy. In pure HTML: <video autoplay loop muted playsinline src="..."></video>. No Javascript (or even CSS) required. You can certainly expand on that as well.
Google Maps does not require Javascript to provide it's core and common functionality either: https://appelsiini.net/2008/google-maps-without-javascript/ You would have to make some changes, but core functionality still exists.
Github does not require Javascript to function. You can toggle JS off and still use it pretty much as is, and the features that do break are trivial to implement without it.
Interactive realtime chat does not require javascript. https://github.com/kkuchta/css-only-chat , and the same principals can be applied to online docs and editors as well.
Javascript is the norm because it has inertia behind it - largely due to circumstance more than any inherent natural benefit, not because it has some secret sauce that the internet needs that couldn't be easily replaced should it be Thanos-meets-Tron-Crossover Snapped out of existence.
A much stronger argument in favor of Javascript would not be pointing to all the good things you can do with it, but rather, with how well and optimized and streamlined doing those things with Javascript is these days. Just to clarify, I'm not saying Javascript is the problem, but rather, the abuse of it, and that abuse would still be an issue if other technologies replaced it one day.
I use the internet with JS toggled off by default as a result of the rampant abuse of dark patterns (for example, the Google Search Suggested Alternatives box that is served below the sponsored result(s) that always "conveniently" expands after a short delay to push the first actual result down the page and replaces it with yet more sponsored content), 3rd party/cross site abuses (Malware), as well as the overabundance and omnipresent ad-spam. Sites that break as a result of my opt-in JS browsing is usually a sign it's not worth my time. Sometimes I'm proven wrong, but sites that can fallback gracefully and display some basic info without JS are usually the worst offenders..
TL;DR: Yes, in a way, I do prefer "the web from 1995", where Javascript isn't everywhere, and only present in places that I specifically whitelist, because it's all too often abused to negatively impact my experience instead of enriching it.
Calling any of this as anything other than Telemetry data is factually incorrect
The movement around forking is NOT just over this new privacy policy, but is a culmination several actions by the new owners of the project to go agaist some very basic norms of Open Source stewardship. Further they are more or less giving the Linux Maintainer community a "FU" over their use of custom / modified version wxwidgets which makes packaging the 3x version of Audacity problematic for many linux distribution for security reasons.
As to the statement that "opt-in does not work with crash reporting" Sure it does, Many applications (including Microsoft, and Mozilla) have a dialog that ASKS the user if they would like to submit crash reporting data to the vendor on a per crash basis, There is LITERALLY zero technical reason for automatic, opt-out crash reporting
Well Audacity thought it would work for them: https://github.com/audacity/audacity/pull/836
Crash reporting is more of a problem than telemetry. Any report that contains the contents of memory may end up leaking confidential data. That data may be considerably more sensitive than an analysis of how the software is being used. The end user should be informed of the risk, be able to review the data being shared, and have the right to block it.
As for updates, there are distribution models where this is handled by a third party. In some cases, a list of packages is downloaded so the only way for the third party to know whether something is installed is when an update is retrieved. In other cases, a list of software is sent to the third party but it is a trusted third party (e.g. Google, rather than a random app developer).
I'd trust a random app developer way more than an ad company whose data processing consent flow is intentionally annoying and still does not comply with the GDPR.
Obviously this applies to offline tools and not web browsers.
Am I so old that even the mere concept of beta testing doesn't make sense anymore?
Crash reporting: Why not just generate a crashreport-date.txt and allow the user to save it and email it to you? Why should they be forced to report it?
nobody does this. It’s such an utterly naive statement and exactly in keeping with others in this discussion. It also doesn’t catch non-terminating errors.
> Why not stay on old version or rely on package managers which do that for you?
Why would you want this? This also doesn’t work for Windows.
Because maybe an old version works good enough for your needs. Every software having auto updates is the reason package managers don't catch on on windows. Then you see every single software having bulky planned tasks/start on boot auto updaters.
>nobody does this
Core/crash dumps are exactly that.
>It also doesn’t catch non-terminating errors.
Why wouldn't it?
Why?
Isn't your decision to run this software some kind of consent to let it perform its basic stuff?
And if so, how far down that slope is it reasonable to go before trying to claim that crypto-mining is also an essential part of off line audio editing software?
It's not like program will stop working when it tries to send crash report without internet connection (if handled correctly).
>I guess the question is - is online telemetry and crash reporting reasonable considered and expected to "it's stuff" for an offline audio editing program?
For me - yes.
Yes, I do consider crash report as a part of software maintenance efforts and I have nothing against sending
critical data e.g at which place it crashed & e.g basic informations like OS, Hardware, GPU/Sound drivers version.
Should there be a way to disable that communication? Yes, and there is.
Beyond all that - if you are seeking the level of anonymity that would require evading program update checks or crash submissions - then you should probably lock down your network as your biggest worry is probably not your open source audio software.
Still, a good question is how you're getting updates in the absence of automatic updates (and for software whose goal is parsing binary file formats, chances are high that if you aren't getting updates, you have a pretty big privacy problem already). If you have no auto-update code but you're telling users to download new versions from, say, GitHub, then GitHub gets their IP addresses anyway.
I think hiding from GitHub is not something that average person does
but if you want to do it, then feel free to purchase 3$, then type
`ssh -D 8080 root@linux`, use SOCKS Proxy in Firefox's Network settings and here's your new IP
Different people have different needs and different levels of sensitivity to this sort of thing.
Personally, I don't want my offline audio editor talking to anything without asking. But since Audacity doesn't do that, this will be what I use instead.
If Audacity were to ask before sending data, a good chunk of people wouldn't be upset. But it doesn't, so here we are.
Also — and I've said it before — automatic "telemetry" and crash reporting is just lazy. It also lacks context. If you want to know what your users' experience is like, just ask them.
What successful ways can you envision that a software developer ought to be asking their users for their experience, when the software is available for free without restriction upon download or use?
How would you ensure that users who are satisfied with the way Audacity is working will take an equivalent amount of time to report their satisfaction as users who aren't satisfied with the way Audacity is working, so that your feedback is representative of the userbase as a whole rather than of the vocal subset that have problems? Would you advise Audacity to stop trying to measure or assess its users and their opinions, and instead simply do whatever they think is best for Audacity without harvesting user data?
If Audacity truly accepted the view that the product should never report a single byte of information back to them and that they should never attempt to collect any data whatsoever about their users, then they would be forced to make decisions about Audacity without those users' data (including their opinions!), even if those decisions could end up being disliked or contentious among a subset of the users. At that point I expect they would likely determine that product autoupdate and feature usage metrics are a valuable feature for the product and not of concern to most users, and then ship those — regardless of the cries of outrage from the subset that hold contradictory opinions — because, after all, that subset demanded not to exist to Audacity, and so their wish is fulfilled.
How can the vocal contingent of Audacity users who say "my existence should remain unknown to those who make the software I use" expect to have their opinions considered relevant, when they specifically demand not to be considered as existing at all?
All of the things you bring up are solved problems. They were solved years ago and the feedback methods continue to be used today by quality software companies. Just because Audacity and its owners choose the lazy route doesn't mean it's the only route.
Programmers and the companies they work for should stop trying to normalize telemetry. It's not normal.
Either products make decisions without telemetry, or they make decisions with telemetry. Either products make decisions without user input, or they make decisions with user input. You do not name any specific feedback methods that do work as a solution to this, and certainly I see none in use in projects such as Homebrew or Audacity that are cited as acceptable to you.
What "quality software companies" offer a feedback method that does not stir outrage among those who incorporate it into their products and/or efforts, when their feedback is not treated with priority and urgency? Every software company I've seen, small or large, has angry users who complain that their opinion has not been treated as correct by software companies, and those users congregate on forums and reiterate their pet peeves every day or week or month, in the futile hopes that this clamor will somehow influence the software company (which, generally, it does not). You do not address at all my concern about biased-towards-complaints data resulting from in-product surveys or feedback methods, and you do not explain how feedback methods unsupported by telemetry can measure the true amplitude of complaints rather than being biased by how loudly the squeaky wheels squeak.
You have failed to provide any supporting evidence for your argument that these are 'solved problems', and instead framed your unsubstantiated view as if it's fact. That isn't a viable approach at Hacker News, and I hope you'll take the time to correct it.
Is it reasonable to expect Audacity developers to just ask all of their users "Hey, how are things? Are things crashing? How and why?" I'm not sure if you've ever tried to diagnose a user's crashing issues, but, especially with non-technical users, you're likely to get responses like "A dialog popped up but I closed it, I don't remember what it said", or "I wasn't doing anything and it just crashed out of nowhere".
Automatic crash reporting is like night and day; sometimes, you can even find and fix problems before your users get a chance to report the crash (if they even bother to do so, which most don't).
> If Audacity were to ask before sending data, a good chunk of people wouldn't be upset. But it doesn't, so here we are.
From the pull request: https://github.com/audacity/audacity/pull/835
> Just to reiterate, telemetry is completely optional and disabled by default. We will try to make it as clear as possible exactly what data is collected if the user chooses to opt-in and enable telemetry. We will consider adding the fine-grained controls that some of you have asked for.
In other words, Audacity is asking before sending data and people are upset regardless, apparently due to just general ignorance about the situation thanks to some people blowing it out of proportion and describing it inaccurately.
I believe when you make crash reports / telemetry disabled by default then you lose a lot of reports,
thus make your life harder as a developer that wants to deliver high quality solution for as many OSes, hardwares, configurations, blabla.
I don't have problem that e.g my IDE would report how many files and lines of code my project has, because it may allow devs to make better decisions.
Perhaps I should have been clearer. I think something similar to Firefox's crash reports. If a crash happens, prompt the user and show them the report, and finally, let them decide. Perhaps even take out the networking features and open the default client with an attachment or a path of the report so they can be attached to a github issue.
So, like Audacity?
Here we'll only hear the strong pro-privacy views because that's the news.
Did you use computers 15 years ago? Linux desktop and open source tools? Nothing had this crap back then, and some of it was pretty good. Audacity itself is an example!
Open source software is not a commercial product. You don't need to prioritize and optimize for engagement or market share or any such crap. Just fix what you want, fix what you can, interested capable users will contribute attempted fixes for their own problems and you incorporate them if they make sense to the project.
I don't think telemetry has ever resulted in good software, it just pushes everything towards being an iPad with one button on it. Only skilled tasteful developers make good software, and that was true long before telemetry existed.
[1] https://errors.ubuntu.com/ [2] https://developer.fedoraproject.org/tools/abrt/about.html
Actual fixes overwhelmingly come from individuals manually reporting weird lockups and backtraces, often taking the initiative to bisect the issue to a particular commit.
Having said that, Sentry integration is another matter.
How? I only know Sentry as the backend tool you use to analyze the uploaded crashdumps? Or do you mean that a "crash report" could be something smaller than a minidump? (although I personally think a minidump is not a bad compromise)
Audacity has been around for 21 years, has generated a strong following from a wide range of users, and is one of the most widely-loved FOSS projects. It achieved said status without telemetry for 21 years.
People keep saying the telemetry thing is "overblown", but there is clearly a large number of us who simply don't want it. It doesn't need it, and the past 21 years have demonstrated that.
Open source users tend to be more privacy conscious anyway, even if Ultimate Guitar / Muse aren’t acting in bad faith (and they do have a bad reputation) then they’re showing a shocking lack of understanding about what they’ve taken over.
Had some troubles, as we (and I personally, and my loved ones) were hit by a 4chan raid. Take the comments in the issues on GitHub with a grain of salt, it's impossible to get ahead of this.
Need to wait for things to cool down to be able to organize everything later.
Anyways, AMA or something :)
i think it would be an interesting peace to read for any FOSS dev
That's rather horrible. Do you know where they might've found your pinephone number?
[1]: https://twitter.com/cookiengineer/status/1412201646378131459
Strange.
I just found it rather scary how these 4chan trolls are able to find his pinephone number despite it not being on his website or any of his social media.
http://web.archive.org/web/20210706000825/https://twitter.co...
What's your personal view (and that of others reading this thread) on software freedom and how to develop free software?
I'm glad you people went with libera.chat and not Telegram. IRC is standard tech that can be bridged from Matrix/XMPP (and others). But what about github? I don't think github is fit for free software development (being a centralized, non-free platform) but i understand the argument that everybody's on there. More specifically, do you have infrastructure for the website/CI/CD so you don't have to rely on Github Pages/Actions?
It seems like a good fit to get started to build binary builds in a reliable manner. Are you familiar with such tech? (or someone from your team)
Touche, realized I was being trolled again.
[0] https://web.archive.org/web/20210706000825/https://twitter.c...
Original comment: https://files.catbox.moe/p41sbh.png
You ever watch Judge Judy? She says quite often "If you tell the truth you don't have to have a good memory."
Yet no one is complaining.
So what makes audacity special?
However, those have been in Firefox for years. What's happening here is change which always makes people extra-angry.
VSCodium is not a fork but it also strips out the telemetry that VSCode integrates.
Outraged users creating issues about Audacity's privacy policy about telemetry [0] in their software probably haven't even read GitHub's privacy policy.