Show HN: Working on a Zero-Knowledge Daily Journaling App | Hacker News Reader

Show HN: Working on a Zero-Knowledge Daily Journaling App

jumblejournal.org

98 pointstony_codes106 comments

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.

Open articleView on HN

I've worked on 2 "zero-knowledge" apps (basically meaning all data is encrypted/decrypted on the client) and I would advise against it:

* 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.

I agree with the pain points you've highlighted -- but I think certain applications do benefit from zero-knowledge. Password managers for example. In the case of journaling, I think one reason people resist is fear of exposure. I agree though, the challenge is communicating the added security to non-technical users.

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.

We've seen how well the library dependencies thing works... alas. Now imagine an actor, who makes malware, where the crash isn't visible. :/

Two of your arguments (1 and 4) are only narrowly applicable (i.e. you should rephrase to "I would advise against it if your sole goal is a large mainstream growth"), but even in that context, priorities of mainstream consumers have shifted over the decades as a direct result of people developing/failing/retrying building such niche projects, & those projects slowly making their way into mainstream consciousness over time. So I'd never recommend against doing something because the audience is small today.

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.

Yes, most of the points are sort of product-growth related. But given this is a SaaS project, I assume the author has commercial intentions, and thus I hope my 2 cent advice is useful (as mentioned before, I went through two such products already [one was commercial]).

> 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?

While this is very well put, isn't this like saying "people could jump over the safety rail. So there is no point having 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 zero-knowledge setup, the client needs to trust that the setup is actually zero knowledge, and that future updates will not change that. Essentially the client needs to trust in the absence of incompetence or malice.

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.

The problem is in setting wrong expectations. The app is "sold" as trustless - you're told that there's no need to trust the provider, but that's simply not true.

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.

You still need to trust them not to read your data via a client side update, which is similar to trusting them not to read it server side. Client side leaks are easier to verify (as you can trace network traffic) but it's too late at that point.

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.

These are great points. “Zero trust” is only really possible on FOSS self-hosted systems.

And only for developers who have both the time and inclination to vet each update for themselves, updates which (for big systems) may have contributions from hundreds of people and may be in a language that you only know vaguely.

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.

> 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

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.

Your points are all sound, but I want to expand on this one:

> 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.

Agreed, but also more or less inherent property of SaaS. (not in theory, but in practice there's no usable solution to "pin" versions of client code)

I've been journaling for about 15 years now. The big key to getting consistent at it was to stop worrying about trying to write a lot, or trying to write something insightful, and just write a sentence or two at a minimum. Often, that turns into more or into something insightful.

1/ what do you feel like you've learned or gained from this? 2/ do you ever go back and study what you wrote or is it more about giving your thoughts clarity today?

I'm not the OP, but for #2, it's almost all about the latter. Occasionally I go check on random or specific days.

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.

Not OP, but have been journaling for the past 7 years with some pauses in between.

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.

I've been journaling for 20 years and often I open old files to talk to the younger me. It's remarkable how you change over the years, a feeling that, AFAIK, any other medium achieves (maybe video/audio recordings, but text is way simpler to register, storage, and retrieve).

It's one of the things I'm most grateful of doing for so long.

1/ For me it's similar to meditation in terms of the appeal. It's a way to slow down and think, not necessarily for measurable gain but to be a bit more present in the flow of things. I've learned a lot about myself as I do a lot of introspection when writing. 2/ Yes, a major feature I'd like to build is a retrospective flow as I've developed a pretty nice system for going back and pulling out "nuggets" from past entries. Seeing your own thoughts after some time, as a stranger is a really useful tool to understand how your mind works.

this is the way

I've been doing it only for 3 or 4 years, and this 100% lines up with my experience. There are times when I haven't been consistent, and it always comes down to feeling that "I can't do a good job of it right now, maybe later..." and then I miss that day, and miss that week, etc.

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.

I'm glad you pointed out the tags issue. I've been using Daylio for a while now because I like doing little entries throughout my day and I initially set up a bunch of tags. Lately those tags have started to feel like a burden because I worry about missing an entry related to those tags. That burden hasn't become significant yet, but it is something that's bothering me and I could see it be an excuse later on to just give up on the whole thing... i.e. the data junky in me says what's the point of tracking data if the dataset isn't accurate.

I’ve been working on the same thing. Does anyone here have tips on how to filter/mask a given time-based data set so that it infers data where possible (i.e. if I logged one mood for the day, it’s probably safe to map that across the whole day) and ignore unrealistic data (I.e. if I logged one meal for the day, that’s probably not a useful day of data).

So far just been winging it on a case-by-case basis but curious if there’s a fundamental pattern I’m missing

My current solution is to write many times a day (each hour when possible). Write short sentences with key information and then move on. Sometimes I'll edit some old entries to remove details and reduce length. The best part is that "key information" also changes, so it also ends up reflecting what was important to me at the time.

Interesting, haven't heard this approach before.

interesting; I benefited from the opposite, which was having a goal of filling one page. This acted as a sort of reward and feeling of accomplishment. But also found any expectations on quality tend to deter me.

Having some sort of prompt helps, too, to keep up the habit. I use Day One, and they have a prompt that changes daily; today's is "What is something I want to do for myself in the coming year?" One of my favorites is "Describe something you learned from your mother" which is absolutely not something I would have thought to write about unprompted.

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.

Thanks for the advice, yeah I'd like to add guided journaling modules and some optional prompts. Just knowing where to get started helps a lot with journaling

I agree. I built a journaling habit by scheduling time for it every week. Sometimes I just don't feel like it and scribble something down. But sometimes even when I start with just a scribble, I keep going and it helps me to think through thoughts in my head.

The thing that finally got me into journaling was becoming obsessed with fountain pens and stationary. So I journal as an excuse to use my fun pens and ink and paper, and as a nice side effect I actually get some useful journaling done!

Can't find any info about journal encryption on the website itself. Perhaps there should be a page dedicated to explaining how your data is protected. Otherwise great stuff!

yes agree, thanks! The white paper is here https://docs.google.com/document/d/1T0SEj5WrymfyzNDD8rNGKQ2O... need to add to landing page

SHA-256 is not suited to derive key material from weak input data, you should use PBKDF2 or another key derivation function for that. The authentication method also seems pretty wonky, that's not how to do zero-knowledge password verification, you should look at methods like PAKE for that. As usual, just don't roll your own crypto if you don't know what you're doing.

Thanks for the feedback! The hash is actually used to derive an actual key using PBKDF2 -- the library used is https://cryptojs.gitbook.io/docs/

Also, 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.

It feels like the Venn diagram of 1) people who know what "Zero Knowledge" is and 2) would be willing to create an account on a web service to store their writing… would look like two circles that don't touch.

