Should notes be end-to-end encrypted?
supernotes.app
supernotes.app
It kinda amuses me that mobile spent a long time moving both storage, computation and network traffic from the client to the server as much as possible (because the mobile devices had too little of each), and E2EE significantly forces it back the other way. One would hope this would mean that you’d get more just-software rather than software-as-a-service, but no, mostly you just end up with the worst of both worlds.
I’m glad that they mentioned “In the end, trust is Still Required™”, and the last sentence of that section is good stuff. But I like to state it more strongly in two ways: if the software is served over the web or to any platform with automatic updates, E2EE is fundamentally broken; and, first-party end-to-end encryption is snake oil.
That sounds like a feature...
Anyway, it’s still much more commonly a limitation than an advantage. Perhaps the most obvious example: I want to be able to search through 10GB of emails without needing to download them all (or a not-much-lighter index), because downloading it takes a long time, costs a fair bit (traffic isn’t generally), and requires that I have that much spare space on whatever device I’m using at the time.
The fact of the matter is that E2EE in all its forms is consistently inconvenient—and double racheting makes it even worse than earlier non-key-cycling techniques. In some situations it may be worth the inconvenience, but I wish there was more acknowledgement of the fact that it’s seriously not the ideal goal, and I wish the innovation would head in the direction of proper and deliberately thorough decentralisation instead, because if you run your own server, you don’t need E2EE: its purpose disappears completely, leaving only the inconvenience. (Reduce it instead to just encryption at rest and transport encryption, which are still useful and entirely sufficient.)
All the syncing code you have to write anyway if you want your app to work offline. Despite all the buzz about big data, most individuals and most companies generate only a modest amount of data. Even when you have a long tail of archived data (e.g. emails that go back 10 years) the key benefit is in having all recent data with you, available offline, and end-to-end encrypted.
Self-hosting is a lot more difficult in practice than in theory. Somebody has to make backups, maintain a server architecture with redundancy, apply security patches, etc. For hobby purposes you can get away with just not doing any of that, but for businesses and people who don't want to tinker with their own servers outsourcing all this makes a ton of sense.
I don't agree with your claims that traffic is expensive. In any case, downloading data once and syncing subsequent deltas is still a lot more data efficient than roundtripping JSON for every user action.
Imagine a company has a Wikipedia hosted by a 3rd party. I interpret E2EE as: after I submit a post, it is encrypted, and the servicing company can't look at the unencrypted data, my coworkers can decrypt the posts.
It is simple to ask "how would you support linking to posts" - but "how would you support searching for posts"?
Would you maintain a key-value lookup list? Would you handle semantic search? Are there E2EE algorithms that facilitate enhanced searching?
It's actually possible under some ciphers / search algorithms - if the client generates encrypted inverted index entries when submitting a post, and encrypts their (vectorized) search query using the same key, the server can compare them and return a scored list of IDs.
You do need to weaken the encryption scheme somewhat - in particular, term-frequency analysis becomes possible.
Whether it was intentional or not, +1 Funny.
Sounds like yet another reason to use free software and pay services for their actual services, like storage.
> I want to be able to search through 10GB of emails without needing to download them all (or a not-much-lighter index), because downloading it takes a long time, costs a fair bit (traffic isn’t generally), and requires that I have that much spare space on whatever device I’m using at the time
10GB is pretty much nothing nowadays, and once one has downloaded it then one only has to download the updates, not the whole thing from scratch. And local search is so much faster than remote search that it is incredible. Using notmuch for email is such an improvement over the Gmail web UI; it really has to be seen to be believed.
> I wish there was more acknowledgement of the fact that it’s seriously not the ideal goal
Hard disagree here. The ideal goal is not trust in a third party; the ideal goal is freedom from having to trust third parties to do more than one can verify. I can verify that a storage provider is providing me storage (I can write data, and randomly send read requests; one might even develop bandwidth-efficient proof-of-storage protocols); there is no way for me to ever be sure that a messaging provider is not reading my messages.
> if you run your own server, you don’t need E2EE
One still needs encryption from one’s server to another’s. To put that another way: from one’s end to another’s. Or … end-to-end encryption.
10GB is more space than a very significant fraction of people have available on their devices (more even than some new devices have free). Or want reserved for stuff 99.9999% of which they will absolutely never access. 10GB is also considerably more traffic than many can spare without incurring multiple dollars of cost. 10GB may also take most of a day to download for a great many people. People might also just want to access their stuff on a new device, such as someone else’s computer.
Local search certainly can be faster, but it’s often not. It’ll normally be using different software from what the server uses, too, since the server software is likely to be factored as a server with no direct library equivalent, and my experience is it generally produces inferior results. I know, none of this is inherent, merely typical. But back to performance: you might be surprised at just how slow storage is on cheap phones. Only a few megabytes per second is realistic, and with not enough memory to keep it in there either.
When talking of all this performance stuff, I feel like pointing out that I live in Australia and am used to the internet being slow purely because of latency to US-hosted sites. This definitely tips the balance a bit more in favour of local for me.
By all means, support downloading everything and being able to work offline and doing local search where possible. Please do, because it is better where feasible and is likely to lead to the software being better in other regards too. But for most people most of the time, requiring this is a bad trade-off.
> One still needs encryption from one’s server to another’s. To put that another way: from one’s end to another’s. Or … end-to-end encryption.
NO! This is NOT what is meant by end-to-end encryption. This is transport encryption. And note that E2EE doesn’t obviate transport encryption, because it still protects the metadata.
Encrypted search is a thing. You need to know in advance what kind of queries you want to do against your DB, but there are off-the-shelf solutions for encrypted search which do not involve homomorphic encryption. Here's an overview: https://www.cossacklabs.com/blog/secure-search-over-encrypte...
Similarly, unless we desire E2EE for everything, it’s both algorithmically and computationally more feasible to stick to centralised unencrypted formats.
This kind of pendulum like, tick-tocking back and forth between things like fat clients/thin-clients, dumb termials/PCs, centralized vs. decentralized (well, cloud-based [i.e., someone else's computer]) applications, and so on, are part-and-parcel of computing that goes as far back as possible. This is just another "tock" in that cycle.
Technology happens in leaps and bounds and not at all uniformly, so this is a natural result. I personally am for the best of both worlds in whatever makes the most sense, but definitely skew towards privacy, security, and user-authority.
True, this is because all software design and architecture is a set of trade-offs and each trade-off has a downside. Software design and architecture is also very fad-ish in that "the it thing" changed and everyone rushes to use it in order to keep their skills competitive. The fads of IT is a large part of the churn that makes low quality software.
1. The idea that it’s impractical to download the data. We are talking about searching text notes. 10gb? That’s nearly 7 million pages of notes. Doesn’t seem a reasonable figure. Even hundreds of megs of text would require a lot of time to acquire and even that would rarely need to be downloaded in one go (new device).
2. The idea that tech that tends to live on the server is somehow magical. Search would take “a few seconds” on a “slow” phone processor you say. Phone professors are incredibly fast these days, but in any case, since when is text search slow? I feel like many developers treat text search as a scary magical black box but it’s rather straightforward. Read about inverted indexes and consider that the servers of the mid 90s were serving at least tens of thousands of text searchers apiece with processors probably slower than what’s in your phone. There are libraries you can use locally to make text search pretty trivial. Apple supports text search (spotlight) across the data and apps on your phone. It’s not rocket science.
3. The idea that anything other than conceptually perfect encryption is useless. “first-party end-to-end encryption is snake oil” - assuming you mean crypto where the user does not handle the keys directly and a first party causes them to be generated, first party e2ee describes some of the biggest privacy wins of the last 15 years - iMessage, FaceTime, Signal, WhatsApp.
I consider even 10MB more than is ideal to require downloading before you can do anything, in most domains.
Text-only notes? Sure, they’re likely to be adequately small, but I’m talking about downsides of E2EE in general, not just this application.
2. I wasn’t sufficiently clear in the context of the figures I used for client search duration. I was talking most of all of the sorts of devices that can’t manage 50MB/s of I/O, and certainly don’t have enough spare memory to fit the index in RAM, so your big index is simply too big for fast to be possible—and it’ll tend to cause memory pressures that slow everything else down too. Generally speaking on a capable machine, yes, properly-done text search should be considerably faster than your latency. But also in practice apps normally use inferior search techniques than their servers, which I think is because most of the effort has gone into server-style search engines, which are not packaged for embedded/library use. As a super simple example, any mainstream email provider will be doing full text search of emails and of at least some types of attachments (you can be confident of at least PDF, DOC and DOCX), all with features like stemming and spelling correction, but I think it’s probably still true that most local email clients don’t search attachment contents and suspect many won’t do fully proper stemming or offer spelling correction. Just more generally, if you compare the search results of server and client, it’s distressing how often client is kneecapped. This is by no means fundamental.
3. End-to-end encryption is presented as a panacea. “Because it’s end-to-end-encrypted, we can’t see your messages” and the likes. Such statements are lies. They need a big asterisk along the lines of “… until we want to, or a government orders us to”. Yes, E2EE helps in the general case, and if they stopped at that I would hold my peace; but they go further and claim, or deliberately give the impression of, inviolability, when all around the world legislatures, police forces and other governmental bodies are testing the edges of undermining it all, and it would be naive to suppose they will not go further and succeed. And so I say: first-party end-to-end encryption is largely false advertising, them saying “trust us, you don’t have to trust us”.
A $100 Android (terrible buy by the way, get a second hand top model instead, unless you're fussy about new features) still ships with a ridiculously fast CPU. The Motorola E6 Play comes with a MediaTek MT6739, a four year old bottle of the barrel phone CPU, and can still decrypt data at about 135MB/s. This thing is slow even in term of modern $100 Android devices, but it's not _that_ slow!
Stuffing everything behind E2EE with on-the-fly decryption without giving it a second thought is definitely a bad idea. Building an index isn't that hard, though, especially if you're probably not syncing your personal account between 20 devices if you're on a device like that. A good index may use tens of megabytes at most, which fits into the minimum RAM allocated towards an app on modern Android already. Traversing such an index shouldn't take long either. Sure, decrypting the found results may take a few hundred milliseconds, but the search itself shouldn't be a problem, should it?
I feel like we've all been spoiled by high performance electronics to the point where we don't realize the kind of power these devices have. SD cards come with their own ARM cores running at 100MHz or even multiples of that depending on the designed data rate; that's more than enough to do some indexing!
The difficult part is getting access to all that power. It means getting rid of the nice and handy frameworks (such as the Android SDK, high level programming languages such as Kotlin, and so on) and getting back to bare metal. Even writing this stuff in Rust may come with severe performance penalties because Rust is full of unexpected and unintentional issues; something like C++20 or Zig would be much better (or C if you really hate writing software).
I have an old tablet, a dual core 1GHz CPU. I installed LineageOS on it to get it to Android 7 so basic web functionality still works without too much effort. The flash storage of this thing is known to break down and it shows. Booting up is slow, animations stutter, the settings app hangs. You know what's not slow? Opening a web page in a web view. Latest version of Chrome, inside a minimal browser UI written in native code, runs great. Sure, video playback is crap because the GPU was bad even when it was new, but this thing can fetch megabytes of JSON over HTTP3 like a damn champ if you write software right. Processing is great, it just sucks at rendering (because the drivers have been monkey patched four Android versions above the last supported one). The experience is terrible because the software is heavy and written to make developers' lives easier, not to be efficient.
Don't be fooled by the electron applications 300MB note taking apps, "slow" chips are still very capable. Imagine how long even a mid-range phone's battery would last if apps were written to be as quick on my shitty tablet as the Lightning Browser is!
This statement, and this way or extremist thinking is the classic no true soctsman fallacy. Taken to the extreme it goes back to trusting trust, and not everyone is a cryptographer who wants to verify the encryption is strong and implimented correctly. Privacy is a sliding scale and people have different threat models.
The statement is also so broad that applying it as a specific issue with E2EE seems foolish - after all the same could be said for any website. You're trusting that Amazon doesn't maliciously update their website to start sending passwords or credit card numbers in plaintext. Hopefully this example demonstrates why encryption in transit is useful.
Just as encryption in transit has tradeoffs (mainly caching), so does E2EE. The benifit of E2EE is data at rest - the server owner cannot suddenly decide to decrypt your data for their means. As you've outlined, for strong privacy this requires tradeoffs (local calculation, more complex systems). As you've also outlined E2EE is also not a magic bullet (trust the client), but that doesn't suddenly discount all of the benifits.
Yes, if the organization itself decided to compromise its own scheme, E2EE cannot stop that... but again. That creates evidence and paper trails. The kinds of people with the power to do this want plausible deniability; the last thing they want is mathematical proof that they screwed their own customers on purpose. Same with that rogue employee: they don't want to be known as the guy who signed spyware.
[0] Yes, including sideloading-friendly ones. If your rogue update isn't signed it will trip a bunch of scary warnings at install time.
From the seminal paper, "Local-first apps, on the other hand, have better privacy and security built in at the core. Your local devices store only your own data, avoiding the centralized cloud database holding everybody’s data. Local-first apps can use end-to-end encryption so that any servers that store a copy of your files only hold encrypted data that they cannot read".
[1] Local-first software: You own your data, in spite of the cloud:
I see no need to involve others in storing my notes.
What a relief!
I'd take it at their word then, trusting random employees at a random corporation, in a world where even police officers routinely get caught snooping at private data unrelated to their work (e.g. girlfriends and such).
/s
If you like other people's technical perspectives are looking for ideas or side project ideas to learn of then read my journal
For context I am a DevOps and software engineer interested in performance, distributed systems, parallelism, concurrency, futuristic GUIs, the future of programming, how computers can be used to improve society and community ideas.
Ideas for Computing 2013
https://GitHub.com/samsquire/ideas
Ideas for Computing 2
https://GitHub.com/samsquire/ideas2
Ideas for Computing 3
https://GitHub.com/samsquire/ideas3
Ideas for Computing 4 (start here if you're interested in parallelism and concurrency and algorithms)
https://GitHub.com/samsquire/ideas4
Startup ideas
https://GitHub.com/samsquire/startups
Since I'm still working on these journal entries, I don't want people to miss ideas I added if people don't come back so I create a new repository when I get to a certain number of journal entries and then announce them to others At some point I need to take a cut on ideas4
For quick notes I use notepad++ and VS Code.
If I were to join a project going forward I would create a journal directory in the repository and each day I would create a new document. I would move common reference commands and information to a separate file for easier reference.
I use a password database and I occasionally save plaintext .txt files to my OneDrive folder.
These are not encrypted but local to my computer but synced.
I create diagrams and GUI mockups with Evolus Pencil.
I have a Me folder for my CV/resume and saved invoices or saved purchase confirmation web pages or PDFs.
I also store notes in OmniNotes on Android phone. These are private.
What proportion of my notes are private?
There is far more public notes than private notes.
Yes. That's why I use Joplin (which is free and open source btw) and not some proprietary freemium app that to explains me that I don't necessary need E2E encryption for my notes.
Use case - I want to keep some notes for myself e2e on my laptop & phone but every now and then I'd like to publish a few of them under a pseudonym anonymously on the internet.
come on, now.
Note-taking and publishing are different enough to deserve being separate apps, especially when the notes can contain private material.
I touched on the example of a blog in the article in the context of E2EE, but let's forget about E2EE for a second and just look at it from a stale data perspective: you click the share button in Joplin and publish to the blogging app of your choice. Later a reader on the blog points out a few typos so you make some changes in your blogging platform. Now you have a version of your blog post on Joplin that is stale unless you manually copy-paste your changes from the blogging platform back to Joplin. Or you make the changes in Joplin and need to manually republish to the blog somehow.
But what if instead your notes app was a single source of truth and making changes there automatically propagated everywhere you needed – whether semi-privately in the Supernotes collection of a friend, in a shared Notion workspace with your team, or published to the broader internet. That's (one of) our goals with Supernotes.
Note: I run a paid 3rd-party synchronization service for Trilium Notes that would offer the publishing part of what you mentioned easily, without setting up a cloud server: https://trilium.cc/
Looking for a replacement that handles write-write conflicts better.
And you can self host it too
I tried to reason this out with them back when they had a discourse site or forum, I don't recall which it was, and was told, I'm paraphrasing, we're not going to do that and don't ever ask again with no good reasoning given.
Not only a bad look from a security standpoint but also a bad look from a community engagement standpoint. IMO standard Notes is to be avoided.
here is someone who would have loved E2E for his emails (and images in the cloud):
Google refuses to reinstate account after man took medical images of son’s groin https://news.ycombinator.com/item?id=32560361
Given the tendency of large corporations to look into our private stuff, even on personal mobile devices (Hi Apple), encryption seems to be the only remedy. That is the reason why I store my (encrypted) notes with Joplin on my own server at Hetzner and it's the reason why I only buy smartphones which offer sd-card slots, so I can expand local storage instead of relying on someone's cloud storage.
If you don't want Google to do that, there's no point in using Google Photos. The entire benefit disappears.
Yes, notes, often containing the most sensitive material of our lives should be encrypted at every stage of the lifecycle.
Either naive or dishonest. Can't tell which is worse.
The reason end to end encryption exists is to cover the cases which you can't plan for.
For example a rogue employee reading the notes of their partner.
Really it's just a LUDICROUS statement to make. This isn't the 1980s, we know how tech works. We've seen tech companies around long enough for heroes to become villains and even heroes again, to watch all stages of lots of lifecycles happen over and over again, all the good and perverse incentives that can take place. To watch, well, decades. Just raw time. Even without centuries as in some industries, some basics are pretty clear at this point and one of them is that absolutely nobody can claim that data they have access too will "never be used" in one way or another given the pace of change and uncertainties of finances and even law.
Notes tend to be things where people put in sensitive stuff, if only for scratch purposes. It's just inevitable, humans are humans. Or put in stuff they don't think is sensitive but who they're wrong, even security agencies can screw stuff like that up. A notes are a tiny amount of data by today's standards, handling everything client-side is not a big ask. So yeah, kind of a wow.
Edit: another top conversation on HN literally right this instant is "“10% error rate is okay“ – Leaked EU Commission document regarding Chat Control"[0]. What happens when the law is changed such that all notes must be constantly scanned by AI for signs of criminal activity?
----
Exactly. The perception I have is that when you subscribe to a non-E2EE service, you're not subscribing to a service. You're actually placing a small bet on the service to: always keep all serverside components up-to-date, proactively monitor for vulnerabilities, proactively implement security controls at the company and technology level, always hire the absolute best engineers, etc.
The problem is that every startup and every company always starts like this. Everyone has the best of intentions. Then the tech debt accumulates, the VC funding dries up, and time goes on. When the service is going to shut down, after being acquired, after being sold, or after being successful, will the serverside security still be perfect?
You have two options: don't store anything sensitive in these services, or assume perfection. I definitely won't bet on the latter.
So, where is this available? Services with this security property are illegal in the US, and most other countries. (Warrants and bankruptcy courts are two reasons.)
However, they’re advertising a non-e2e app, and then incorrectly claiming they can legally provide this property.
And if you did somebody would quickly notice and you might go to prison.
That a pretty high barrier to entry compared to just having admin access on the db.
This entire section is FUD. Trust is "Still Required™" - unfortunately HN doesn't support underlines so I can't get accross the full obnoxiousness of the original formatting - therefore having your data in someone elses database is no worse then using an app that someone might add a backdoor to?
It is a very common pattern that an app which claims to be secure turns out not to be. In fact I would say that claim to be secure and actually live up to that are probably the exception rather than the rule.
This is why we self-host 99% of the content related to managing Supernotes (as a business) on Supernotes itself, but (a small minority of) sensitive content we keep in 1Password, which is one of the few apps I trust to have done E2EE well enough for me to feel that data is secure.
This is why I like what the folks over at Notesnook are doing with Vericrypt [0], which essentially allows users to verify the encryption themselves in a very easy to use way.
Why use and popularize a 3rd party stored personal notes app at all? I'm well aware that this is how a lot of people do this sort of trading convenience for genuine security.
But we (well, maybe not people here) could put more effort into solutions that don't require a money making middleman, since the tech is here to solve this problem without it.
I have more than one device and I'd like to be able to take notes on one and have them viewable/editable on the others. With E2EE, I don't have to trade this convenience for security.
I'd still want E2EE for that since if someone breaks the syncing service they'd have access to all of my notes.
This is all the whole entire point of software freedom. It's not that it's perfect, but it is as good, frequently better, than third parties. Weird how this is controversial.
Try syncthing. But if not that, I mean, rsync, which is what the big boys rely on anyway.
What use cases are knocking it over for you?
To start Supernotes is very different from many other note-taking apps – we are focusing on the social aspect of sharing knowledge with your friends via markdown notecards [1], rather than local-first note-taking apps of which there are many to choose from if that is what you prefer. As a small team of two, trying to do both ease-of-sharing and end-to-end encryption (E2EE) right is a mammoth task, so we wanted to do one right, the social side of things.
E2EE has become a buzzword for marketing for the last few years, but what's most concerning is how misunderstood it is. That's one of the main reasons why we decided to publish this article as we regularly received support interactions from customers mis-understanding encryption, with some asking whether we have "end-to-end encryption in transit" and "two factor encryption".
This article is here to help the average (less tech savvy than HN) user better understand how encryption works so they can make a more informed choice whether Supernotes is right for them. We are not saying there are no reasons to use end-to-end encryption — there are a lot and other people have explained the obvious benefits quite well! The question is whether the increased effort and friction are worth it for your use case.
If you want to quickly jot down and share your recipes, restaurant recommendations and startup ideas with your friends then Supernotes is for you. If you'd like to write down passwords, trade secrets, or your deepest darkest desires then we suggest using an alternative.
For my own venture (large file transfers) I went through very similar thoughts, but have decided to keep e2ee, but it's going to take a lot of time to see if it actually benefits my users.
I've found that "going against the grain" with offline-first, e2ee etc is mostly a problem of immature off-the-shelf tooling, protocols and libraries. I.e. you need to put in a lot more work to build an equivalent product. Do you think that with a more mature ecosystem, you would have come to a different conclusion?
You forgot to mention the biggest downside to not encrypting the notes: your company can read/edit them on a whim. Sure, E2EE isn't perfect but it sure is a PITA for vendors to steal data behind their users' back.
The solution to "E2EE is hard" is definitely NOT to ditch it altogether. Nothing is perfect. As a software vendor it should be mandatory to have E2EE in place. It doesn't matter if it's notes or emails or messages. I, the user, should decide what is private and important - not you.
But if any of our users feel like they need E2EE for their notes, we'd like to steer them towards a platform better suited because that's not our priority. We've typically done the same thing when small businesses come our way and ask if Supernotes would be a good fit for their team: we tell them the team use-case is not our priority at the moment, so if that is a priority for them they would probably be better served by a shared workspace tool like Notion.
My 2 cents.
I really don't like every app reimplementing secure block storage and exchange or whatever.
https://www.usenix.org/conference/usenixsecurity17/technical...
But I don't see how this is clickbait. The title asks if your notes should be encrypted, and the article does a pretty good job at explaining different kinds of encryption, what the company uses and why, seems like the opposite of clickbait to me.
> Our app, Supernotes, is not E2EE
That should have been at the top, and saved me two minutes.
If someone develops a usable, cross platform, e2ee notes app with collab/sharing features, I'll gladly pay good money to use it.
But things like encryption help build trust. They ensure that there are safeguards in place in case something gets compromised. They reduce number of bad actors from unlimited to just one (the vendor).
In my opinion, all these are very good reasons to always opt for E2EE even if it isn't perfect.
Not going to ever touch Supernotes now.
And yep, partly it is that don't have the time to dedicate to this. There are so many other features that I think would better serve our users than E2EE, so we're prioritizing those for now (table stakes in the notes game are very high). But if I had infinite time at my disposal, I absolutely would add some form of E2EE – though still not sure I'd make it the default as again, there are some things you can't engineer your way out of when you add E2EE.
The one that is most on my mind probably being irrecoverable data loss. If watching the cryptocurrency space over the last few years has taught me anything, it's that even if you beg people to take good care of secret/recovery keys, frequently they don't. And that's for stuff you can sell for actual money.
Irrecoverable data loss is a real pain in the ass that needs to be dealt with but it's the only way to achieve true privacy. Knowing you can't decrypt my data whether by your own will or coerced by your government (which may or may not care about privacy now or in the future) or at the whim of a North Korean hacker, keeps my mind at ease. Why on earth would I give that up? Google has Keep, Apple has Notes, they do a pretty decent job as far as basic notes app go. Sorry if this sounds like putting you down, I'm sure you put a great deal of work into your app and you seem passionate about it and I'm sure it's great. But because the table stakes in the notes games are high, you need to go above and beyond what your competitors offer. Not just great UX, but pushing _every_ boundary in the space, including by offering privacy. I feel like in 2022, privacy is non-negotiable. Make it optional if you feel you must, or don't, but don't suggest skipping E2EE is in any way a virtue.
Our current set of priorities means that E2EE is not going to be at the top of the list for the foreseeable future, so we want existing and potential users to be aware of that (and our rationale behind it). We prefer to have users that understand and align with our vision rather than trying to convince/trick people with different priorities to use Supernotes.
If you're not a paying customer and you are not willing to buy the product, what causes you to think they'll do what you think they should do on arbitrary principles (that you might still not buy the product even if they implemented it) rather than practicality of reality. Why should they listen to voices on the internet who aren't even their customers?
Expecting other people to do more for you without giving anything in return is some thing I don't like.
People tend to exchange and discuss ideas on HN and this is no different.
More to the point, sorting these sorts of things out is kinda what why your users are paying you. I would have been okay with "we want to make sure our users don't experience data loss, so we're still working on the right implementation of E2EE" (as long as you actually working on it). But outright declining to implement E2EE is user-hostile. As noted by the sibling comment, in 2022 privacy is non-negotiable.
(Also I don't think you're adequately considering the liability you're exposing yourself to by holding your user's data unencrypted. What if some HR exec decides to make a note with all their employees social security numbers, addresses, and contact information, and then there's a data breach?)
If you knew how hard it was to write E2EE you would be more respectful of others honesty.
In this thread you call people lazy and effectively claim they should roll their own E2EE crypto. And you write off using others non security software.
What if they aren't professional cryptographers? Would you still recommend that to?
The article does seem to educate people on what different encryption models mean, which is a good thing. People should know and understand what they signup to use and how control of it could be taken from them. Take it would a grain of salt, companies have lied about E2EE so the only way to know for sure is to do the encrypting yourself and stay on top of security flaws in your encryption software.
Quite simply, no one cares about you, much less your notes.
Good explanation though.