[HN Gopher] Audacity fork without any sentry telemetry or crash ...
___________________________________________________________________
Audacity fork without any sentry telemetry or crash reporting
Author : ushakov
Score : 106 points
Date : 2021-07-05 21:18 UTC (1 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| boba7 wrote:
| Already censoring people you don't like? Is this guy a kid?
| People vote sneed, respect their vote. What is this?
| blt wrote:
| Is there any decision on tracking upstream vs. diverging?
| rvz wrote:
| Yet the whole source is sitting on a closed-source software
| platform called GitHub, that also uses telemetry. (You know where
| this goes)
|
| Outraged users creating issues about Audacity's privacy policy
| about telemetry [0] in their software probably haven't even read
| GitHub's privacy policy.
|
| [0] https://github.com/audacity/audacity/issues/1213
| dane-pgp wrote:
| Shouldn't this have a separate name, to avoid confusion and
| filesystem/repository clashes? I don't know if there is a
| trademark involved, but that's a potential legal issue the
| project will want to keep clear of.
|
| 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.
| [deleted]
| ushakov wrote:
| Sneedacity seems popular!
| https://github.com/cookiengineer/audacity/issues/18
| smoldesu wrote:
| Formerly Chuck's, I'm presuming.
| boba7 wrote:
| I'm getting censored on HN just for linking to the new fork.
| Thanks guys. Very Denocracy.
| ushakov wrote:
| for anyone wondering what makes the name special
|
| https://knowyourmeme.com/memes/sneeds-feed-and-seed
| [deleted]
| PieUser wrote:
| I don't see anything wrong with telemetry or crash reporting in
| open source software
| shmerl wrote:
| Looking forward to someone finally merging XDG base directory
| support.
| boba7 wrote:
| Why is this censored by HN? Cookie is a mod here?
|
| https://github.com/formerlychuck/sneedacity
| dang wrote:
| Recent and related:
|
| _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)
| gizdan wrote:
| I have no horse in this race, but wouldn't it be better to keep
| crash reports in there? Of course it should be disabled by
| default, and it would never be uploaded. That way individuals can
| raise issues and attach the crashreports if they need to.
| jitl wrote:
| I think the reaction is completely overblown, the telemetry and
| crash reporting are already opt-in. The auto-update-checker
| (opt-out) only reveals OS, as part of HTTP user-agent, and IP,
| as part of the TCP connection.
| sneak wrote:
| Yeah, an offline audio editing program should not phone home
| in any way without advance consent. The autoupdate check
| serves as telemetry.
| orf wrote:
| Stop. Just stop. Software needs to reach out to the
| internet to provide some much-needed functionality such as
| auto-updating or crash reporting.
|
| 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.
| geofft wrote:
| Crash reporting is only needed if you write software that
| crashes in the first place.
|
| 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."
| zxzax wrote:
| I completely disagree with your assessment, Audacity just
| crashed twice for me yesterday.
|
| 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.
| orf wrote:
| I've found several bugs in SQLite, one of them pretty
| fundamental and obvious. It's a complete nightmare to
| report them, forcing you to use some utterly terrible
| forum software with limited searching, visibility and a
| shockingly poor UI. Genuinely the worst and most
| confusing thing I've had to use in the last decade.
| Sourceforge issue trackers are a step up from this. They
| also offer no convenient way to test your system using
| the latest RC/beta/alpha/whatever without manually
| staying on-top of the releases page and updating it.
|
| I don't think the rest of the comment warrants much
| discussion, but I wanted to point that out.
| petre wrote:
| > forcing you to use some utterly terrible forum software
| with limited searching, visibility and a shockingly poor
| UI
|
| 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.
| sneak wrote:
| > _much-needed functionality such as auto-updating_
|
| 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.
| Zandikar wrote:
| > Software needs to reach out to the internet...
|
| 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.
| smoldesu wrote:
| > creating a bunch of immediately abandoned forks is a
| joke.
|
| 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.
| orf wrote:
| Picking two applications with less global users than a
| small town or a large village doesn't make a great point.
| They might as well have been abandoned - no relevant mass
| of people use them.
| smoldesu wrote:
| Ah, my bad. I'll stick to S&P Top 500 companies next
| time.
| monetus wrote:
| Have you addressed the matter of consent in any of your
| replies? You sound very angry, you should take moment.
| kennywinker wrote:
| Software doesn't need auto updating. The "move fast and
| break things" industry needs auto updating. Other than
| some very few exceptions (e.g. a web browser with a huge
| attack surface may need auto updates to protect the
| user).
|
| 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.
| tester756 wrote:
| How about just asking user whether he wants new version?
| kennywinker wrote:
| Exactly. Nobody's complaining about a "check for updates"
| button.
| orf wrote:
| Yes it does. Bugs need to be fixed, improvements need to
| be made. That's the lifeblood of most user-facing
| software. Without it you end up with a huge user base
| running legacy versions, reporting the same bugs and
| asking for the same features.
| BugWatch wrote:
| _WHENEVER_ I had (or left) the auto-updates on, I came to
| regret it, from Windows updates to Android apps. Form it
| usually takes is (and all of them personally
| encountered):
|
| - 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.
| kennywinker wrote:
| That's a minor inconvenience at the bug-screening level.
| I've used audacity for over a decade, updating it once
| every year or two - either when i got a new computer, or
| when it occurred to me there's probably a new version out
| there.
| orf wrote:
| Cool. Works for you, doesn't work in aggregate.
| kennywinker wrote:
| That's your opinion, not a fact. I'm happy for auto
| update to exist, but it should always be at the
| discretion of the user if they want to take part in it.
| orf wrote:
| Look around you. The market has spoken. It _doesn't_ work
| in aggregate, which is why even Ubuntu checks for updates
| periodically by default.
|
| I don't see anyone forking that in outrage.
| slackfan wrote:
| "needs to reach out to the internet to provide some much-
| needed functionality such as auto-updating or crash
| reporting"
|
| Software needs not do any such thing. Developers may
| _want_ this thing, but users absolutely do not need it,
| and neither does software.
| orf wrote:
| Wrong, users absolutely do need their software to not
| crash and to stay relevant. The user doesn't _have_ to
| update it (so no silent upgrades), but showing something
| when a new version is released is a great thing for
| moving your user-base off legacy versions containing bugs
| fixed in later versions.
| sneak wrote:
| "moving your user-base" shows your bias here. The
| developer doesn't get to move their user base, the users
| get to decide what version of software they wish to run.
|
| 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.
| nitrogen wrote:
| Show a button to check for updates on any version
| timestamped older than X months where the button hasn't
| been clicked in a while. Show the button on the crash
| dialog. Don't open a single socket without approval. Let
| the user decide.
|
| This is a fundamental principle of human interaction --
| ask first before touching someone's stuff.
| krono wrote:
| Neither crash reports nor auto-updates are vital to the
| functioning of the program.
|
| It doesn't seem so weird to me to have an application ask
| for permission first. Something most applications do
| anyway.
| tester756 wrote:
| >Yeah, an offline audio editing program should not phone
| home in any way without advance consent.
|
| Why?
|
| Isn't your decision to run this software some kind of
| consent to let it perform its basic stuff?
| aeturnum wrote:
| If Audacity branded itself as as an "offline audio editing
| program" I would agree with you, but its headline is (and
| has been) "Free, open source, cross-platform audio
| software." I think using the internet to check for updates
| and report crashes is perfectly within that mission and, on
| balance, not using the internet in those situations seems
| to against the mission.
|
| 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.
| geofft wrote:
| It's possible to do this in a way that doesn't reveal your IP
| - run the update-checking server as a Tor onion service and
| embed a little client that knows how to connect to the Tor
| network. Then your entry node doesn't know what you're
| connecting to, and the remote update server only knows the IP
| of the relay talking to it, not your actual IP.
|
| 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.
| tester756 wrote:
| Well
|
| 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
| reaperducer wrote:
| _wouldn 't it be better to keep crash reports in there?_
|
| 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.
| floatingatoll wrote:
| Ask who? In-product surveys would be ignored or trigger this
| same outrage, and requests for an email address at download
| time simply result in throwaway accounts and other garbage
| input.
|
| 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?
| reaperducer wrote:
| To me, your comment overflows with cynicism and not much
| else.
|
| 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.
| floatingatoll wrote:
| I have seen no effective solution for this, in any
| product yet to date, that both addresses my questions and
| satisfies the terms of "users do not exist" demanded by
| those who are against all telemetry or telemetry-capable
| functions.
|
| 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.
| danudey wrote:
| As someone who's worked at a mobile app company, crash
| reports were described to me repeatedly as "I was blind but
| now I see".
|
| 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.
| detaro wrote:
| The more relevant PR is probably
| https://github.com/audacity/audacity/pull/836 which was
| merged and shows the confirmation prompt for crash reports.
| tester756 wrote:
| >Of course it should be disabled by default, and it would never
| be uploaded.
|
| 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.
| me551ah wrote:
| The reaction is completely overblown. As a software developer
| myself I know how important crash reports are to figure out
| which bugs are impacting the most number of users. If everyone
| moved to this version without telemetry, we would end up with a
| far buggier version of Audacity because the developer has no
| clue of what bugs of prioritize. Audacity runs on multiple OSs
| and with the huge amount of hardware devices available, it's
| impossible for the maintainer of an open source project to test
| them all. I really hope that this project doesn't catch up, for
| the sake of bug-free audacity.
| geofft wrote:
| But if this project does catch on, it indicates that users
| prefer a pro-privacy Audacity to a bug-free Audacity. That
| might not be the decision you (or I) would prefer, but I
| think it's a legitimate decision for users to make and we
| ought to respect that.
| [deleted]
| detaro wrote:
| I mean, the crash reports appear to be with a confirmation in
| upstream already? (see screenshot in
| https://github.com/audacity/audacity/pull/836)
___________________________________________________________________
(page generated 2021-07-05 23:00 UTC)