> Devising a new schema based on SQLite would allow for current features that are being jerry-rigged into the attributes to have their own real place in the database
Perfectly possible with XML too
> An SQLite based store is one of the most tested and optimal formats for document and application storage
It's optimized for things that largely don't matter for password storage. The testing is admirable, but there's no issue of keepass clients crashing or corrupting data so again, not very relevant (probably because of low concurrency, simple writes etc).
> A switch this big is a major chance to fix the governance structure and align it more with a democratic consortium than a benevolent-dictator-for-life style of project management
You don't need a technical change to solve this. In fact, a fork that would fracture clients is the last thing you need when making governance changes.
> So many quality of life features can be added where the old schema disallowed it
All of the features they list can be achieved with an XML format. The format isn't what's holding them back.
Not a problem for XML per se (you can work with byte positions, and with fixed-size blocks to avoid resizing/relocation), but in the case of KDBX there is the issue that it is encrypted as a whole. Not encrypting as a whole, on the other hand, risks leaking more information about the contents, like you can see which parts/how much changed between one update and the next.
Whole-file encryption with authentication is also more tamper-resistant. Basically the only thing an adversary can get away with there is rolling back the entire file to a previous version.
Whereas, any incrementally encrypted format has the additional risk of piecewise manipulations. For example, while SQLCipher authenticates each page, it doesn't authenticate the entire file, allowing for pages to be deleted, reordered, or duplicated (though duplication is easy to detect since each page has its own IV). The end result will generally just be a corrupted database, which will probably get detected by PRAGMA integrity_check, but compared to KDBX, this will not be detected by default nor is it guaranteed to be detectable at all.
Another in place option is AES-encrypted ZIP. ZIP has the benefits that the Directory at the end of the file can also include piecewise metadata for full file validation.
A part of me wonders if the only real upgrade needed for the next "large file" KDBX relative format is from a GZIP stream of the XML plus attachments to a ZIP container of the XML with attachments in some folder structure combined with the choice of a good piecewise (modern) encryption for the ZIP container. (That is taking more cues from 7zip than from classic, now broken password-encrypted ZIP files.)
(Though as someone who tries to keep my KDBX files small, I think I'd still prefer the option of a whole-file encrypted format.)
I actually prefer this. It's how most user-facing file formats work. KDBX in particular is often used in conjunction with syncing software, and I don't want a half changed file to sync and then the connection to be lost. The usual paradigm of "write new file then move and replace over old file" works more safely for atomic changes.
I don't know if this could count as "corrupting": I made the mistake of syncing my keepassxc database to my macbook with finder webdav client (nextcloud backend) it read the file alright but when I tried to write a new secret it helpfully wrote an empty file in place, wiping nextcloud file versions in the process.
Thankfully, Nextcloud was smart enough to move the previous file in the trash bin and I could restore it.
It seems keepassxc "save" procedure here was to delete the old file and replace it with a new one and something went catastrophically wrong in the process ?
Looking at the settings there's is a parameter for this method for particular circumstances but I didn't enable it back then. Now I just have a second database only on this mac synced to icloud and never letting it near my nextcloud again.
I actually had a similar thing happen with gvfs-fuse (Google drive). It was a bug in gvfs using the quota usage of a file as it's file size (because libgdata didn't provide a method to get file size), but I was using a file shared to me so it had zero quota usage.
All of which is to say I would bet on something in the webdav-nextcloud line being at fault instead of keepassxc.
I sync'd this file using various means on different platforms, nextcloud apps on windows using virtual files and android with Storage Access Framework cloud integration, and on linux with rclone and somehow never had such a catastrophic issue
This seems to include cement works and other processing plants that have somewhat mine-like output but aren't actually extracting anything from the ground at that site.
> I also avoid it because I'm concerned about being over-reliant on google (what if they close my account?)
Most if the "sign-in with google" accounts I have seen treat it as a shortcut to creating and logging in with an account with the primary email address of the Google account. So you can hit "reset password" and get a conventional password log-in to an account you previously made with the Google auth. If you get locked out of google, it's NBD.
Of course, this is probably not universally the case.
I use the online versions, e.g. https://www.gnu.org/software/make/manual/html_node/index.htm.... In this form they are pretty good documentation (although that is usually due to being comprehensive and adequately written, nothing really to do with info beyond supporting adequate structure).
> Not long before I arrived in the Bay Area, I’d been involved in a minor but intense dispute with the rationalist community over a piece of fiction I’d written that I’d failed to properly label as fiction
Anyone familiar with what work this is referring to?
In general long meandering semi-factual pieces like this, with odd historical excursions, are one of his things and I don't know anyone else that does it quite the same. (Hmm... oddly enough Scott Alexander, who he cites here, also does some similarly Borgesian stuff, but with a different bent.) One of my favorite writers and I recommend pretty much everything he's done since the early 2010s.
> Compared to non-/occasional drinking (≤1 g/day), light/moderate drinking (up to 2 drinks/day) was associated with a decreased risk of CRC (OR: 0.92, 95% CI: 0.88–0.98, p=0.005), heavy drinking (2–3 drinks/day) was not significantly associated with CRC risk (OR: 1.11, 95% CI: 0.99–1.24, p=0.08), and very heavy drinking (more than 3 drinks/day) was associated with a significant increased risk (OR: 1.25, 95% CI: 1.11–1.40, p<0.001)... These results provide further evidence that there is a J-shaped association between alcohol consumption and CRC risk.
I guess these sites don't bring up drinking because except for very heavy drinking the data says it's not a factor.
> If you shop online and use raw measurements, then it will both fit and be available
The article itself gives numerous reasons why this is not true:
* Patterns are scaled up and down from a single original pattern. However actual bodies do not follow simple scaling. As a result, variation in body size will always result in clothes that fit poorly.
* There is not a universal set of body proportions. The article shows a categorization system with 9 buckets. I suspect women's body's simply have a wider range of shapes than men's leading some men (possibly including you?) to discount this.
* Some brands literally don't stock even the median adult women's size!
In America, any rando can build and fly an ultralight, no pilot license needed, no medical, no mandatory inspection of the ultralight or anything like that. I guess the idea is that 250 lbs (plus pilot) falling from the sky can't do that much damage.
Flight / aerospace is probably one of the worst analogies to use here!
As you say, it is one of the most regulated industries on earth. Versus whatever AI is now - regulated by vibes? Made mass accessible with zero safety or accountability?
It doesn't hold. This is a prototype aircraft that requires no license and that has been mass produced for nearly the entire population of earth to use.
Speaking of which, prototype aircrafts with no license still exists in aviation. I can build a plane in my backyard and fly it legally, so long as it's small enough.
We're already well past wright brothers. We have trillion dollar companies selling LLMs, hundreds of millions of people using chatbots and millions* of OpenClaw agents running.
Talking about regulation now isn't like regulating the wright brothers, it's like regulating lockheed martin.
* Going by moltbook's "AI agent" stat, which might be a bit dubious
> Performance - using the native API bypasses the standard Windows API, thus removing a software layer, speeding things up.
But the article cites no bemchmarks
> Power - some capabilities are not provided by the standard Windows API, but are available with the native API.
Makes sense when you are doing something that needs that power, but that makes more sense as an exception to prefering win32 than a general reason to prefer native.
> Dependencies - using the native API removes dependencies on subsystem DLLs, creating potentially smaller, leaner executables.
Linking win32 is a miniscule cost. (unless you have a benchmark to show me...)
> Flexibility - in the early stages of Windows boot, native applications (those dependent on NtDll.dll only) can execute, while others cannot.
Is Zig being used for such applications? If so, why are the calls that the document says will be kept on win32 not an issue?
Perfectly possible with XML too
> An SQLite based store is one of the most tested and optimal formats for document and application storage
It's optimized for things that largely don't matter for password storage. The testing is admirable, but there's no issue of keepass clients crashing or corrupting data so again, not very relevant (probably because of low concurrency, simple writes etc).
> A switch this big is a major chance to fix the governance structure and align it more with a democratic consortium than a benevolent-dictator-for-life style of project management
You don't need a technical change to solve this. In fact, a fork that would fracture clients is the last thing you need when making governance changes.
> So many quality of life features can be added where the old schema disallowed it
All of the features they list can be achieved with an XML format. The format isn't what's holding them back.
reply