Wavacity – a FOSS port of Audacity to the web

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.

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.

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.

I didn't say none.

You can always tell someone hasn't developed consumer apps for ChromeOS when they white knight for it.

If you want to know a specific API that DOESN'T work, but performs splendidly on Windows, then the Eyedropper is a perfect example.

There's an old bug report for it that even has Google Chrome team support, and still no dice.

But yeah, keep rushing to defend the platform that doesn't even get proper support from its creators.

Another example is given in the link you posted. Direct Sockets API is deprecated, but its replacement isn't available yet.

So, if you were a web-dev using "vanilla" ChromeOS to test a site, you better install a full Debian VM on your 4 gb machine, because there's no other way to spin up a server.

No, I think it was correct to say Fugu is NOT for ChromeOS.

Definitions of the verb apply from https://en.wiktionary.org/wiki/apply#Verb:

2. (transitive) To put to use; to use or employ for a particular purpose, or in a particular case

    to apply funds to the repayment of a debt

    We need to apply the skills we've learned to solve this problem