Hacker News Reader

Comment by axguscbklp | Hacker News Reader

Maybe I am being uncharitable, but my initial reaction is: What is all this verbiage? Just make software that does not phone home. Audacity does not need to phone home to implement any of the features that people actually use it for, so make it not phone home. There is no need for legalese or complex explanations. Whatever you think you are going to get out of getting more user data, just drop it. You do not need it. Just make the software not phone home, end of story.

Like I said, though, maybe I am being uncharitable. Am I missing something?

View on HN

It is pretty simple to do telemetry and phoning home correctly; be transparent and give the user control. Show them exactly what is being sent, how it will be used, let them edit the data and let them choose to when/how send it or not send it. The 0ad project does this well IMO.

> Am I missing something

I think so. It optionally phones home to see if there are version updates. It optionally phones home after a crash. They have to publish legalese to comply with GDPR because those phones to home store audacity version number, operating system and operating system version number, and country of origin (based on up). It allows them to know when it’s safe to drop support for certain operating system versions.

Why not just drop all that version updating and error reporting functionality?

… sure, and why not just publish the binaries on CD-ROM?

Would they still need to publish legalese if they made it so that updates and sending of error reports required the user to click a button every time, and under the button there was some text explaining exactly what data was going to be sent?

Yes. Laws _require_ you to have a privacy notice. Just because your license says the software is provided AS IS does not mean it's enough. Noone is going to bother you if it's a small open source project by a bunch of maintainers, but as soon as you're a company, you have to.

For the USA, that's not always true:

https://www.swlaw.com/blog/data-security/2015/03/12/why-you-....

But I know Audacity has a sizable European userbase, too.

Are you suggesting that Audacity is something that needs a lot of auto-updating? It's not like an OS. Updating it can wait.

A vast majority of users are non-technical. Manually checking for updates for software can seem like a trivial thing to someone who knows how to use a computer, but many folks don't know how to do these things, and would miss out on fixes and features if they aren't made aware of updates.

Also, it's an optional feature. You can just turn it off if it's not a benefit to you.

If these updates are compelling, people will know. Outside of security updates, there’s not often a reason update unless there’s a née feature you require.

I swear it seems like there’s a whole generation that doesn’t understand that how to build software that isn’t always phoning home and requires a subscription fee.

Every major browser phones home for version updates. Do you have a problem with them, too?

Yes. People should have control of and be responsible for their hardware and software. If people want to cede the responsibility and control, there's no problem with having that option, but it's a bad default.

The browser almost exclusively executes untrusted input and mediates access to user data. Not keeping such a thing updated is irresponsible.

An audio editor has an incomparably smaller network attack surface - perhaps even none, if it's sandboxed and makes no use of the network at all.

DAWs and audio editors have a very large (non-network) attack surface, in the form of plugins, which run in-process, with zero "protection" between them and the host [0]. A plugin can do anything the host app can or could do, including full access to user files, network access and more.

[0] some plugin host apps do "sandbox" the plugins by running them in a separate process, but this is absolutely nothing like the sandboxing done by browsers. The separate processes run with all the priviledges of the host app process.

That’s an issue with running untrusted code. If you’re intentionally downloading and running untrusted code, there’s not a security protocol in the world to help you.

Seriously. Don’t do that.

The definition of "trusted code" in this domain is essentially non-existent. "Oh, it's from Spitfire Audio, no problem" is about as sophisticated as it gets.

This is a user problem. Not App Store problem. Maybe you should t be downloading weird ads plugins from some rando forum that links to megadownload or whatnot.

> run in-process, with zero "protection" between them and the host

Perhaps that's the current state of things, but like you mentioned with web browsers, it's a thing that can be done if you're willing to sink enough effort into it. Browsers had to go through this process at some point too. There's nothing that prevents plugins from running in a sandbox where the only I/O is waveform in, waveform out.

https://ardour.org/plugins-in-process.html

I know you’re being sarcastic, but seriously. What’s the problem? It’s an audio recorder.

Because they want their users to enjoy the latest version, and be able to provide a good experience by not having a crashy software.

See what other people noticed. It's checking when it's safe to cut versions of operating systems.

Because it's useful?

How often do you, upon having a free/libre software crash on you, rebuild it with debugging symbols, run it through gdb to replicate the crash, and then send a full backtrace to developers?

I've done that in the past, more times than I care to remember, and never have I thought 'Blimey! That's a great use of my time! Let's do it again!'.

Nope.

Reply on news.ycombinator.com