Audacity is an indispensable utility. It’s great to see it and other “real” software on the web. I’m reminded of Photopea[1] which is a web clone of Photoshop.
It's been a very long time since I used it, but didn't Audacity turn evil, add a bunch of networking code it never needed before, and start spying on people? (https://fosspost.org/audacity-is-now-a-spyware/). I remember people reverting to older "safe" versions.
I guess that doesn't much matter for this web app since it's collecting your IP and data by design (their privacy policy seems very vague and handwavy), but for the desktop app it seemed like kind of a big deal at the time.
Even A/B testing could be considered an ethical hazard because it disrupts the user's understanding of the software for the sole purpose of decisions that, frankly, devs should have made before telemetry.
Users should be able to trust that their software won't be blabbing over the network about what you're doing. In an age where privacy is attacked from all angles, it's the least a developer could do.
> Users should be able to trust that their software won't be blabbing over the network about what you're doing.
Says who? That’s just your opinion. My opinion is that if an exception happens in my software that makes it harder for me to use, the developer should be aware of the issue and fix it so that the software works correctly in the future. There isn’t anything wrong with your opinion, but there is something wrong of accusing the developer of some type of impropriety just because they want to use telemetry.
Telemetry is what happens when lazy or complacent devs move forward in their software but decide to be 'data driven'.
What's wrong with accusing someone of having the ability to spy of maybe spying? The point with technology and humans is, if the ability is there, it's not 'if' it will be abused; it's when.
Software that doesn't phone home or have telemetry never has to worry about that moral hazard. User data doesn't belong to developers, and that includes behavioral data.
This conversation can go nowhere because you believe you’re right and others are wrong. You really should accept that you have a specific preference and other people have other preferences. It’s not a question of right or wrong.
There is too much behind-the-scenes telemetry, analytics, and other intel-gathering happening on websites and in software. The gains are held solely by developers who either cannot figure out how to build their software, or whose management is so incompetent that there's no real connection to the users of the software, so making meaningful and helpful change to the software is less accessible.
I strongly hold that the practice creates less durable software that also primes a user to expect their software to study their behavior and change accordingly. That is supremely creepy, and users deserve better treatment than that. It's our job as developers to respect the resources our software is using on the user's machine, and for them to be 100% informed of anything they may be sharing over the wire.
Maybe that viewpoint isn't in line with VC-backed startups or enterprise, but I also don't expect them to act ethically wrt software, either... Analytics and telemetry created the data brokerage industry. Programmers are responsible for allowing that behemoth to invade and shape lives.
You don't need telemetry for that. We have several decades of data showing that software can be developed, tested, deployed, used, and valued without ever forcibly collecting a single bit of data from users.
Why on earth should a user trust that their data isn't being used to spy on them just because it's being collecting under the guise of being for something else? Once the data is collected, the user has no control over what a company will do with it and the only sane assumption users can make these days is that if a company can make more money by doing something (like selling or abusing the personal data of their users) they will do that thing.
The practice of collecting telemetry is also highly suspicious because it's often done without the user's consent (opt out at best), and without showing the user exactly what data is collected and sent.
The fact is that companies have betrayed the public's trust so many times, and in such egregious ways, that it's unreasonable for developers to expect people to "just trust them" to do the right thing. If you don't want to be accused to spying, maybe just don't behave like spyware. Do testing, solicit voluntary feedback, and eat your own dog food.
We also don’t have “decades of data”. Almost all large scale software systems leverage some form of telemetry/monitoring. Would you run a factory without quality control on the process? A more interesting question to me is which large software systems don’t use telemetry? Linux maybe?
When many people connected to the internet via dial up, phoning home (even just to check for updates) could get your software branded as spyware. The idea that a software company would be collecting data on what dates/times you were online, what your IP address was, and when/how often you used the software you purchased was offensive. Adware (and nagware) were tradeoffs users knowingly made, but data collection was a sin.
As the internet got popular enough more and more programs started spying on users and there were efforts to come up with clear guidelines for what was/wasn't acceptable, for example: https://www.grc.com/oo/cbc.htm Today most programs collecting telemetry would fail by that standard.
Just because "everybody does it" today that doesn't make it right. Most computer users have no understanding of what the software they run is doing, very little idea of the risks/harms involved with giving up their personal data, and no idea that there was ever a time when things were any different.
It's still not any of your business when your users run their software. Which features they use more often or what tasks they use their software for are also none of your business. You might find that information useful to have, but that doesn't make it yours to take without asking.
This isn't just "my preference" either. When users are respected enough to be asked if they want to be tracked, the vast majority of them care and won't opt in (https://iapp.org/news/a/research-shows-25-opt-in-rates-for-a...).
You don't need telemetry. If you want it because it lets you be lazier, request permission before collecting anything and make sure users know exactly what is being collected before asking them to opt in. Just having or pointing users to a privacy policy is not enough. Don't collect anything more than you absolutely have to and delete the data quickly once you have it so that it can't be leaked/sold later. Anything less than that is disrespectful and deceptive.
https://developer.mozilla.org/en-US/docs/Web/API/File_System...
There was nothing biased in my comment - even Chrome for Android doesn't support these APIs.
You know how everyone complains about Flatpak sandboxing until they learn about portals and Bubblewrap because the programs are isolated from the rest of their disk? The web is like that, except without portals and Bubblewrap. You can save stuff and drag files in, but you can't really integrate a webapp with a user's local filesystem -- and it's very hard to keep all of a webapp's data in a user-inspectable format that's easy to transform, open up with native apps, or transfer across browsers or websites.
Now, the problem is that persistent read/write access to user-defined folders is wildly dangerous. And Google's proposal is... not the worst thing in the world? But it's suboptimal and it's a missed opportunity to build something far better, and I kind of understand why Mozilla considers it harmful.
Getting this wrong would have permanent implications for the web. Mozilla is absolutely right to be cautious. However, it's also really holding the web back and in particular holding back PWAs because the only really reliable way as a developer to store data via the web is to sync it to an online account. As a result offline webapps are very limited; you never really trust the storage.
It's an extremely dangerous feature that we really need, but it's not clear who should champion it and I don't really trust Google to be heavily involved in the spec process, let alone to be the people writing the first draft. I don't think Google is good at building nuanced web specs even when there's no conflict of interest at all (see the web audio API, HTML templates, etc...). A lot of Google specs end up being very weird and they end up having strange quirks and very strange limitations that don't need to exist? They're very often kind of orthogonal to what the community needs. I don't know if the problem is that Google doesn't think enough about the spec or that they think too much and over-complicate things, but for low-level important features I prefer other browser-makers to lead the way.
What would be best is if a team with more earned trust picked up the spec and went over it again trying to better address the dangers and trying to make something that better addressed everyone's needs in a cleaner way, but there are not a ton of stakeholders on the web that I trust to do that. As it stands the proposal is... ok-ish? But needs a lot more discussion and could be better. I don't blame anyone for being hesitant about it; the potential for abuse is so unbelievably high.
But... it is a serious limitation that I can't ask for persistent read/write access to a folder from an offline webapp.
As a result there are a number of web-apps that could be entirely account-free and offline that aren't. It also makes it a lot harder for users to move and transform data, although maybe that's less of a consideration nowadays since mobile has kind of standardized data silos even for native apps that would have previously had portable databases or worked directly with files.
Not saying you should want it, I completely understand and am completely sympathetic to anyone who says "the benefits don't outweigh the risks." That is a fine position for someone to take. That being said, this isn't just about trying to make the web more powerful, it's also in a lot of ways about fixing long-time deficiencies in the web that have made it less private and that forcibly shift the majority of even well-intentioned web software into a user-hostile SaaS model. When every webapp is a SaaS business with web accounts, that decreases hobby development in favor of corporate development and encourages users to spread their data in (imo) irresponsible ways.
A UI rework to incorporate mobile-friendly design would be a ton of effort, but it would really take this project to the next level!
That's not to say that there can't be mobile audio apps, or mobile whatever. I just think that's a separate app, and should be designed and written as a mobile app from conception.
I realize that a large cohort finds desktop applications uncool today, but I'm just so frustrated with the idea that serious and powerful desktop interfaces need to crippled in order to fit into a "mobile-first" (a.k.a. "lowest-common denominator") paradigm. For audio listening, that's fine. But for serious audio creation and editing? FUCK an iPhone, sheesh.
Yeah, my primary issue with this sort of thing is that there is very little personal A/V content I'd feel comfortable uploading to some random server in the first place, but I agree that there are some tools better suited for the desktop and more specifically a keyboard and mouse.
The problem is that a very sizable part of the population doesn't have a desktop. It's not that they think it's uncool exactly but for a lot of people, kids especially, all they have are cell phones and tablets which were designed first and foremost for content consumption. I can't blame developers for wanting to target the needs of that audience to whatever extent they can.
I think Audacity devs should instead focus their limited resources on desktop (mouse+keyboard+big screen) use. Also because if you just need some simple audio editing, you can be served by other simple mobile apps.
This is what people like me have been getting at for ages when we talk about decoupling interfaces from application logic. It's also incidentally a really strong argument for decoupling state presentation from visual presentation. I should be able to build a mobile interface for Audacity without rebuilding Audacity both because the audio processing logic should be separate from the interface and because the interface should be separate from the visuals -- I should be able to consume Audacity's interface as an XML tree and pipe it into a separate renderer.
Because if that was the case it wouldn't be that hard to make Audacity mobile friendly (or at least more mobile friendly than it currently is).
As a bonus, if your interface is consumable as an XML tree without rendering anything, it's very likely going to be much easier to make the interface accessible. From what I can see in the documentation, Audacity as a native app on desktop doesn't work with screen readers on Linux.
This is not necessarily anyone's fault beyond GUI toolkit designers, it's not particular to Audacity, but it's a paradigm shift. Some visual controls wouldn't work well on mobile, but for most apps including Audacity there's really no reason (other than lack of existing infrastructure and toolkit support) why people shouldn't be able to just swap out those visual controls with ones that do work on mobile and use Audacity normally otherwise.