Show HN: Hush Docs – private Google Docs alternative that works without internet(demo.hushdocs.com)
demo.hushdocs.com
Show HN: Hush Docs – private Google Docs alternative that works without internet
https://demo.hushdocs.com
15 comments
For starters, I think the number 1 most important thing is open sourcing code. Everyone should be able to read the entirety of the software's code themselves, verify the claim, build the app from source, and run it locally if desired. Unfortunately not everyone will have the skill to do this, so many will likely have to resort to trust in others to do this verification for them.
Given that this code also runs on a website, you have to trust that the code loaded from the website is the same as the source. Notice this statement I also added in there: "Please be aware: if someone evil... takes control of hushdocs.com, they can access your docs!"
There are some ways to mitigate this:
1. I could offer a native downloadable version of this site, and you can verify the downloaded file's integrity using a hash and signature.
2. I could add a service worker to the site such that after the website loads the first time, you have to manually allow a new version of the site (that would also be signed by me) to load and run in your browser. Check out this blog post for ideas on how to go about this: https://blog.airborn.io/post/2017/08/03/Transparent-Web-Apps...
3. I could host the static site on IPFS and you could rely on a browser extension to ensure the correct site loads, described here: https://blog.cloudflare.com/e2e-integrity/
But at the end of the day, to really verify the claim yourself, you have to be able to read and build the software from source yourself. Otherwise, yep, you are trusting that I'm giving you code that's doing what I say it's doing.
Given that this code also runs on a website, you have to trust that the code loaded from the website is the same as the source. Notice this statement I also added in there: "Please be aware: if someone evil... takes control of hushdocs.com, they can access your docs!"
There are some ways to mitigate this:
1. I could offer a native downloadable version of this site, and you can verify the downloaded file's integrity using a hash and signature.
2. I could add a service worker to the site such that after the website loads the first time, you have to manually allow a new version of the site (that would also be signed by me) to load and run in your browser. Check out this blog post for ideas on how to go about this: https://blog.airborn.io/post/2017/08/03/Transparent-Web-Apps...
3. I could host the static site on IPFS and you could rely on a browser extension to ensure the correct site loads, described here: https://blog.cloudflare.com/e2e-integrity/
But at the end of the day, to really verify the claim yourself, you have to be able to read and build the software from source yourself. Otherwise, yep, you are trusting that I'm giving you code that's doing what I say it's doing.
A security researcher can typically verify this claim to a fairly high degree of certainty without too much difficulty.
The problem is that at any point the code might change, and unless a security researcher is checking every version, they won't find it. Also, there is no guarantee all users run the same code...
The problem is that at any point the code might change, and unless a security researcher is checking every version, they won't find it. Also, there is no guarantee all users run the same code...
I don’t mean to be overly glib, and I get that this is intended as a collaborative-first tool, but:
Why not just use an offline-first format like docx (collaborative: comments and track changes), synced with Dropbox or similar (sync across devices)?
Why not just use an offline-first format like docx (collaborative: comments and track changes), synced with Dropbox or similar (sync across devices)?
No worries, good question :)
For one, conflict merging sounds like it could be a nightmare with that approach. Like imagine you have 10 people working on a doc at the same time, and they each have different versions. Hush Docs takes care of keeping a doc in sync out of the box.
For two, real-time collaboration isn't possible with that approach.
For three, it's end-to-end encrypted if you care about that sorta thing.
Also just a note, comments and change tracking could be implemented pretty easily if there's interest. I spent like a week and a half on this, it's pretty barebones.
For one, conflict merging sounds like it could be a nightmare with that approach. Like imagine you have 10 people working on a doc at the same time, and they each have different versions. Hush Docs takes care of keeping a doc in sync out of the box.
For two, real-time collaboration isn't possible with that approach.
For three, it's end-to-end encrypted if you care about that sorta thing.
Also just a note, comments and change tracking could be implemented pretty easily if there's interest. I spent like a week and a half on this, it's pretty barebones.
Hi HN,
Hush Docs is an offline-first, private Google Docs alternative. You can turn off your internet and the site works totally fine. Your docs are stored in your browser (using IndexedDB/Dexie.js), so you can create and edit your docs whenever you want, no internet or account needed. If you decide you want to sync across devices - or collaborate with others on a doc - you can create an account (which you do need internet for). Your docs are then end-to-end encrypted, so no server ever has access to your plaintext docs! Docs stay in sync using CRDTs (Automerge) - collaboration should be smooth even if someone works on a doc while offline for a while (like on an airplane with no wifi). Code is 100% open source. [1]
I decided to create this because someone asked for a tutorial on how to create offline-first apps using Userbase, which is a developer tool I’ve helped work on to make it easy to create secure and private apps [2][3][4]. I started out with a super basic tutorial, and then one thing led to the next and ya know: Hush Docs. A basic tutorial on how to build something like Hush Docs with Userbase is coming! [5]
Hush Docs is super barebones, so I’m calling it a "demo." If there's serious interest, I’d happily put more time into it and get it into something more production ready.
For reference, here are a couple other sweet E2E encrypted Google Docs alternatives I came across while scoping this out:
https://cryptpad.fr
https://www.airborn.io/
Airborn did something especially cool worth pointing out: they used a service worker to guarantee that code loaded into the browser came from the latest GitHub commit. [6]
[1] https://github.com/j-berman/hush-docs
[2] https://userbase.com
[3] https://news.ycombinator.com/item?id=22145168
[4] https://news.ycombinator.com/item?id=25869472
[5] https://userbase.com/docs/
[6] https://blog.airborn.io/post/2017/08/03/Transparent-Web-Apps...
Hush Docs is an offline-first, private Google Docs alternative. You can turn off your internet and the site works totally fine. Your docs are stored in your browser (using IndexedDB/Dexie.js), so you can create and edit your docs whenever you want, no internet or account needed. If you decide you want to sync across devices - or collaborate with others on a doc - you can create an account (which you do need internet for). Your docs are then end-to-end encrypted, so no server ever has access to your plaintext docs! Docs stay in sync using CRDTs (Automerge) - collaboration should be smooth even if someone works on a doc while offline for a while (like on an airplane with no wifi). Code is 100% open source. [1]
I decided to create this because someone asked for a tutorial on how to create offline-first apps using Userbase, which is a developer tool I’ve helped work on to make it easy to create secure and private apps [2][3][4]. I started out with a super basic tutorial, and then one thing led to the next and ya know: Hush Docs. A basic tutorial on how to build something like Hush Docs with Userbase is coming! [5]
Hush Docs is super barebones, so I’m calling it a "demo." If there's serious interest, I’d happily put more time into it and get it into something more production ready.
For reference, here are a couple other sweet E2E encrypted Google Docs alternatives I came across while scoping this out:
https://cryptpad.fr
https://www.airborn.io/
Airborn did something especially cool worth pointing out: they used a service worker to guarantee that code loaded into the browser came from the latest GitHub commit. [6]
[1] https://github.com/j-berman/hush-docs
[2] https://userbase.com
[3] https://news.ycombinator.com/item?id=22145168
[4] https://news.ycombinator.com/item?id=25869472
[5] https://userbase.com/docs/
[6] https://blog.airborn.io/post/2017/08/03/Transparent-Web-Apps...
I have built products where user data is stored in the browser...
It inevitably leads to angry users when they hit the "clear cookies" button without realising that will delete all their documents...
It makes it pretty hard to use the browser for any offline use case when the user's expect their data to be persistent, yet don't understand that clearing history/data deletes the data...
Before long you'll be forced to sync the data to a server.
It inevitably leads to angry users when they hit the "clear cookies" button without realising that will delete all their documents...
It makes it pretty hard to use the browser for any offline use case when the user's expect their data to be persistent, yet don't understand that clearing history/data deletes the data...
Before long you'll be forced to sync the data to a server.
There's also a challenge here where browsers will literally just start deleting data from IndexedDB if a user starts running out of space on their hard drive.
I added this statement: "Keep in mind this is a demo app subject to change in the future. You can download your docs at any time." as a warning to anyone who might be using this site with expectations that the data will be persistent.
Ultimately I figure the only solution for a production app is to either do a better job educating users on these issues, or scrap the offline persistence selling point entirely (and just rely on it as a cache).
What did you end up doing with your products?
I added this statement: "Keep in mind this is a demo app subject to change in the future. You can download your docs at any time." as a warning to anyone who might be using this site with expectations that the data will be persistent.
Ultimately I figure the only solution for a production app is to either do a better job educating users on these issues, or scrap the offline persistence selling point entirely (and just rely on it as a cache).
What did you end up doing with your products?
I ended up syncing the data to the server, and emailing the user with a "magic link" with the decryption/auth keys in.
To begin with I didn't store the encryption key, but too many users lost the original email, so now I also store the user's encryption key, which is lame from a privacy point of view, but for most users is what they expect.
To begin with I didn't store the encryption key, but too many users lost the original email, so now I also store the user's encryption key, which is lame from a privacy point of view, but for most users is what they expect.
Got it.
Not sure if this was clear here, but when you create an account on this site, the docs do sync to a server automatically. The encryption key is derived from users' passwords (Userbase handles that part). This way if users lose their locally persisted data, so long as they still have their password they're good to go (or vice versa). It's only if they lose both that they lose their data.
But still, given your experience, it does sound like it would be challenging to sell an exclusively offline product using browser storage. Appreciate the insight.
Not sure if this was clear here, but when you create an account on this site, the docs do sync to a server automatically. The encryption key is derived from users' passwords (Userbase handles that part). This way if users lose their locally persisted data, so long as they still have their password they're good to go (or vice versa). It's only if they lose both that they lose their data.
But still, given your experience, it does sound like it would be challenging to sell an exclusively offline product using browser storage. Appreciate the insight.
Very cool! One issue with this is, depending on your security slider setting, this does not work in Tor Browser and presumably Firefox. In Private Browsing mode IndexedDB is apparently restricted, so it is only working in non-private windows for me, and of course JS must also be enabled.
Ah yes! Good point. Could work on a fallback for when IndexeDB isn't present :) It's probably still rough around the edges
"No one but you ... has access to your docs. Not even ... Hush Docs"
The gripe I have with statements like these, which these days everyone seems to make, is that I wouldn't know, and cannot prove that this is true. I just have to take your word for it.
How do we solve, in general, across software, this one problem?