Show HN: Working on a Zero-Knowledge Daily Journaling App (jumblejournal.org)
Decryption key derived from master password never leaves the browser. It's just a text editor so far, but a we have a few features planned: retrospective tooling, sentiment analysis, journaling modules, guidance and information inline, better habit formation & rewards UI.
111 comments
[ 2.9 ms ] story [ 147 ms ] threadAlso, I'm interested if you see an attack vector on the authentication method. One thing to note is that even if an attacker can authenticate successfully they still have no access to the user private data without brute forcing the master password.
What have I learned or gained? It definitely helps ground me in the flow of time. It's so easy to lose weeks or months or years if you're never reflecting. Journaling helps me be more aware day to day.
The greatest tools for me are:
1. When I'm feeling as if I'm stuck I go back sometime (like a week) and confirm that I've indeed progressed.
2. My recollection of events is better just because I'm logging them. If I really want to confirm something I can go back and check. This is specially helpful in day to day issue resolution with my wife, which has been an important topic for us.
3. Sometimes I go back a year or more to just have some memories. It helps me to feel human because I had big troubles with long term memory.
It's one of the things I'm most grateful of doing for so long.
I use the mobile app Pixels for journaling though. It lets the user define custom tags (I track emotions, activities, wake up time, body pains...), which for me is pretty useful, but I would say it also raises the floor on the effort it takes to make an entry, because I don't like to miss data points on those tags. So to the reader: start small, be forgiving, and don't worry about getting good data. 99% of the value of journaling is the practice.
So far just been winging it on a case-by-case basis but curious if there’s a fundamental pattern I’m missing
Another cool thing they have is templates. I use one called "Daily Self", which just asks a bunch of questions about my day: Who did I see? What's my mood like? What are my accomplishments? What did I eat? (I added a couple more questions, what I read and what music I listened to).
Both of these have been effective tools for me. If I have something on my mind, I write about it and don't worry about prompts. If the daily prompt interests me, I'll answer it. And if there's nothing else, I just open the Daily Self template and write about my day.
Built it late last year to build the habit of writing out my thoughts.
* iOS: https://apps.apple.com/us/app/a-journal-a-day/id1659288235 * Android: https://play.google.com/store/apps/details?id=com.georgejose...
I agree it feels tacky, but on the other hand as a reader, I prefer knowing about alternatives.
The other thing -- and it doesn't apply in this specific case -- is that often knowing about competitors helps clarify what's unique about the original linked post. It's a thing I see on HN a lot: Marko got posted, somewhat says it looks like Svelte syntax, then somebody replies to that and says the Marko is much more performant.
Normal app: Both user and application know what they are doing.
User-friendly app: User doesn't know what they're doing, luckily, the app does.
Zero-knowledge app: Neither the application nor the user know what they are doing.
More info on https://en.m.wikipedia.org/wiki/Zero-knowledge_proof
I have a feeling that this is not zero knowledge and we’re all getting bamboozled.
Including several password managers and companies I hoped would have known better.
* most consumers have no idea what you're talking about / don't care
* those who know what "zero trust" is, also know that it's not really trustless. You do have to trust the company that it will never send the password or plaintext data back to the server. Checking this on a continuous basis is essentially impossible, a rogue update can be pushed anytime. The amount of trust you need to put into the company is not dramatically different from a normal setup. I think psychologically it's also a bit self-defeating - promoting zero-trust aspect somehow suggests that customers shouldn't trust you.
* the design is a major pain, since you never know what surprises await you in the customer's data (data tends to rot). Data migration to a newer version is a pain since you can migrate only when the user logs in, which can be years later (in effect you need to keep backwards compatibility forever). Debugging such customer migration problems blindly is hell.
* there will be useful features which you won't be able to implement without violating the zero knowledge principle. Chances are that many users would place a higher value on those features rather than on the zero knowledge aspect.
If you really want to decrypt/encrypt on the client, then try to minimize them - no encrypted structures, just encrypted text / images / whatever payload. Metadata, keys etc. can remain plaintext and thus accessible for your maintenance needs.
True users must trust the developers to not make a rogue update, but in practice I think it works fine. We also trust library dependencies to not push a rogue minor update that will crash our site or do something malicious.
As to your other two points:
- your third bullet amounts to "don't do X because it is difficult"
- your second bullet isn't really true. Zero trust can be trustless in theory, and every effort to make it so moves the dial closer to that ideal. It's entirely conceivable for "effective trustlessness" to be achievable for a decent range of threat models. Sending plainttext/passwords back to the server could be mitigated by a broad selection of approaches: moving the "reproducible / verifiable / signed builds" efforts of native apps into the browser. Components of this are already conceivable with service workers, and with enough demand browsers could easily improve support for related measures.
TL;DR what's easy to do today security-/privacy-wise is easy purely because people continued to work on it when it seemed impossible / not worthwhile. Discouraging these efforts is really poor form.
---
Additionally, worth mentioning that all of the above applies to SaaS, and for open-source self-hostable projects (not applicable here), the reasons to continue working on it are even stronger.
> Zero trust can be trustless in theory, and every effort to make it so moves the dial closer to that ideal.
I agree it can be done in theory, but I don't have a reason to believe the product as of today is truly trustless as it claims on the website.
I also believe that making something truly trustless is impractical for the vast majority of use cases. Reproducible/signed builds are indeed a step in the right direction, but not enough on its own. Each signed build would additionally have to be independently audited by a trusted 3rd party. It doesn't help that the build is signed, if the company itself inserted the password logger. And not having to trust the provider is the point of trustless, isn't it?
Your logic that the app could deploy a "rogue update" so it has little merit would essentially say there is no point in mitigating anything because insert unlikely failure case.
When saying it causes people to trust you less by raising the spectre I disagree. I would assume that a company focused on zero knowledge would also pay attention to other mitigations and related best practices.
Agree with the downsides.
In a classic setup, the client needs to trust that the service provider is not malicious or incompetent either.
The level of trust thats required for a zero-knowledge setup is not fundamentally different from that of a classic setup. Most importantly, the amount of trust required is substantially greater than zero.
I would agree that it's "safer", though, since client-side encryption indeed eliminates several ways how the confidentiality of your data could be compromised.
Essentially it's not really zero trust at all. When I think of zero trust I think of running code locally that is either firewalled or I wrote it myself.
I appreciate that if you _do_ trust them, then this setup is much better as it eliminates the risk of a data leak via compromise, which is all too common these days.
Open source and self hosting is a good start for the paranoid, but definitely not sufficient. As always it comes down to threat models and who/what you are trying to defend against.
This is why I like decentralized apps where you can use a content-addressed frontend that is just pinned to a specific version. I can choose to update to the next major version if I want to.
> a rogue update can be pushed anytime
This is not an intrinsic property of a zero-trust system, but a consequence of a culture in which software is never finished.
Curious what alternative names people have?
https://dayoneapp.com/blog/the-next-chapter-of-day-one-at-au...
I wonder if this would do better as an open source native mobile app?
Browser can scroll and handle scrolling well. Let them do it.
I noticed you accept bitcoin, will you accept Monero as well?
Just do it offline, there's your zero-knowledge.
It's probably just an issue of the right target market. People like me aren't it, but people who are less concerned about such things may very well be. A zero-knowledge implementation is still a great idea to protect them, even if they don't really appreciate the protection they're getting.
By the way, I realize my comments have been critical, so let me say the other side: good work! I wish you all the success in the world. Building and releasing something is a major accomplishment, and anything you make won't be right for everyone. That's not a fault with your product. That's just the fact that different people have different needs.
I agree the primary appeal (and thus market) of this app is not technical, but of course it's still important that the technical aspects are vetted and secure.
Without online, it's in the hands of ONE party. Online, it's in the hands of that same party and at least one more.
Objectively less private.