[HN Gopher] Show HN: Working on a Zero-Knowledge Daily Journalin...
___________________________________________________________________
Show HN: Working on a Zero-Knowledge Daily Journaling App
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.
Author : tony_codes
Score : 82 points
Date : 2023-01-31 14:41 UTC (8 hours ago)
(HTM) web link (jumblejournal.org)
(TXT) w3m dump (jumblejournal.org)
| The_Colonel wrote:
| 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.
| olah_1 wrote:
| > 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.
| lucideer wrote:
| 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.
| The_Colonel wrote:
| 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?
| tony_codes wrote:
| 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.
| ilc wrote:
| We've seen how well the library dependencies thing works...
| alas. Now imagine an actor, who makes malware, where the
| crash isn't visible. :/
| jckahn wrote:
| These are great points. "Zero trust" is only really possible on
| FOSS self-hosted systems.
| WJW wrote:
| 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.
| jl6 wrote:
| 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.
| The_Colonel wrote:
| 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)
| bluelightning2k wrote:
| 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.
| The_Colonel wrote:
| 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.
| kvdveer wrote:
| 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.
| samiam_iam wrote:
| [dead]
| gejose wrote:
| 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...
| hackernewds wrote:
| why do people propose their own competing product in a post
| discussing another. IMO it's in poor form
| elicash wrote:
| 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.
| moserch wrote:
| This is really cool. I love the yearly views. Are you going to
| make an app too?
| thalassophobia wrote:
| 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!
| tony_codes wrote:
| yes agree, thanks! The white paper is here
| https://docs.google.com/document/d/1T0SEj5WrymfyzNDD8rNGKQ2O...
| need to add to landing page
| ThePhysicist wrote:
| 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.
| matijash wrote:
| nicely done! I like how I get warnings for password not being
| strong enough. What did you build it with?
| tony_codes wrote:
| Built with serverless tools on the backend. AWS Lambda, dynamo,
| S3. ReactJs SPA for frontend.
| SakiWatanabe wrote:
| Why not just use Day One, it is already end to end encrypted.
| dewey wrote:
| 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...
| moneywoes wrote:
| The front end is beautiful, how did you build it?
| frankfrank13 wrote:
| already locked myself out lol
| Semaphor wrote:
| 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.
| addandsubtract wrote:
| 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)
| anned20 wrote:
| 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.
| petesergeant wrote:
| 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.
| soiler wrote:
| 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_.
| ravishi wrote:
| 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.
| Random_Person wrote:
| 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.
| bbor wrote:
| 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
| i_like_pie wrote:
| 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?
| ravishi wrote:
| 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.
| soiler wrote:
| 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.
| rpgbr wrote:
| 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.
| tony_codes wrote:
| 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.
| powerset wrote:
| 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!
| jrib wrote:
| 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.
| hackernewds wrote:
| this is the way
| jakelazaroff wrote:
| 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.
| Aaronstotle wrote:
| This is cool!
|
| I noticed you accept bitcoin, will you accept Monero as well?
| jcutrell wrote:
| 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.
| SeanAnderson wrote:
| Zero knowledge here means client side only not zero knowledge
| proof, correct?
| js8 wrote:
| 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.
| baby wrote:
| Yeah this doesnt seem to have anything to do with zero
| knowledge besides reusing the keywords because it's trendy
| marban wrote:
| Day One just announced a Web version.
| low_tech_punk wrote:
| 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?
| avinassh wrote:
| what does Zero-knowledge mean and how it is different from end to
| end encrypted?
| thewataccount wrote:
| Yes, everyone started miss-using zero knowledge when they mean
| E2EE.
|
| Including several password managers and companies I hoped would
| have known better.
| tony_codes wrote:
| 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.
| cracked-behem wrote:
| Aren't the engineers controlling the backend also controlling
| the frontend? What's stopping the frontend from exfiltrating
| the encryption keys?
| baby wrote:
| 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.
| miqueturner wrote:
| 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))
| low_tech_punk wrote:
| In case anyone wonders, the illustrations are done by
| https://absurd.design/
| tony_codes wrote:
| ah yes, thanks for posting that
| turnsout wrote:
| 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?
| sam1r wrote:
| This is awesome. It reminds me of 750words.con
| pranabgohain wrote:
| Very neat! Congrats. KloudMate seems like the right tool for you
| to implement observability for your serverless application :D
| scifibestfi wrote:
| > "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?
| [deleted]
| jrm4 wrote:
| What about this necessitates "on the internet?"
|
| Just do it offline, there's your zero-knowledge.
| matt_s wrote:
| What problem is zero-knowledge solving and why does that matter
| for a daily writing journal?
| tony_codes wrote:
| some users hesitate to journal due to privacy concerns
| Janymos wrote:
| 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
| [deleted]
| shahahmed wrote:
| noticed that the page doesn't scroll outside of the center
| container, which feels a little buggy.
___________________________________________________________________
(page generated 2023-01-31 23:02 UTC)