Worse they require frequent logins on device to keep the with client working. Just making the account on device isn't enough. You have to maintain it as well.
Sometimes there's no choice. If it's between beans and rice or nothing at all, then it's going to be beans and rice. Soup kitchens, school lunches, etc are a great help too.
Not the parent and I will continue to use F-Droid but Obtanium is a popular alternative. It allows you to install apks directly from various supported sources (forges, F-Droid repos etc) so you typically use the apk that the app maintainer has produced in their CI pipeline rather than F-Droid's reproducible builds.
F-Droid would likely get APKs from the same place (if reproducible builds are on for the app in question). If this attack is implemented successfully, then that place was compromised as well, and Obtainium can’t do much here to detect that I’m afraid.
Edit: on second thought, they could pin certificate hashes like F-Droid does on the build server, but verify them client-side instead. If implemented correctly this could indeed work. However, I think F-Droid with reproducible builds is still a safer bet, as attacker would have to get write access to source repo as well and hide their malicious code so that F-Droid can build and verify it.
Okay, but sideloading is worse? AFAICT the problem we're discussing was in F-Droid doing extra verification (somewhat incorrectly, apparently) of an APK before handing it to Android to install. Regardless of F-Droid, Android will check signatures on updates against the installed version. So your response to F-Droid imperfectly checking signatures as an extra verification on first install... is to skip that entirely and do zero verification on first install? That's strictly worse for your security.
Sideloading sounds like a massively worse option than using F-Droid even with this flaw. Humans are way more likely in making mistakes, and you lose a lot of safeguards in between you and the APK when you sideload. Also, you don’t get updates as fast, which is a whole problem in itself.
So, IMO we should not fall into that trap of immediately removing apps that had a security flaw and falling back to a way worse alternative (which sideloading is) instead.
Exactly my thoughts. I don't understand whether I'm really spoiled, or is the crowd here weird about upgrading for some reason - if you have a laptop from 4-5 years ago, the new one would be 2-5x faster in vast majority of things - even if not critical for your workflow, it would feel SO MUCH nicer - so if it's something you use for 100h / week, shouldn't you try to make it as enjoyable as reasonably possible?
Other example - I'm by no means rich, but I have a $300 mechanical keyboard - it doesn't make me type faster and it doesn't have additional functionality to a regular $30 Logitech one - but typing on it feels so nice and I spend so much of my life doing it, that to me it's completely justified and needed to have this one then.
That’s a feature, not a bug, for some. When I upgraded to an M series chip MacBook, I had to turn up the heat because I no longer had my mini space heater.
The article isn't about solving those problems, it's about taking a few days longer to do the actual travel to save a bunch of money, since there's already massive delays on either end.
No, the article is saying "actually I was wrong about being longer and slotting in between airplane and cargo ship; we can be as fast as planes, but cheaper, and take a big slice of that whole huge market". Which is why they need to explain why airships won't also have customs etc.
