Understandable move. Still a sad day for retrocomputing, because once Linux drops support, compilers such as LLVM and GCC will soon follow suit, and soon there will be no way to write DOS or Win16 programs in Rust.
I think your analogy is flawed. I can be part of the losing 49% and still be entitled to receive the same services as the 51%, whereas people who chose a privacy-oriented OS are essentially going to be excluded from essential governmental services. That's a whole different kind of thing.
I'm not going to replace my 1200 EUR smartphone with a device that forces me to have an account with Apple or Google. I've been issued a German identity card, which is its own computer that includes a digital identity already. I also own an expensive card reader, which together forms a system that is completely capable of supporting any attestation anyone would need. They should just stop excluding me already.
>I' ve been issued a German identity card, which is its own computer that includes a digital identity already.
Then keep using it, instead of the not-mandatory app?
> I also own an expensive card reader, which together forms a system that is completely capable of supporting any attestation anyone would need.
Sure. In the mean time, do we tell the other few dozen millions that don't have an expensive card reader to go fuck themselves, or can we get to work on a solution that, even if not ideal, makes their lives easier?
> They should just stop excluding me already.
They aren't. You said it yourself, your ID is in your pocket.
Sure, that's why they stopped receiving paper letters for tax declarations once they setup Elster.
Oh, wait, they didn't, my bad. You can still declare your taxes with good old paper. The only people that can't are self employed, and that's because they have a different set of obligations with higher demands
Telecoms shut down 3G once 4G had rolled out. TV networks killed DVB-T after DVB-T2 went live. Banks have abandoned FinTS for app-based 2FA.
Your comment compares a paper-based, non-digital process with a digital one. My criticism, however, is about abandoning an old digital (but vendor-neutral and inclusionary) process in favor of a new (and discriminatory) one.
Well, in all seriousness what examples could you give me here in terms of device hardware attestation? Even GrapheneOS does use Google root certificates to attest your device. There is indeed an option for EUDI to keep a list of keys and I bet this is probably the way they are going to go for Android in the future. We shouldn't forget this is still in the planing phase.
> to have an account with Apple or Google.
True for Google, not true for Apple. Device attestation on iOS does not require you to have an iCloud account or sign into some Apple services. It works entirely using device hardware ids.
> I also own an expensive card reader, which together forms a system that is completely capable of supporting any attestation anyone would need.
Nope. This is eID and verifies your identity, it does not attest the security of your hardware. These are two different problems we talk about here.
> My Librem 5 runs an FSF-endorsed OS and has a smartcard.
Ok, so how does that help with device attestation? If I am an app developer how does it tell me that your OS has not been tempered with or actually that my app has not been tempered with? Are there any cryptographic keys stored in a secure place on the device that the Librem vendor can verify?
> This is extremely misleading.
But it's not. It's an architectural difference between how Google and Apple implemented attestation. Apple stores the generated keys in a secure part on your device and certifies them. The rest is your job as an app developer. And as a user, you do not have your iCloud or iTunes account used for device attestation. In contrast Google and its Play services are an integral part of the attestation workflow.
For Apple it's evident from their docs. As a side note: I do try to learn more about this, because of an incoming project concerning it.
> You can’t rely on your app’s logic to perform security checks on itself because a compromised app can falsify the results. Instead, you use the shared instance of the DCAppAttestService class in your app to create a hardware-based, cryptographic key that uses Apple servers to certify that the key belongs to a valid instance of your app. Then you use the service to cryptographically sign server requests using the certified key. Your app uses these measures to assert its legitimacy with any server requests for sensitive or premium content.
> Nope. This is eID and verifies your identity, it does not attest the security of your hardware.
The reader and its firmware is already certified by the federal IT security agency BSI for use with eID and banking. Why shouldn’t I be allowed to use that for whatever digital identity wallet thing the EU is cooking up?
Correct me if I’m wrong please, but this is a mobile Wallet app, an enclave, for government issued documents: Ausweis, Diploma, etc. How does a card reader come into the workflow here? I don’t quite get your point.
Currently, the card reader is the only thing that allows me to do banking and use government services on Linux. If at some point, governmental services decide to drop support for the physical-card-plus-reader systems and move everything to mobile wallets instead (like many banks already did), then I can’t do shit anymore without Apple or Google.
Right, because "you can't use an unpopular OS if you want your full rights as a citizen, and access to those rights must be additionally subject to a foreign corporation's opinion of you" is totally acceptable. I would go so far as to say that a government requiring any particular technology or private service to be a functioning member of society is hostile to all citizens. If your OS vendor / phone carrier / ISP all close your accounts despite no illegal activity, and your government has no alternatives you can use for essential services, then your government has sold your citizenship.
They didn't willfully delete their recovery phone number. They tried to delete a shitty, known-broken 2FA mechanism after they had set up passkeys. Poor UX conflated the two things, so their recovery phone number ended up being deleted. This is 100% on Google.
Why the fuck would Google care in which country I live? It's a personal decision, and no corporation should have any say in this. They certainly don't have to flag an account for that, especially not if the account has 2FA enabled. This is on Google, too.
The problem is the rapid succession of changes to recovery phone number, country, cellular provider. There is no way to differentiate, at scale, between an account takeover currently in progress that needs to be stopped immediately to minimize damage, and a legit user deciding to change all his personal info at once.
30 day cool down period is a reasonable response, at scale.
Of course you can keep your provider. It's called roaming, per OP story: "I am travelling to the UK and did not want to have *roaming* on my Australian phone."
For cheaper rates than roaming, typically you install a secondary eSIM for the country you're traveling. 99% modern phones support dual SIM for this reason
Back then, many programmers originally learned their ropes in an 8-bit home computer era (or earlier), where it used to be completely normal and even necessary that you used whatever memory region you got away with.
For example, on the C64, you would get away with using the memory locations $02, $2A, $52, $FB to $FE, $02A7 to $02FF, and $0313 as scratch space for your own programs. Memory was incredibly scarce. I can’t blame programmers for sticking with their habits and for taking several years to unlearn and adjust their misconceptions about who owns what if they came from a home computer era where that pattern used to be the only way to get stuff done.
I am now migrating all my unencrypted secrets on my machines to encrypted ones. If a tool supports scripted credential providers (e.g. aws-cli or Ansible), I use that feature. Otherwise, I wrap the executable with a script that runs gpg --decrypt and injects an environment variable.
That way, I can at least limit the blast radius when (not if) I catch an infostealer.
reply