Genuinely how are you supposed to make sure that none of the software you have on your system pulls this in?
It’s things like this that make me want to swap to Qubes permanently, simply as to not have my password manager in the same context as compiling software ever.
My router doesn’t have a WPS button, so I also had to use the two button interface. Not fun having to cycle through some 50 plus ASCII characters for the WiFi password. I’m pretty sure you can emulate the button press in openwrt with some package though. It was faster to just enter the password than to figure all that out.
I just use HN as my comment platform. I have a Hugo short code that (very respectfully!) grabs the comments on a full rebuild, but only if those comments are not already cached and if the post is less than 7 days old. The formatting looks quite good on my site. Feel free to check it out at the bottom of this post: https://mketab.org/blog/sqlite_kdbx
For sure, but these LARP situations are mostly based on defending against a highly motivated and powerful entity like the government.
But other situations like against thievery, domestic abuse, or brute force deterrent (ie: setting a simple duress code that is likely to be triggered, say 1111), it has the potential to work well.
Graphene brings out some of the best of android. Profiles are first class citizens, private spaces within the owner profile (I think all profiles can have them now?), and app pinning are great.
The main critique I’ve seen of the duress pin is that it causes undue trouble. The obvious counter argument is that if you genuinely have the need for a duress pin, it’s worth its weight in gold. If the severity of the charge or physical punishment (in countries without due process) would in any way be less by NOT having xyz data on your phone, then it’s helped. Say, the difference between 10 years for destruction of evidence and 80 years for espionage.
The web server that powers fossil was also written by its author! It’s nice that unlike git instaweb you don’t need to install an additional web server just to see a read only view of your commits.
I use Fossil for all of my long term projects. It can even import Git repositories if you want to try it out.
Today I was working on a semester paper for a non-technical class. It is versioned in fossil and I have all my miscellaneous ideas, initial outline, and the paper guidelines in the Wiki. The branching also makes much more sense, and I’ve used it for major revisions of the paper or its structure.
Fossil is legitimately awesome, and I lament the fact that Git gained popularity over it.
Fossil itself is a C binary, not a database. Maybe they meant that Fossil’s source code is hosted in Fossil, or that Fossil repositories are SQLite files? I don’t exactly know either.
Well, the masses are wrong. See: insane amounts of compute wasted on “thank you”, “haha true”, “redo it”, etc. I think the UI should be designed to avoid misuse, and I think an ever growing distillation of your most common traits is not a good use of context length. If you want it, specify it. Maybe even hard limits on chat length, why are we 20 replies deep in a single chat? A user friendly option could be a single button that distills that chat down, and opens a new one with prebuilt instructions to continue the conversation. I’m no product designer though, just some thoughts.
Gemini’s web UI and mobile app are horrible. Gemini outputs malformed links that lead BACK to gemini.google.com. There are constant bugs with the side panel not showing your chats or the current chat timing out for no reason. Also, the mobile app has an issue if your text input is too long where the entire text entry box lags, even to the point of locking up the entire app. Openrouter’s web ui runs circles around all the frontier lab UIs. I even prefer their PWA to any of these mobile apps.
I see what you mean, but I like having a clean slate even for those one off questions. I don’t want a differing answer to a philosophical inquiry just because the LLM remembers a prior position I’ve written about you know?
This seems to imply that customers assume by default that the LLM remembers their past chats? I feel like the UI makes it incredibly obvious it’s a clean slate every time? But then again people ask ridiculous meta questions all the time to these chatbots expecting a correct answer.
Could someone explain the appeal of account-wide memory to me? Anthropic’s marketing indicates that nothing bleeds over, but I’m just so protective of my context that I cannot imagine having even a majorly distilled version of my other chats and preferences having on weight on the output. As for certain preferences like code styling or response length, these are all fit for custom instructions, with more detailed things in Skills. Ultimately like many things in LLM web UX, it seems to cater to how the masses use these tools.
Detection methods only serve to stop the most blatant, low effort kind of LLM responses. The more pressing issue is that people are reading LLM output, and paraphrasing it for their assignments, reports, emails, etc. The obvious problem being that LLMs are often wrong, or miss nuance in unnoticeable ways for the laymen. The secondary problem is the general outsourcing of thinking and effort, even for tasks that you ought to give your focus to. BTW: from my anecdata, most university students are absolutely violating academic integrity with these tools, and have completely lost the ability to engage without them.
This is a nice, refreshing post. Not everything has to be a big deal all the time. Also, there’s a LOT you can do at build time in terms of dynamic content for a simple static site. On my blog it actually renders the HN comments at the end of my post! I took proper care to make sure rapid iteration did not hit the API every refresh (comments are cached for an hour) and it’s also completely free. Obviously truly dynamic things will require a backend, but my needs are super minimal.
Nope, I meant VeraCrypt. As I assumed you meant splitting attachments into their own BLOB. This means you would have the KDBX file, then the attachment blob. I’m saying that you might as well use a purpose built encryption container tool.
As for the protocol my main argument is that passing around a file with dumb syncing is always going to have issues. The only real way to mediate it is to have a defined schema and standardized sync protocol between keepass clients. This would make them behave more like a centralized password manager. However, this approach would require some sort of relay infrastructure and just ends up emulating syncthing but for application specific data rather than simple files. It’s far out of scope for KeePass IMO to build a p2p sync protocol.
Editing this comment because a user in this thread actually acknowledges this point:
> Solving sync and sharing cannot be done on whole database file level, as it implemented now in KeePass. Changes need to be tracked at the password record level, all changes need to persisted as operations log and that log needs to be distributed across devices.
It’s more of a purist attitude on my end for sure. I cannot stand the idea of storing a PDF and all its bloat for a single paragraph of information that could easily fit into an entry note. Vendor PDFs are also sometimes ridiculously unoptimized too. Even for a modest 500kb PDF, that’s still like a couple hundred plaintext entries that could have taken its spot.
Splitting the file into pieces is certainly not the right way to go about it though, as you would just be poorly emulating VeraCrypt! The most robust sync solution is an actual protocol (like Bitwarden), otherwise dumb file syncing is going to have the same issues it usually has.
This class of mistake could have been wholly avoided if the format was SQLite based because there is no assumption that everything must be loaded into memory. Of course I defer expertise to you, but I've had a far better time with SQLite than I've ever had with XML parsing (OFX/QBO still bother me...)
I really appreciate your commentary here! I understand that SQLite would not automatically solve the politics issue. As ctoth mentioned, it would serve as a "flag day" for the KeePass community to hopefully cover everyone's bases in a formal manner. Schema versioning and evolution is way more up SQLite's alley. An SQLite schema has referential integrity which an XML schema lacks, making it harder to misuse and contort. It is also far simpler to modify a query in the event passkey storage need to be changed than it is to modify the parser.
The lower barrier to entry probably also reduces the number of catastrophic parsing mistakes a developer can make. This is a net positive gain for the wider ecosystem of external tools which do not have to re-implement the whole parser. Every language has a great SQLite library, the same cannot be said of KDBX.
Good to see you in here! You make a great point, historically the breaking changes have not really affected users. You kept your db as is, and it would get migrated if you wanted to use new features. A friendly warning on open with a prompt to migrate to unlock new features (after gaining ecosystem traction) would be reassuring to users. On a more technical note, is there anything on your end with KeePassium that would be greatly improved, especially regarding potential improvements to auto-fill memory usage?
KeePass is for sure better suited for this usecase. There is far less to keep track of, and the unlock mechanism and data are tied together. I've also had inexplicable issues migrating GPG keys cross-platform to where I just do not bother anymore. Ssh/age/minisign just work for my use cases.
I think a relational DB is the best tool for the job!
I argue more for the use case of "secrets manager" than solely password manager. People store TOTP seeds and Passkeys and a myriad attachments. A SQLite store would better facilitate this, as not everything has to be in memory all the time. This is only with regard to the size constraint, there are so many other benefits to be had from a formal specification of the schema to truly future-proof the standard.
I really doubt it. I have not seen any evidence to suggest that there are irreconcilable issues with SQLCipher's page level encryption over a flat file. Codebook, Enpass, Signal, and a ton of other important clients use it just fine.
Note to self is quite a bit more ephemeral in practice than keeping it in your kdbx file. Any number of things could cause you to lose your chats with Signal.
Attributes are meant to be user facing, and are super useful for all the assorted info that you can use during autofill steps. I primarily use this to autofill card information with autotype.
Cryptomator checks all the requirements. It is a cross platform, GPL'd, encrypted overlay filesystem which you can put anything in, not just markdown docs. Just unlock it and point your notes app to it. Lock when done.