> Be the change in the world you want to see. Turn javascript off. Use real native applications that cannot change underneath you.
But they can change (underneath). Native app is one bug away from arbitrary code execution. When remote content triggers this bug, it becomes RCE. In this case it was javascript engine bug, in any other it could be your photo viewer or whatever native code you are running with untrusted content. The untrusted content being an image you are viewing.
> This is hyperbolic; the agents were only able to access the internet by finding a zero-day in the internal Artifactory instance that was providing package access for the agents. The sandbox could and should have been better, but it was not as weak as it could have been.
Like we all forgot how sandboxing is done for decades. This brokered thing they call sandbox is not it.
I guess that’s the point. Initial incident reports from all sides were so vague and didn’t disclose anything technical. If it did, it would show a bruteforcing bot let loose to spend millions in infrastructure costs and there’s no ‘intelligence’ in that.
My suspicions for ai all along was that bruteforce approach even if useful will be unsustainable due to high cost in the long run.
General desktop replacement is not easy to pull of (successfully). It seems weird to start with replacing windows or macos rather than SaaS and IaaS, which they are concerned about the most. In the end they still going to use phones with software from Google and Apple.
> I've accidentally set up passkeys just by clicking an okay button a few times in the past and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
No doubt there exist services that do not offer recovery method for passkey or mfa enabled account. But this is entirely on them (the service), to blame for, not the passkeys or the users. It’s bad implementation.
Why makes no sense at all unless you are very naive trusting they would not jump straight to the endgame if it was possible with the technology available.
It's unexpected to anyone with intuition about how a computer traditionally is supposed to work. As a general principle, as a user, I expect a file on one computer to be usable on another computer. Or, at the very least, if I need to obtain some other thing from the original computer to "unlock" that file, I should be able to do it. The idea of a file that is only usable on a particular computer feels weird.
I think it's time to update your expectations. Hardware security modules have been around for quite a while. You shouldn't assume that your chosen password is the only input to the key derivation, or even that the raw key itself will always be obtainable.
I never assumed that my chosen password was the only input to the key derivation. Just that my chosen password is at least one of the inputs to the key derivation. LUKS has been around for quite a while.
Yes, that's kind of what you need to be able to successfully back up and restore an encrypted file. Why are you making it sound like that's such a strange thing to want?
Yes, in general that's how I expect (or at least want) things to work. And I'm a tech-savvy software developer.
Your average non-technical user will absolutely expect it to work this way, and if it doesn't, will be at best confused, and at worst incredibly angry that their photos are gone.
The sane way for encryption keys stored in hardware (secure enclave or tpm like) is to onboard user when the key is not derived from user password. Just like they do for FDE to export a recovery key and then you can adjust your expectations when you know (been told) whats going on.
No, I'm asking for what LUKS has done for two decades. Keyslots are alternatives, not requirements, so a TPM slot and a passphrase slot coexist and either one alone unwraps the master key.
BitLocker does the same with key protectors. Even on a local account with no internet, there's always a 48-digit recovery password that opens the volume on a completely different machine.
Two of the three major platforms ship a portable passphrase path alongside the hardware one, so this being unavailable here is a product decision, not a law of key derivation.
> You can export your passwords to a plain text CSV from the original computer.
Exporting a private key from a keychain is hard to automate (the password of the keychain is asked for all exports, and HAS to be typed manually IIRC).
But that’s not backup restore? I’m thinking Time Machine restore on a new Mac when old one is no longer working. Or when the old one had to be wiped and restored.
What information from your login keychain do you expect to need on your new computer?
There's not really a plausible answer to that question, because the login keychain data is almost entirely specific to that host.
To iron-man your argument: Apps that store account credentials to third party services will need to be signed in again.
If you were using http basic auth for a website and saving that, then it was probably in there.
Private keys and certificates you manually imported, or that were created by an application for your host. This is the closest to a plausible answer, imo.
It's also unexpected when you send your laptop in for a screen replacement, the tech does an unnecessary logic board swap while he's at it, and your local keychain doesn't work anymore. And then Apple Support will say, hey, we told you you needed to backup your data! Which you did, but that's not the issue.
I've learned to not trust Apple support on anything. My daughter's Watch screen cracked and we sent it in for a replacement. To setup the replacement though, they requried that she unpair then repair the watch then-and-there. They said she wouldn't lose any data, that it just disconnected it from the phone.
Nope, unpairing is a complete reset apparently. And Apple Support was apparently not trained to know that not everything syncs in the backup. She lost all her voice memos, which she uses for class notes, and probably other app data as well.
Can you clone or sync hardware keys? Maybe they don't fail as much as computers do but they can be lost or stolen like the keys that we use to open (dumb) doors.
My non hardware key is a keypass file that I update only on my laptop and I sync to my other devices. I have plenty of backups. It does also the TOTP required to login into some customers servers.
I have a few yubikeys and it’s a manual process to sync a new key last time I tried
I keep all my TOTP keys on an encrypted usb drive in a safe. When I lose a key, I manually add all the TOTP accounts onto the new key from my safe
Passkeys are a different story. Every account I need to make sure I have multiple yubikeys registered. When I lose one, I get in via a second key and then add the replacement one.
It’s a pain but it’s a model that makes sense to me. Lose the key? Time to reach for my backup key.
Basically you add more radiators to keep water temperature low or you add a backup heating source such as typical electric water boiler that will be used only during very cold days to increase water temperature when heat pump cannot keep up.
And they are, in fact, planning to continue to use RHEL and/or AlmaLinux on their desktop and datacenter machines, even going so far as to adapt Fedora's build system to support building Debian packages[1] to leverage their existing RPM infrastructure.
As I understand it (from reading another article[2] posted on HN a few days ago), this change applies purely to the layer of machines that more or less directly interface with their experimental hardware, which has requirements more akin to industrial controllers than workstations or servers when it comes to the expectation of long service life with limited windows for scheduled maintenance.
But they can change (underneath). Native app is one bug away from arbitrary code execution. When remote content triggers this bug, it becomes RCE. In this case it was javascript engine bug, in any other it could be your photo viewer or whatever native code you are running with untrusted content. The untrusted content being an image you are viewing.
reply