@paco @BenAveling it is just a stupid electronic device
-
@paco The toilet paper is for fiber.
-
-
@david_chisnall @paco AWS with the Mac Minis -- every time you power them off they wipe storage, takes a couple hours to complete before you can use the server again. Really annoying when you didn't expect it
-
@david_chisnall @paco AWS with the Mac Minis -- every time you power them off they wipe storage, takes a couple hours to complete before you can use the server again. Really annoying when you didn't expect it
@feld @david_chisnall @paco David nails it. Also, encryption at rest makes it possible to retire storage devices after End-of-Life without having to worry about data theft after retirement.
-
@feld @david_chisnall @paco David nails it. Also, encryption at rest makes it possible to retire storage devices after End-of-Life without having to worry about data theft after retirement.
@vinoth @david_chisnall @paco same reason why I FDE all my disks now. I don't have to care what happens if they fail.
Also I never have to worry about ZFS pool issues from moving disks around. Wiping the encryption key and setting a new one is much simpler than trying to scrub all the ZFS metadata off a disk -
@david_chisnall @paco AWS with the Mac Minis -- every time you power them off they wipe storage, takes a couple hours to complete before you can use the server again. Really annoying when you didn't expect it
The Morello cluster we set up at MS was exposed for GitHub Actions runners. We forwarded the GitHub web hook thing to an Azure message queue thing that the head node read. When it received one, it used an exciting pile of expect scripts to talk to the serial console on a node to boot one of the machines. The node then booted with a read-only NFS mount as the root filesystem, generated a random key, and used that for a GELI-encryped read-write filesystem on the (200GB) local SSD. The GitHub Actions runner (actually, the portable Go rewrite) then pulled the job to run. At the end, we rebooted the node and the next job would get a new key for disk encryption.
If a job left any important data on a node, the next user would get the encrypted data and, unless they deleted the GELI layer, would get it decrypted with a different key. We didn't need to bother scrubbing anything between uses.
-
The Morello cluster we set up at MS was exposed for GitHub Actions runners. We forwarded the GitHub web hook thing to an Azure message queue thing that the head node read. When it received one, it used an exciting pile of expect scripts to talk to the serial console on a node to boot one of the machines. The node then booted with a read-only NFS mount as the root filesystem, generated a random key, and used that for a GELI-encryped read-write filesystem on the (200GB) local SSD. The GitHub Actions runner (actually, the portable Go rewrite) then pulled the job to run. At the end, we rebooted the node and the next job would get a new key for disk encryption.
If a job left any important data on a node, the next user would get the encrypted data and, unless they deleted the GELI layer, would get it decrypted with a different key. We didn't need to bother scrubbing anything between uses.
@david_chisnall @paco yes yes yes this is exactly how it should be done (but the use of expect scripts makes me feel like we went back 30 years) -
@david_chisnall @paco yes yes yes this is exactly how it should be done (but the use of expect scripts makes me feel like we went back 30 years)
Yup, experimental hardware. It came in a rackmounted box, but it was really an evaluation board. The bootloader was never meant to do that. We had all of the serial consoles connected via some big USB hubs because the only way of netbooting them was to talk to the serial console and prod it with a bunch of commands.
-
@paco This is often essential for corporates to meet defined security standards.
Yes, it's far more probable that the application will be attacked than the data container, but there you go.
I also seem to remember that certain hacks *have* stolen the entire (virtual) container, so it is a nice to have.
-
@paco what about data-at-rest encrypted on your disk while malware is exfilling all data, the encrypted stuff is safe. imagine all your mails (seperately) encrypted, malware actor can only use the ones that are decrypted while present. limits damages.
-
@paco Groan, yes. Had someone just the other day asking about full disk encryption just after his wordpress had been hacked.
No, you need to fix your website. FDE might satisfy your auditor or other paper tiger box ticking exercise (ta-*dah*, security) but it won’t stop your wordpress being hacked again.
Which it was, a few days later.
-
@paco what about data-at-rest encrypted on your disk while malware is exfilling all data, the encrypted stuff is safe. imagine all your mails (seperately) encrypted, malware actor can only use the ones that are decrypted while present. limits damages.
@stf That is all true. It’s just totally unrelated to the sense in which OpenAI is using “encryption at rest.” It’s also nothing like what a cloud provider means when they say “encryption at rest.”
Can a person take individual actions to protect themselves? Yes. That isn’t the topic.
-
@paco This is often essential for corporates to meet defined security standards.
Yes, it's far more probable that the application will be attacked than the data container, but there you go.
I also seem to remember that certain hacks *have* stolen the entire (virtual) container, so it is a nice to have.
@syllopsium i didn’t say there was no reason to do it. I just said it wasn’t protecting the data. Compliance is the biggest driver. And this is a great example where compliance makes a bunch of people do a bunch of stuff that has limited value in reality.
-
@stf That is all true. It’s just totally unrelated to the sense in which OpenAI is using “encryption at rest.” It’s also nothing like what a cloud provider means when they say “encryption at rest.”
Can a person take individual actions to protect themselves? Yes. That isn’t the topic.
@paco i misunderstood i thought you criticize data-at-rest encryption in general, sounded to me like openai was only the trigger for that.
and the cloud storage thing also was confusing, in that context d-a-r-e also makes sense it all depends who is holding the only copies to the keys.
please excuse my confusion and my blatant off-topicness
-
@paco i misunderstood i thought you criticize data-at-rest encryption in general, sounded to me like openai was only the trigger for that.
and the cloud storage thing also was confusing, in that context d-a-r-e also makes sense it all depends who is holding the only copies to the keys.
please excuse my confusion and my blatant off-topicness
@stf I think what i did badly was compare it to encrypting a laptop hard drive. THAT has a ton of value because laptops are easily stolen. But I can see how it sounds like I didn’t think any of it was worthwhile.
-
My oldest website (1995) got hacked because a company did a shitty thing...but that's not the important bit...
The important bit is that I started rebuilding. Using old, old, older than marquee old html. For giggles, to see if I could remember it.
My site was being pounded thousands of times an hour by AI bots who think my site is the other company.
I now have a single page, explaining why I was hacked, with an email address so the people who stole my name can just buy the site because I can't ever use it again, but it will be a cold day in hell before I just relinquish it.
-
My oldest website (1995) got hacked because a company did a shitty thing...but that's not the important bit...
The important bit is that I started rebuilding. Using old, old, older than marquee old html. For giggles, to see if I could remember it.
My site was being pounded thousands of times an hour by AI bots who think my site is the other company.
I now have a single page, explaining why I was hacked, with an email address so the people who stole my name can just buy the site because I can't ever use it again, but it will be a cold day in hell before I just relinquish it.
@MissConstrue Grrrr. That sucks. I run a slightly popular, 20-year-old web forum. I ended up paying the $9.50/month to bunny.net to add their anti-bot protections. You can totally see in the graph when I turned that on.
-
@moira I have a really good car for this and I wish I could find someone that could do the work. I'm handy around the house and with computers, but I would never drive a car where I had a hand in fitting the engine.
@paco @moira Your nearest major city probably has a business or two that does this, the downsides when I last looked were "Hella expensive" and "you're getting Tesla parts in your car"
I would sooner trust James-Dean-cursed-death-porsche parts in mine. I should recheck, maybe there's more selection in motor and batteries these days... -
Then I might have been wrong and there were more leaks. They definitely had one last year, where they hosted pictures of peoples' passports in Zendesk (which is all kinds of insane).
If they used a "proper" age verification service and they leaked, that's an entire new can of worms. (Though I still think Discord in particular having age verification is not a bad thing.)The same channel did another video about Discord age verification.
Basically:
1) use an LLM-based system to guess your age
2) use a commercial age verification service using ID
3) send a support request via Zendesk, often attaching IDs and/or selfies (even though that should not be done via Zendesk)
Often people use them in that order due to simplicity and speed.
Only the third was "hacked" (some dude bought the password to Zendesk off an employee). Zendesk should obviously not be used for age verification or any other sensitive information.
So, age verification is in most cases bad and is obviously just a power grab when used like the UK system or the on-again-off-again EU system, but the Discord leak is not an example of why it is bad.
youtube.com/watch?v=rfspiibG_2c (about the leak from 7:13) -
among other things but we generally stay stocked up on TP and French toast.
