
Ask HN: is e2e encryption desirable in a note-taking app? - soneca
Hi HN!<p>I am bootstrapping a web app for 1:1 meeting notes (https:&#x2F;&#x2F;www.oneonemeeting.com).<p>Its core functionalities are all done and I have a few paying customers. Then I realized that I had access to all the notes of my customers -  including colleagues at my day-job employer that are using my app. I am the only developer and I refrain from reading these notes but on ethical grounds only. I believe a technical barrier blocking me (or anyone along the way) to access these notes is desirable.<p>My doubt is if I should work on it right now. So I would like HN&#x27;s opinion on two dimensions:<p>1) From the point of view of a <i>user</i>: is e2e encryption on a 1:1 meeting notes app desirable for you? Please help validate or not if it is a worthy feature to work on.<p>2) From the point of view of a <i>startup founder</i>: the MVP is ready to market without this feature. Should I spend more time building this feature or should I focus on marketing and think about it when the product is more validated?<p>thanks!
======
vishnuharidas
1) As a paid user, I always want the privacy and security of my data. I may
talk business deals over the app, and I don't want anyone else to read it. A
small fault on the server can leak the entire database of my business
conversation.

2) As a founder, I will include security as a primary function. Because people
want to ensure that their conversations are secure. Also, "security" is the
highlight when I invite customers and investors.

I strongly suggest to include data privacy and security. It is important for
an app where people discuss important stuff.

~~~
soneca
Thanks! I am indeed inclined to work on the data privacy before focusing on
growth. It is just that it goes against to some advice for lean startups.

------
snazz
My principal concern in this case is a core problem with E2E web applications
in general. For it to be E2E, your decryption needs to occur client-side. In
the case of a web app, this would be JavaScript. An attacker could modify your
decryption code to send the plaintext to an attacker with ease. More
importantly, however, since the user won’t be storing their decryption key on
their computer like they would with a real desktop app, you’ll be sending both
the cipher text and the key to the user on every request, meaning that it’s
not truly E2E since an attacker on the wire would have the ability to decrypt
the message too. Your server would store both as well and could decrypt the
messages if it were hacked.

This is the fatal flaw of ProtonMail’s supposed E2E and I don’t think you
could get around it without forcing the user to use a real app that stores the
keys locally and not on your server.

------
Jeremy1026
Absolutely. Storing sensitive data in plain text on a server is just waiting
for something to go wrong.

------
itskoshkin
Of course it is. Not for all, though.

