Volume encryption would either mean typing a password at boot, or needing to use the TPM, which would get stolen with the NAS, so either very inconvenient, or useless.

And I dont think anyone breaking in to steal a NAS is going to do it to read the data, they’ll sell the hardware for cash. Anyone who would break in for the data is likely a far more sophisticated threat, which is a bit paranoid.

1 vote against truenas scale. I am happy now that it’s setup, but it was such a pain to get working. The GUI insisted that the disks had no serial numbers, but I could see them clearly in the commandline. I had to commandline setup the zfs, which they dont doco, and it has diverged from the published BSD instructions.

I also get the impression that unless you are using commercial grade stuff, truenas dont want anything to do with you.

Do you really need encryption if its all local? You should be able to trust your network is safe, so encryption in transit is the most you need to worry about? And if your NAS is on 24/7 its decrypted 24/7 anyway, so no real win having disk encryption.

Or you drop something heavy nearby and the disk skips and aborts.

Very expensive mistake if you messed up the disk during the write period.

You could make new hardware, but realistically, it doesnt happen. The secrets get lost, the skills get lost, and the medium dies.

There is no chance that there is a working reader in a few thousand years time, let alone billions.

All that said, I agree that we need stable long term storage, my point is that billion year storage is just a fantasy spec. It looks good to investors, but doesnt hold up to reality.

Of course, but that is still a very long time.

360TB x 500Mb/s write == 73 days to write

https://www.omnicalculator.com/other/data-transfer

Thats a long write time. Also, I have to assume that most of the read/write hardware can’t live that long, so that’s all a bit theoretical. They’ll stop producing the hardware shortly after selling all the discs.

Fruits. You put a heap of sugar and fruit in a pot and stew it all together and lasts for a long time in the cupboard.

Maximum anonymity would be to fake your death and go live in a cave, never speaking to a human ever again. Which is obviously silly.

ING works fine with no permissions.

Sometimes it feels like a portion of the community views complexity as a badge of honour.

Its not this, it’s that there are very serious risks to self hosting (dataloss, hacks etc), and if they aren’t prepared for them, itll be catastrophic.

The gatekeeping isnt just for fun, there are actual risks and downsides.

As for prepackaging an appliance, we already have a model for how that plays out. There are millions of ISP provided routers and IoT things, and every other day there is a new breach involving them.

I’m definitely not an expert, but, I can give a lay-persons vibe:

1. Nested crypt isnt super-unusual, most commonly it would be SSL wrapping an applications crypt. You are taking it to another level though.

2. My gut feel is that its security theater. If you can’t trust one layer, then dont use it at all?

3. I wonder if timing sidechannels would get worse? Encryption and compression often have weird sideeffects, so maybe there would be some risks there? I’m not smart enough to know tbh.

“Grandma, there are lots of scammers around, if anyone calls and claims to be me, ask for the password”

Yes, it only works if we also appropriately educate our at risk family members and instill a healthy level of caution. But if we aren’t willing to do that, then there is nothing that can be done.

Have a safeword with your grandparents. If anyone claims to be you, they have to know the safeword.

Aside, this isnt new, and doesnt require AI. You dont need to do fancy voice matching or anything special, just claim that the phone connection is bad.

iPhones have locked bootloaders, and that likely will never change.

11-12 should be well tested. 12-13 should be well tested. 11-13 may work, but you may be the tester.

I’d step through one at a time.

Yeah, it prevents booting on that motherboard, but they can just yank your disks and boot it on another motherboard.

Normally, a good bios password implementation shouldn’t reset with CMOS battery, but for yours it seems it does.

Bios passwords dont provide security at all. At most, mild theft prevention (that is trivially bypassed). If you want security, disk encryption is what you want.

Replace your CMOS battery, NTP is good to, but you really don’t want your CMOS freaking out.

Shaggy defence

Ctrl-alt-Fnumber until you get to a tty shell. Login, run journalctl - f. Ctrl-alt-Fnumber until you get back to login screen, and login. Go back to tty and see what errors got logged.

If you have ssh enabled you can also ssh in and run the journalctl cmd. You’ll have to try different F number keys, I dont remember which ones get you a tty and which gets you the login. Start at F1 and move across, but wait a bit, sometimes it can take a while to spawn the TTY.