It is more efficient, in terms of cost the datacenter owner pays per unit of heat extracted. Water is cheap in places this is being done, relative to amount of heat vaporization can carry off.
You can certainly argue DCs should pay more for water than other uses, but who gets to decide what is a good vs bad use of water? Pricing in externalities is tricky, and water usage rights are especially complicated. I don't know what a good&fair solution is.
The litephone is too basic and the HiSense A5 etc do not work on US networks.
I looked at building a 5.2" e-ink phone for the US market and did some fun mock-ups, but it would be a huge undertaking with my limited hardware background. Smaller phones just have fundamental limits due to battery size that are difficult to work around, and Android has basically no e-ink support as it's such a niche type of display for a phone.
Yes that's fair, it's a trade-off. Thinking more, there are really three levels of protection I see.
1. Keep keys in a file/the keyring. This protects them somewhat from non-root users on the same machine. It also provides phishing protection, which is really the most important aspect of U2F/WebAuthn to most people. If your computer is compromised, all the keys are compromised.
2. Keep keys in the TPM. The only additional protection over #1 is if you recover your computer after it is compromised, you can be reasonably certain the attacker could not make a copy of the keys and thus can no longer use them to authenticate. Arguably this is not a particularly useful protection.
3. Keep keys in the TPM/secure enclave and unlock them via biometric. This does provide meaningful extra protection if every use requires an unlock. Then if your computer is compromised, the attacker will have to either defeat the biometric unlock, or trick you into unlocking for every authentication attempt.
#1 is what I do right now for rust-u2f, and I think you're right #2 is not really useful. So maybe it's worth just implementing FIDO2 without worrying about TPM support. What I really was talking about was doing #3 for Linux, but I don't see a way to meaningfully accomplish it without tight hardware integration.
P.S. It is recommend to register multiple FIDO keys and/or have backup codes for accounts as a way to mitigate the issue of one physical device breaking toasting an identity. Not all providers may support this, for silly reasons.
I've considered adding FIDO2 support to the software-only U2F token I wrote in Rust. It's a fair bit of work though, and I am not sure how comfortable I am with passwordless login unless the keys are kept purely in hardware such as a TPM.
That said, my reading of this post is that FIDO2 support will get built into Chromium directly, which is itself open source. Or if you do want a hardware key but running open software, I'd definitely recommend https://solokeys.com/, I've been following them for a long time.
I'd love to have something equivalent for Linux, but given that requires hardware support I think relaying auth requests to your phone is the closest equivalent.
I wrote that U2F implementation in software because I wanted phishing protection without needing to carry a hardware key. Well, and to learn Rust :) It's certainly a security trade-off to just store secrets in your keychain like I choose to, it is not meant to be a replacement for a hardware key and in fact I have a Yubikey I use when the situation calls for it.
I'd love to use TPM and biometrics to implement U2F/WebAuthn on Linux and have a proper, secure solution. Similar to what Apple has done with Touch ID. But that's no easy task. TPM support is poor on Linux and other options like relaying auth requests to your phone for approval and storing secrets in the Secure Enclave is no easier.
I would too. Go ahead and open an issue and we can chat more, but in short I think the biggest hurdle is understanding TPM2 and what API to use to interact with the device. (TPM2 is necessary so the key material never leaves the TPM, signing happens in the device itself)
Thanks for the suggestion. It hasn't been a focus yet because it doesn't bring much security for me personally, but it is something I would like to do eventually.
Though it suffers from the caveat that secrets are just stored as a file in $HOME. I'd love to support more secure methods but haven't seen enough interest in the project to justify the dev time that would be required.
You can certainly argue DCs should pay more for water than other uses, but who gets to decide what is a good vs bad use of water? Pricing in externalities is tricky, and water usage rights are especially complicated. I don't know what a good&fair solution is.