I wonder if this would do better as an open source native mobile app?

On desktop, I can only scroll the middle section of the site. If I hover anywhere on the side margin and try to scroll, nothing happens. (Firefox, macOS)

Came here to say this, it really messed with my mind for a second. I'm using Brave on macOS, so it's not browser related.

just deployed a fix for this; if you see this and happen to check let me know if it's better :)

If I can offer some unsolicited feedback:

  - This space is very crowded - to consider this app, I need to know a differentiator much sooner. Is it the streak? Is it the zero-knowledge? What makes this different from the 20 other options? It seems like the value prop here is "this is a simple journal that tracks whether you wrote today or not, and that is zero knowledge." If there's more, it's missing from the marketing here.
  - There's some confusion in the branding. You're using the word "guru", as well as the word "jumble" as a verb. Pick a tagline and a CTA, and stick to those.
  - I like the point you are trying to make about the value of writing itself... but how does your app take advantage of that value prop? Can I capture those insights in a unique way? Otherwise, I can take your value prop and accomplish it in the writing app I already have an account and history with.

I think you're on the way to something good here, but it's a little too confusing to get me to convert.

Thanks a lot, this is really useful feedback. I completely agree the landing page branding needs some work. I've recently done some workshops to get some clarity on target audience and will try to tighten this up.

Currently the app is light on features so indeed it does not differentiate well, but we will build out a retrospective flow which is unique and helps users find actionable insights from past entries, and explore their best ideas on specific topics over time.

For the love of anything, please stop messing with the scrollbar. Not only (as two others mentioned) does scrolling only work on part of the screen, it also moves at a completely different speed than what I have set up, and hides the scrollbar.

Browser can scroll and handle scrolling well. Let them do it.

Sorry for that; I'm a backend engineer; still learning some of the frontend best practices. I just deployed a fix for this; if you see this and happen to check let me know if it's better :)

Looks nice! I have been using empty git commit messages for journaling in the past few months and found that I'm more willing to journal in the command line with this git-abuse than most applications specifically designed for journaling. Don't know if anyone else has tried this

In case anyone wonders, the illustrations are done by https://absurd.design/

ah yes, thanks for posting that

Shameless plug for my own password protected daily journal app where all your data stays on your device!

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...

why do people propose their own competing product in a post discussing another. IMO it's in poor form

Because people reading the comments, who like the concept, may find it useful.

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.

What about this necessitates "on the internet?"

Just do it offline, there's your zero-knowledge.

one benefit of online is privacy. I've talked to many people that really don't like having a physical journal laying around with personal information that a partner might read. But yeah, I get there are workaround to that problem and not everyone has this kind of privacy issue

"Privacy" and "online" don't go well together, though. Talking about "zero-knowledge" doesn't really address the issue, because there is no way of knowing if the author is being honest, or if they've implemented it correctly.

Maybe zero-knowledge should be open sourced, built from source by users as a desktop app (so they can lock to a version), and each version should be stamped (hash of specific version signed) by trusted 3rd party penetration testing agency -- it does limit the reach of the product though

It's a tough problem. An application like this is all about convenience. Having to vet the source and build it yourself brings a lot of inconvenience.

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.

Thanks a lot for the encouragement; but also I really appreciate the honest feedback, it wouldn't be hacker news if people stopped being honest, it's why we all love the conversations here.

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.

