Not true. At the very least it can leak your IP address. There's a reason whatsapp & other messaging services have an internal proxy for generating web previews.
FYI your decryption key can be MITMed during this process by anyone with physical access to the system, which defeats the purpose of encrypting the disk in the first place.
Police show up and arrest you. Could be with reason, could be by accident. Maybe you did something wrong, maybe you didn’t. They also physically size your servers, and in doing so they unplug the system.
If you have disk encryption, your data now requires the police to force you to produce a password, which may or may not be within their powers, depending on the jurisdiction.
It’s strictly better to have full disk encryption and remote unlocking than no disk encryption at all, because it prevents such „system was switched off by accident“ attacks.
They have kits that allow them to unplug the server from the wall without interrupting power supply, specifically so they don't lose the decryption keys.
Sure, but in reality I'm more interested in not letting any low paid tech dude in the DC access to my data just because it can pull a drive. Or someone who buys the server from the provider.
In the real real world, not all police has that or uses it in every raid. We got visited once as a group of people some ten years ago, coordinated to happen at the same time at different locations across multiple states, and at none of the locations they brought any such equipment or expert, even though both the accused crime revolved around computing and warrant specifically was for computer equipment. They asked nicely for passphrases and since we didn’t provide any they got nowhere. They even allowed us to power down some machines for them, haha.
Maybe I have a server at home, with a locked cabinet and vibration sensors, that houses a server or two and they all use full disk encryption, but I still want to be able to reboot them without having to connect a physical keyboard to them. So no one has physical access, not even me, but I still want to be able to reboot them.
Or countless of other scenarios where it could be useful to be able to remotely unlock FDE.
That's not a counter-argument. You are protecting the physical access, and your threat model doesn't include someone willing to bypass your locks and sensors. (or it does and you just didn't go into those details.)
The argument was that physical access gives up the FDE key.
dm-verity only verifies block integrity and the boot chain and does not provide confidentiality or a secure remote key exchange, so someone with physical access can still MITM or tamper with the initramfs and capture a LUKS passphrase during a network unlock.
If confidentiality during remote unlock matters, seal the LUKS key in TPM2 tied to PCR values using systemd-cryptenroll or use Clevis with Tang over TLS with strict server certificate pinning, accept the operational cost of re-sealing keys after kernel or firmware updates, and keep an offline recovery key because trusting the local console is asking for trouble.
>Doesn't Discord require every user to create a new account, even if they're already using Discord in some other community?
No, the same account is used. You get prompted to choose a nickname each time you join a server though.
>So when they say "a Discord server", they really mean it--they're like droplets running independent deployments or whatever
No, they're probably all run on the same compute. The "official" name for a discord server from the API documentation is actually a "discord guild" and it works pretty much like a subreddit.
Good instinct to fight against antisemitism, because there is a lot of it. Unfortunately the Israeli government lobs accusations of antisemitism at its (legitimate) critics frequently, enough so to muddy the waters between actual antisemitism and criticism of the Israeli state.
Nah, let’s not let them to set the narrative. It is not antisemitism to criticize Israel and I do not care what Israeli or my (German) government says about it.
Because KDBX is a gzipped and encrypted stream, this is actually fundamentally an issue with the spec itself. A client must re-encrypt and compress the file prior to writing because a mere append operation is not possible. SQLite solves this issue by allowing you to write with page level granularity rather than being forced to dump the whole file for a single tiny change!
Couldn't they simply switch to zip files? Those have an index and allow opening individual files within the archive without reading the whole thing.
Also, I don't understand how using XML makes for a brittle schema and how SQL would solve it. If clients choke on unexpected XML elements, they could also do a "SELECT *" in SQL and choke on unexpected columns. And the problem with people adding different attributes seems like just the thing XML namespaces was designed for.
It's a single XML file. Zip sounds like the worst of both worlds. You would need a new schema that had individual files at some level (probably at the "row level.") The article mentions SQLCipher which allows encrypting individual values separately with different keys. Using different keys for different parts of a kdbx sounds ridiculous, but I could totally imagine each row being encrypted with a compound key - a database-level key and a row-level key, or using PKI with a hardware token so that you don't need to decrypt the whole row to read a single field, and a passive observer with access to the machine's memory can't gain access to secrets the user didn't explicitly request.
ZIP files can have block-like relatives to the SQLite page. It could still be a single XML file and have piecewise encryption in a way that change saving doesn't require an entire file rewrite, just the blocks that changed and the updated "File Directory" at the end of the ZIP file.
Though there would be opportunity to use more of the ZIP "folder structure" especially for binary attachments and icons, it wouldn't necessarily be "required", especially not for a first pass.
(That said there are security benefits to whole file encryption over piecewise encryption and it should probably be an option whether or not you want in-place saves with piecewise encryption or whole file replacement with whole file encryption.)
A ZIP file with solid encryption (i.e., the archive is encrypted as a single whole) has all of the same tradeoffs as a KDBX file as far as incremental updates are concerned.
A ZIP file with incremental encryption (i.e., each file is individually encrypted as a separate item) has its own problems. Notably: the file names are exposed (though this can be mitigated), the file metadata is not authenticated, and the central directory is not authenticated. So sure, you can read that index, but you can't trust it, so what good is it doing? Also, to support incremental updates, you'd either have to keep all the old versions of a file around, or else remove them and end up rewriting most/all of the archive anyway. It's frankly just not a very good format.
> SQLite solves this issue by allowing you to write with page level granularity rather than being forced to dump the whole file for a single tiny change!
Smaller ideas that would address this: add support for non-CBC encryption modes, tweak/disable the compression so that small changes require less rewriting.
Yes actually, I have personally onboarded several people to BitWarden! (Including manually migrating their accounts, setting passwords and passkeys, etc) However, I dislike the centralization and lack of control. There was a paper discussed within the past couple days on HN about what a malicious BitWarden server was capable of, despite BitWarden's marketing. I believe BitWarden's team responded promptly and appropriately to the research.
VaultWarden is a good compromise (offers the choice of SQLite or Postgres under the hood), putting you in charge of the primary server, but it is honestly overkill for a single personal user compared to a kdbx file on a webdav share.
> overkill for a single personal user compared to a kdbx file on a webdav share.
Maybe. I'm looking into VaultWarden for my personal passwords because keeping a KBDX file up to date on iOS is painful (without a corporate cloud backing).
Hey I’m with you here actually. Synctrain on iOS makes it bearable, and actually wakes itself up periodically in the background to do a sync. It’s not as good as it could be, but far better than the alternatives. Otherwise you can spin up WebDAV and direct connect via keepassium. Both work well in my usage.
It's a file in the 10-500kB and passwords are read way more often than added.
If it's even tracked as an implementation issue, it probably ranks very low and fixing this requires a lot of care not to screw up things with the safety and feature rollout.
Exactly. As such, people in the thread with huge dbs have a poor UX when they really do not need to. Also, people who have experienced corruption issues on network storage due to the default saving method (I personally have never experienced this).
I think it also touches on issues of interest to the hn crowd (it's being reported on a YC-incubated platform!), and one especially unique things about the reporting is the spatial reconstruction of the scene, which is not a degree of detail you typically get, and limits the number of variations of interpretations possible.
I also think issues of censorship are very high on the list of topics of interest on HN and few topics are subject to more extensive censorship than reporting on events in Israel and Palestine.
Israel and Palestine is one of the most obsessively covered topics in every form of western media. All the more the reason it doesn’t belong on HN. I’ll grant that there’s a tech angle to this specific story, but past experience with such articles on HN is that they reliably devolve into endless repetition of fixed talking points on each side. No useful information or opinion is conveyed, just endless insinuation and infective.
Furthermore, there are handful of accounts who sole purpose seems to be to pump the HN feed full of Israel and Palestine. People who want so badly to talk about a single political topic should probably go to Bluesky.
I agree that Bluesky is a great place to go into more depth about it, and in many respects a better place than HN to get good discussion. But I think there's equivocation going on here.
Framing it as "obsessive" is an attempt to shift away from subject matter toward an attitude of journalists or consumers, like it's borne of the same attitude as paparazzi. But I think it merits significant coverage not for that reason, but because it so frequently meets criteria for meriting journalistic attention.
I agree that comment sections can be bad, but they aren't always, and to some degree I would rather trust moderation than suppress reporting on a topic of legitimate interest. You're exactly right that a lot of reaction is toxic and politicized, and sometimes the way that manifests is by trying to cook up rationales to suppress stories by flagging them. Out of respect for the concern you've identified, it would be a huge mistake to let politicization win by allowing politically motivated abuse of flagging.
reply