> What remains to be seen is which polling stations remained open and which did not.
You can check it yourself, the output and log files for each ballot box are already available. I can see that mine opened and closed at the expected time.
Or even Whatsapp, which people already have installed on their phone. No need to go to the store to install anything.
A scammer managed to convince a relative to share their screen during a Whatsapp video call. Luckly, said relative didn't use banking apps on the phone, the bank rejected as suspicious the transaction on the computer which would have sent money to the scammer, and the relative asked me for help before going to the ATM to unblock the account (I then contacted the bank and had them fully block the account as a precaution, and told my relative to go to the bank branch the next day to change the passwords and unblock the account).
Or the adb escape hatch. IIRC, their adb equivalent is limited to having a small number of apps installed at the same time, needs each app to be periodically reinstalled at short intervals (IIRC, one week), and you need to have your expensive Apple laptop with you for that reinstall.
Even with Android becoming much more closed, it's still more open than Apple.
> Having a small number of apps installed at the same time, needs each app to be periodically reinstalled at short intervals (IIRC, one week), and you need to have your expensive Apple laptop with you for that reinstall.
Not true if one pays up ($99/yr), in which case the interval becomes one year. Also apps that sign and install other apps with one's cert exist.
> actually it was one of the first stories about eMudhra appearing on the HN homepage yesterday.
I feel like I'm going crazy, something which happened (checks clock again to be sure) yesterday (actually two days ago I think, so much has happened that it all blurs together) is being considered old news!
It's not just IoT devices. It's also a very very long tail of programs which for some reason have their own copy of the CA certificates list, either because they don't trust the system's one, want to work identically on all platforms, have a severe case of not-invented-here, or all three at the same time (looking at you, Java...)
> Why would you want to access hosts via ssh over TOR?
When you're behind a restrictive firewall which blocks anything other than HTTP/HTTPS (like at an Internet café), or when there's some upstream routing issue making reaching the server directly impossible from your location (these can be a pain to diagnose).
Or perhaps it's simply your default: you proxy everything through Tor, and need a reason to not go through it.
Are there restrictive firewalls which block unknown HTTP/HTTPS but not Tor? I'd expect Tor to be blocked first.
(And then proxying via your home is much faster and safer. You can do websocket-based proxy, but even exposing ssh server on port 443 works in a lot of places!)
Once again, this shows the strength of mutual authentication (ssh user key authentication, or HTTPS client certificates): even if the client accepts the forged server key from a MITM server, the real server won't accept the client key exchange (since it, at least in the SSH protocol, is bound to the connection). For the three things the attacker did here:
1. It can't steal your password, since the private key never leaves your client;
2. It can observe each command you type, but it can't open a connection to the real server to know how it would respond to your commands;
3. It can't open any connection to the real server (it will fail authentication), so it can't do anything to the real server.
If you really like passwords, there are ways to configure sshd to require both a client key and a password, in that order.
You could also do mutual authentication of SSH, with a local password-encrypted private keyfile, if you really like passwords. That gives you all the benefits of the "something you know" factor, without exposing the password to the server. And you can inspect how the decryption and use of the key happens (since it is on your computer), and therefore see it doesn't leave your computer.
Or use fido/gpg in a yubikey - the user gets to authenticate the use of the secret, but it never leaves the hardware token, let alone the client computer.
> If you lose it report to the same people (service desk).
THIS is the reason it worked great for your use case. You have a stopgap for the worst case.
You also have a limited, well-known, and mandated set of compatible software and hardware. And you don't have to worry about attestation preventing you from using any future hardware or software, because you have control over any attestation whitelists.
The scenario people worry about is not "passkeys being mandated by your company to access company webapps on company-provided devices, with easy access to in-person passkey resets". The scenario people worry about is passkeys making them lose access to third-party sites on their own devices.
You can check it yourself, the output and log files for each ballot box are already available. I can see that mine opened and closed at the expected time.
reply