Yeah, an offline audio editing program should not phone home in any way without advance consent. The autoupdate check serves as telemetry.
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?
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.
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.