No. No it is not. I'm sorry, this is just objectively wrong, and I don't mean to pick on you personally, but I do think it needs to be said.

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.

You are right, I get what you are saying. But I guess I'm speaking more from a user perspective. Some people have told me they can't write down private things in a physical journal; as someone they are living with can easily pick it up and read it. In theory, a digital copy can be secured with more confidence than a physical copy ... for example by encrypting things with a key that you're confident only you have access to. I think I should have said that one benefit of "digital" is the potential for increased security ... online is clearly not the case.

and it's completely ok, I love hacker news because it's one of the more honest places on the internet.

Zero knowledge here means client side only not zero knowledge proof, correct?

It means progress:

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.

Yeah this doesnt seem to have anything to do with zero knowledge besides reusing the keywords because it’s trendy

the decryption key never leaves the browser. Maybe it's not perfect, but I'm not using the keywords because it's trendy, this project started out of an interest in more secure authentication and data security.

But zero knowledge cryptography has nothing to do with that. Sorry I was a bit harsh, I guess I got tripped by the misuse there.

it's ok, it's hacker news so I expected honesty which I appreciate. But What would you call an authentication mechanism which never passes the decryption key off the browser? It's an improvement over systems that handle the keys themselves on the server side.

I'm not sure, I would call that encrypted storage perhaps? Or client-side encryption

yeah, perhaps client-side encryption or User encryption ownership or something along those lines. To me, "encrypted storage" doesn't sound like anything different that what is done with normal authentication methods.

what does Zero-knowledge mean and how it is different from end to end encrypted?

The main thing is that the encryption keys never leave the browser. So even an engineer in control of the backend cannot see the information being saved. With E2E encryption the owner of the data usually also handles the decryption keys.

Aren't the engineers controlling the backend also controlling the frontend? What's stopping the frontend from exfiltrating the encryption keys?

Zero knowledge means that you can convince someone that you know something without showing them that something.

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.

Yes, everyone started miss-using zero knowledge when they mean E2EE.

Including several password managers and companies I hoped would have known better.

> "A good writer doesn't just think, and then write down what they thought, as a sort of transcript. A good writer will almost always discover new things in the process of writing. And there is, as far as I know, no substitute for this kind of discovery." -Paul Graham

What is it about writing that makes it different than thinking?

writing is a tool to help us think. Since we have limited active memory to think with, the words act like storage which helps organise thoughts and cover more ground

On a marketing tangent, I wish the security practitioners had names better than "zero-knowledge" and "trustless". To an average person, they really make the system sound dumb and dubious despite them being beneficial.

Curious what alternative names people have?

I dont actually think this product is finished. It has a buggy interface, specifically the tag and search for tag functions don't seem to work from my Macintosh 12.0.1 (Monterey) using Chrome (Version 109.0.5414.119 (Official Build) (x86_64))

This is really cool. I love the yearly views. Are you going to make an app too?

probably not in the near term, I want to make the webapp work well on mobile and encourage users to employ a keyboard when journaling

Hell yeaaaahhh! Finally something like this came up! Ooh yeah babbbyyyy

This is cool!

I noticed you accept bitcoin, will you accept Monero as well?

Just bitcoin for us :)

The front end is beautiful, how did you build it?

thank you! It's an SPA build with React

Very neat! Congrats. KloudMate seems like the right tool for you to implement observability for your serverless application :D

Looks really interesting. Are you affiliated? I will check it out.

looks very slick! are you planning to do the typical SAAS route with this? or is it actually free forever?

It would go the SAAS route if enough people find it useful; if there are consistent users I can't afford to make it free forever unfortunately

noticed that the page doesn't scroll outside of the center container, which feels a little buggy.

I just deployed a fix for this; if you see this and happen to check let me know if it's better :)

What problem is zero-knowledge solving and why does that matter for a daily writing journal?

some users hesitate to journal due to privacy concerns

I don't have "past my entry". Can't writing(泣)

Why does this have to be cloud-based at all?

same reason for anything cloud based. Sync between accounts, take the responsibility of data storage off the user.

This is awesome. It reminds me of 750words.con

nicely done! I like how I get warnings for password not being strong enough. What did you build it with?

Built with serverless tools on the backend. AWS Lambda, dynamo, S3. ReactJs SPA for frontend.

Day One just announced a Web version.

Interesting, seems the web app space is continuing to encroach on apps as they two converge.

already locked myself out lol

whoops, I can delete your account if you want to create a new one with the same login, just let me know.

please do! Love the tool

can you ping me at support@jumblejournal.org ? let me know the login to be deleted

Why not just use Day One, it is already end to end encrypted.

I only recently started using Day One and was always a bit worried that it's some random company but turns out they got aquired by Automaticc (Wordpress, Tumblr) which made me feel a lot better about the decision.

https://dayoneapp.com/blog/the-next-chapter-of-day-one-at-au...

We will build some unique functionality that is different from the value proposition at DayOne

Reply on news.ycombinator.com