he/him/his, cis, gay, husband, Beagle chew-toy, JavaScript jockey, Rustacean
I think Poettering’s assumption here, which I agree with, is that it’s difficult to produce software without bugs, and it’s even difficult to patch those bugs without ever introducing new bugs
But, let’s pretend that we’ve accomplished this and never have to fix any bugs: we’ll still have to update firmware and other software components when a new CPU or other device needs to be supported
Although, admittedly, a user might not decide to install a hardware-enablement update if they know in-advance that they’ll never upgrade their hardware or plug in a new device
The mature answer is “it depends”
Absolutes are rarely 100% true, and it entirely depends on your perspective, your use cases, and your expectations
Neither DuckDuckGo nor CloudFlare (the other favourite punching bag around here) have surveillance capitalism business models, but they do require you to trust someone else’s software running on someone else’s computers, and you still need to communicate with them over someone else’s networks
From my own perspective, which suits me fine but might not suitable for you, I prefer to avoid surveillance capitalism companies like Facebook/Meta, Amazon, Google
I’m also not a free-speech maximalist: I want to live in a world where information flows freely, but I acknowledge that not every single idea deserves exactly the same amplification
The same people screeching about DuckDuckGo and CloudFlare regarding censorship are often exactly the same people claiming that LGBTQIA and Black history education is not “age appropriate”, so even free-speech maximalists are rarely consistent
Google must believe eBPF is mature enough (although they’ve been wrong before, see the Bluetooth stack rewrites and reverts in Chrome OS)
Note that desktop Linux distributions are working towards replacing iptables with nftables (added in kernel 3.13), so it seems as though there is some/broad consensus that we can do better than iptables these days
AOSP has dropped iptables in favour of the far more efficient and powerful eBPF: https://www.xda-developers.com/lineageos-19-android-12/
It completely breaks compatibility with decades of code that requires iptables, but there’s nothing stopping new work that embraces eBPF
Okay, you got me stumped here
Either I added my 3x Yubikey security keys prior to that feature being taken away, or there’s a bug, or there’s some condition that has to be met before you can add security keys to your account: are you using a compatible web browser (e.g. recent Firefox), and have you downloaded/viewed/printed your recovery codes?
Mobile phones are the least secure device that you are likely to own
Un-nuanced absolutist statements like this grind my gears a little, haha
SMS is plain-text, and codes from the authenticator apps (and possibly also the GitHub Mobile app) can be phished, so in this regard I agree that the security key option offers the strongest safety/privacy, but those other phone options are still better than nothing for the majority of users
As far as devices I own, the only TV I could buy here was one running Android 10 without any software updates in the last 2 years, I feel I can confidently state that the TV is less secure than the phone I bought this year with an OS patch from this month
You don’t need to use the GitHub mobile app if you don’t want to
Any of these can also be used (for example):
1:
You don’t need to add a phone number at all: https://lemmy.ml/post/257191/comment/176967
And security keys can be independently manufactured (even by ourselves) and disposed of when desired: https://www.indiegogo.com/projects/solo-v2-safety-net-against-phishing
I don’t disagree that many governments aim to increase surveillance, but non-SMS 2FA can be used to thwart government access to our accounts, so I don’t think you can accurately state that 2FA is a pro-government mechanism
Anonymity (which I am generally in favour of) can protect victims of abuse, yes, but it can also protect online abusers, so I don’t think absolute statements about it are helpful
2:
It has always been possible (and likely) to misuse encryption technology in ways that jeopardise security
So, I don’t think it’s true that the presence of alleged mechanisms are intended to be marker of quality/security/etc
Independent security audits and reviews are a better marker, as this is the only way you can know if a service is correctly hashing+salting your password in a database instead of storing it in plain text
You’re argument here is like saying HTTPS is meaningless now that almost everyone is using it, when the security uplift is such a huge net positive for everyone
3:
I agree, this is a huge current use case
We don’t have the details yet, but, I will speculate that GitHub will leave SSH authentication alone, but you’ll need MFA to use the website/app, so you’ll need MFA to e.g. add a new SSH key to an account/repository
There are a range of two-factor authentication mechanisms that can be added to your GitHub account, so this does not require sharing your cell phone number with them at all if you don’t want to
I’m not sure why people are complaining about this change, this seems like a reasonable security uplift that will hopefully be adopted across more services
I encounter misinformation and other FUD about immutable distributions quite frequently
Imagine a root filesystem that is only modified when you expect, instead of at any time by any software on your system, the horror! </sarcasm>