@sylver_dragon@lemmy.world
sylver_dragon
member since 7 Jun 2023 13:35
comments
- on Not sure if this belongs here, but I hope it does. in c/privacy@lemmy.ml · 12 Sep 2026
-
on Not sure if this belongs here, but I hope it does. in c/privacy@lemmy.ml · 11 Sep 2026
It’s a design decision and one which is probably about right for many situations. TPM chips are not perfect, and there are a lot of situations which can cause them to fail or the hardware around them can fail (e.g. the motherboard). With the end result being that the data would be rendered unreadable. So a recovery key is a trade-off between confidentiality and accessibility.
The design of the recovery key itself is also fairly good as a backup protector goes. The key is long and complex enough that brute forcing it is hard enough and would require long enough that it is functionally impossible. If your concern is that the recovery key could leak, the easy answer is “don’t write it down”. You could simply choose not to store it and while it would be a theoretical attack on the confidentiality of your data, practically it’s a non-issue. But, for those folks who feel that having an unlock code written down somewhere is an acceptable risk while mitigating the risk of the TPM breaking and rendering the disk unreadable, it’s a good solution. And I can personally attest to the usefulness in a corporate environment. People do dumb things with laptops all the time. And no matter how much we might tell people to use the network/cloud storage which is off the system and backed up regularly, there is always a parade of people whose system just died and contains the only copy of important project data.
It’s important to remember that security is a long series of compromises between confidentiality, integrity and accessibility. All three are important. And you have to find the spot in the nexus of those factors which works for your situation.
-
on Valheim: Deep North 1.0 in c/games@lemmy.world · 9 Sep 2026
As excited as I am for this, it’ll be a while before I can get back to Valheim. My wife and I finished our last run, defeating The Emerald Flame in Ashlands, a couple months back and we’re not ready to deal with the Mistlands and Ashlands again quite yet. We also just enjoy the early game enough that we’d usually rather re-roll to experience the new content than continue an old world.
I’m also going to be curious to see what, if any changes and tweaks happen to the game with it officially released. In our last playthrough, the Mistlands still suffered from issues dealing with enemies which were slightly off-plane. A situation you cannot avoid in Mistalnds. Also, the particle effects and screen shake for magic were way over-done. Casters basically blind everyone else, but the magic is so incredibly invaluable that someone needs to do it, especially in Ashlands. I don’t know how you’re supposed to deal with the forts without it. Between spawn rates turned up to “yes” and melee weapons which have all the stopping power of a limp dick, the only reliable solution we found was yeeting a couple trolls into the fort with a batch of vines setup to hold the breach.
I’m also curious about support for mods. It makes sense that they didn’t want to put time into support during early access, but that’s now over. We basically don’t play without the Mass Farming mod and the Better Wisps mod. The former is just a tedium reduction mod and the later strikes a nice balance (for us) between keeping the mists and actually being able to find anything in the mists. The hunt for black cores is tedious enough without being able to see any further than my own feet.
-
on Leaked webinar reveals Flock employees teaching police how to surveil anti-Trump No Kings protestors and track their cars in c/privacy@lemmy.ml · 4 Sep 2026
surely you can’t profile criminals based on a film franchise with significant mass appeal. Talk about painting with a large brush.
If everyone is guilty of something, it makes yanking them off the street easier to justify to a news media asleep at the switch.
Never watched the video, so I’m just answering for the general case. Even with just a password, the recovery key serves a similar function. It’s a fail-safe if the primary protector is lost. It’s entirely possible that the password being setup will be given to a user and IT will still need a way in, if that password gets lost/changed.
Ok, and? Yup, LUKS uses different defaults. Don’t get too caught up on “Linux does it this way”. Both ways have valid reasons and the Microsoft developers and LUKS developers picked different defaults. If you want, you can create a recovery.key file on LUKS. If you are using TPM as your primary protector, I’d actually recommend you follow Microsoft’s lead on this. If that TPM chip (or the motherboard it’s attached to) dies, you’re kinda fucked. If you are using a password, this is less of an issue. assuming you have that password stored safely somewhere not on that system.