I'd really urge the author to rethink doing something like this at all. The app looks great but those stats on the front page were an immediate turn-off for me (not to mention how it pops up in what looks like an annoying cookie banner). You can talk about user activity on a web service where it makes sense to be hitting a server, but for a local app that should really just be a nice GUI for ffmpeg, I don't want my computer updating you whenever I use it with data about how I used it.
And the types of users who are going to be using something like an ffmpeg wrapper are the types who are gonna care about something like that.
It's not SaaS anyway, so why would I care about your current to-the-hour success metrics? Might as well just slap your amount of sales up there, it's less intrusive at least. Put some user testimonials, anything other than telemetry data.
I agree with you to a point. The problem is that if most people turn it off, then developing the telemetry system was a huge waste of time and resources for not much gain. Valuable data that could have been used to improve the program without any extra work from others may be lost.
Similar to Windows forcing users to update because most of them keep putting it off forever, hurting their own security.
I wouldn't worry about it if I was the developer. Many people on HN might care but most people on average (even semi-technical folks using a tool like this) probably don't care. Most products have some sort of telemetry capabilities built-in (and any smart developer should try and understand their audience and app usage) and the people who care probably tend to on average be more wary about downloading closed-source non-App Store apps anyway etc.
It's not mentioned in the terms of service either.
I would recommend removing this because it's against the GDPR... and even foreign companies have to comply (for the protection of European citizens, wherever they are) if they offer goods and/ or services to citizens in the EU in some way (European region of an app store, ad campaigns in Europe, etc.) I also think that the GDPR is pretty correct in requiring opt-in consent before tracking, so it's "the decent thing".
That’s at best a weak band-aid. Who knows if blocking that one domain stops everything? We shouldn’t have to resort to firewalls or DNS filters to stop local apps from collecting our information.
I switched from a self-hosted transfer.sh instance to a selfhosted ffsend instance with r2 backend. Quality is much higher, easy to run on docker and its end-to-end encrypted. With the cli tools you can easily upload files from command line.
I thought of self-hosting this (it's fantastic, by the way), but why do that when there are public instances? Feels like too much work for little benefit.
For us, GitLab is the perfect match between enterprise (GitHub, Jira) and open-source software. We used the OSS version for years and switched to EE 2-3 years ago.
Depends on the location. If iWay does have a POP in your network, they can offer native IPv6 because their DHCP does support it. If they don't have a POP, they often (need to) use Swisscom to "proxy" your packages (like Crossover7). And because the Swisscom DHCP Server can't assign IPv6 leases currently, your router needs to tunnel IPv6 packages in IPv4 packages to the infrastructure of iWay.
reply