One other major downside of end-to-end encryption: everything has to be done client-side, and the server becomes very close to a dumb pipe and block storage. (The only parts the server can do anything with are those that aren’t encrypted, so the explicit goal of E2EE is to reduce the server to a dumb pipe and block storage.) Got ten gigabytes of stuff you want to search through? Without E2EE, the server can implement search and store an index, so your search can be done on a fast server, and you get a response in 100ms taking maybe 10kB of network traffic. With E2EE, all the server can do is hand you encrypted blobs. Maybe you have to download the full ten gigabytes, or maybe you also store the index and can download just that, which is probably smaller, but now you’ve got to do complicated index synchronisation when making changes (complicated because you want to minimise the amount of extra sync required). So your search now runs on your probably-slow phone processor and storage (we don’t all use iPhones), maybe takes a few seconds, and requires that you have downloaded (and store) maybe 10GB, maybe only 100MB, but a whole lot more.
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.
I see this kind of pushback from engineers quite often when advocating for privacy first technologies. I think this comment is a good example of the sort of reflexive dismissal many developers have to changing how they work, from being asked to move a bit away from the dominant paradigm of the last 20-30 years (cleartext private data on servers).
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.
1. I use the 10GB example to show, by an extreme that is nonetheless completely plausible in many domains (mostly communication apps, the frontrunners for E2EE: email with various attachments, chat with not even a few thousand photos attached, that kind of thing), where the scheme falls apart.
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”.
I generally agree with your points but would point out that when I exported all my evernote data a few years ago it came to about 15gb, mostly because I use a lot of photographs and diagrams in my notes. I don't know anything about this note platform but if it allows multimedia embedding then the data can balloon quite rapidly.
I might imagine a pipeline where a full photograph blob is downloaded and decrypted on your device, normalized, run through something like image2vec + ocr + metadata extraction, and the result stored in an index. At that point, of course, you could garbage collect the original blob - at least until your app releases an major update version requiring a reindexing of blobs.
(I am leaving this comment to explain why I am downvoting your comment, as while this is absolutely the correct answer for how to build this--and so in some sense deserves an upvote--it is itself the proof for why you were wrong and yet is presented as the response to a socratic question that should have led you to realize why you were wrong and yet you didn't seem to acknowledge such, even though you clearly do appreciate that this answer is the opposite of the narrow question that was asked. I thereby feel this deserved both the two downvotes--on this answer and the original question--as well as--and I try to avoid doing this: I prefer just hitting downvote and moving on with my life--an explanation to ensure that if anyone is merely skimming they see that this is in fact the reason why the device can do that search locally without all 15GB synchronized at all times, and work only ever has to be done to improve old indexes in the off chance you make a major improvement to your indexing, and that both can be done incrementally and is often avoided by centralized players anyway as it is so costly for them.)
So you're saying you DON'T need to keep the photograph on the device, and it can be retrieved as needed, like I was? Your scheme only requires you to keep the index. I don't understand why you asked that question in the first place?
> 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.
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.
> 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.
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.
> if the software is served over the Web or to any platform with automatic updates, E2EE is fundimentallu broken; and, first-party end-to-end encryption is snake oil.
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.
First party E2EE has some value even under a "trusting trust" scenario: it lets service operators keep rogue employees from accessing your data. To compromise your data requires pushing a software update, which on pretty much every platform[0] creates a paper trail of cryptographic signatures leading back to the company's signing keys. If someone finds out about user data being stolen through a modified version of the app, that can be traced back to any developer who had access to key material.
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.
>One other major downside of end-to-end encryption: everything has to be done client-side, and the server becomes very close to a dumb pipe and block storage.
It tries to be, but in practice as I say you mostly just end up with the worst of both worlds, because of perverse incentives (the software provider wants to charge a monthly figure and doesn’t want their server to be fungible).
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.)
I know I'm biased because I'm working on an E2EE todo/planning app[1], but over the years I've become convinced that E2EE apps are the future.
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.
Ok, I'll byte. Let's take a hypothetically example that might just happen.
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?
So, searching through encrypted text is a really interesting problem!
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.
> the software provider wants to charge a monthly figure and doesn’t want their server to be fungible
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 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.
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.
It is, and that's fine, but it's important to call out things like the search example above to people actually know what that means. There are some things where it's required, and some things where a 10x increase in how long it takes to do anything is not acceptable.
> With E2EE, all the server can do is hand you encrypted blobs.
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...
The top-level comment should at least acknowledge that it's possible. We shouldn't just put up our hands and say "it"s impossible/impractical to have E2EE data without overloading our clients", we should be pushing companies to prioritize research into techniques like encrypted search, so that the "future" can come sooner
I mean it’s like Crypto enthusiasts claiming their coins are green because they can theoretically run on renewables, when the reality is that the majority of miners use fossil fuel sources, and either way the energy is wasted.
Similarly, unless we desire E2EE for everything, it’s both algorithmically and computationally more feasible to stick to centralised unencrypted formats.
Personally I firmly believe that in the near future local-first software is going to be the main paradigm of Internet based applications, and end-to-end encryption will be its second nature [1].
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:
When I last looked into fully homomorphic encryption in 2017, the algorithms were still not at an applicable place. Sure, we may have polynomial time algorithms for FHE, but it doesn't help anything in practice if those polynomials are not reasonable themselves.
Well this is what the TPM is supposed to solve. You want to trust the developer (after all if your client app is compromised, end-to-end encryption won't save you), but you don't want to trust the server, and physical access to the server doesn't get you any access to the data.
I pity the one who has 10GB of notes. It's a fair point though. E2EE is a tradeoff that may make sense in some cases but not others, and yes, it doesn't do away with the need for trust.
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!
>> Our team will never read or access your note content, unless we have received your express permission during a customer support interaction
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).
All 450+ of my journal entries, notes and computer ideas are unencrypted, public and shared and worked on in the open on GitHub, so are not encrypted except over TLS when I edit them on GitHub when logged in under my account samsquire
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.
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
Wow this is like an extreme version of "working in the open". If you don't mind me asking, do you have any private notes? Like maybe your workout notes or something? If so, what proportion of your notes would you say you keep private?
When I'm at working for or at a company I either use the company or client provided Wiki such as Confluence or knowledge base software. This is private to the company.
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.
Do you have something that allows you to publish that as well?
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.
One of our guiding principles with Supernotes is that data staleness is an undesirable property and so we're trying to build a markdown-notecard-first (read: portable) and sharing-first (read: no staleness) notes app.
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/
My preference is to not need to care about what I'm pasting into my notes app. As I use the app on mobile, desktop OS and store not only organized content there, but also random thoughts, incl. sensitive content. That's I prefer to have it E2EE and use standardnotes.com (no affiliation, I'm just a happy customer)
Last I knew standard notes hid 2FA behind the paywall. Basic security should not be a pay feature. If they're willing to hang non-paying potential customers out to dry what other questionable security choices are they making?
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.
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.
Google Photos whole premise is that they analyze, categorize, scan, and classify the photos for you. They find similar faces, put your photos on the Maps timeline, etc.
If you don't want Google to do that, there's no point in using Google Photos. The entire benefit disappears.
After seeing umpteen people at various large corps put a password into an unencrypted note over the years that's then stored on "the cloud", I think encryption should be standard.
Or for that matter someone who isn't an employee at all. Unless they're claiming they have figured out absolutely perfect security such that they can never be hacked or compromised. Or isn't an employee/manager right now, because the thing about companies is that they tend to grow and die, management changes over time, they get bought, etc. That's the human condition, we don't live forever.
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?
> Or for that matter someone who isn't an employee at all. Unless they're claiming they have figured out absolutely perfect security such that they can never be hacked or compromised. Or isn't an employee/manager right now, because the thing about companies is that they tend to grow and die, management changes over time, they get bought, etc. That's the human condition, we don't live forever.
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.
> Our team will never read or access your note content, unless we have received your express permission during a customer support interaction
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.)
In most currently widely-used E2EE systems isn't the provider in control of the client anyway, and thus there's not really any protection against rogue employees? If I'm in control of the client and I'm encrypting all my data before I send it to the cloud storage provider, then sure, I'm safe against rogue employees at the provider accessing my data (although they could still delete it). But the E2EE systems I'm aware of consist of a provider distributing a client that promises to encrypt data between that client and the provider's servers, but not in a way that makes the process easily auditable by the customer.
I don't know how you do things where you work. But a rogue employ making changes to the product, then wide releasing it or releasing it to anybody is not something you can just do.
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.
Of course I'm not suggesting that service providers shouldn't have robust processes to protect against rogue employees. What I'm suggesting is that from the customer's perspective, if you're running a client that was distributed to you from the provider, you should be just as worried about a rogue employee putting something malicious in that client to e.g. compromise the E2EE as you are worried about a rogue employee reading your unencrypted data on the server.
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?
Author here – can't say I agree. If this is FUD, I would assume there is an app you're familiar with which you can say with actual 100% certainty is end-to-end encrypted in a leakproof way?
In cyber security there's no such thing as 100% secure. There's insecure, secure, less secure, more secure etc. Always relative because security is not a concrete thing. You can't at any point say this app is 100% secure. That doesn't mean that the app is not 100% secure or that the app shouldn't use encryption since it can't be proven.
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.
I don't need to have 100% certainty that an app is end-to-end encrypted in a leakproof way to prefer it to an app that's not end-to-end encrypted at all.
Having a preference is different from saying something is FUD. It's not FUD to say that there is still a lot of faith/trust required in the gap between "this app claims to be E2EE" and "this app is perfectly E2EE with no holes in an ongoing manner so my content is actually secure". Especially because it's much harder for a notes app to have encryption features like Perfect Forward Secrecy.
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.
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.
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.
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.
So instead of a third party, I'm expected to install and run my own syncing service on the open internet and all of the security patching/monitoring is up to me?
I'd still want E2EE for that since if someone breaks the syncing service they'd have access to all of my notes.
Yes. And not sure why you're dramatizing it so hard, the best security/patching/monitoring comes from free and open source software, and the biggest fails tend to come from third parties that I (or more importantly, everybody else) can't monitor.
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.
No. I have Bitwarden for that and prefer all the speed/indexing features I can get instead. If there are NO compromises, then of course encrypted notes are interesting.
Co-founder of Supernotes, Tobias, here! I thought I'd try to tackle some of most common questions in one go.
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.
I for one liked the article a lot, and I applaud you for doing the research and sharing it even if it's a negative result, especially with the HN crowd. Much more respect than what the majority does - plaster on some "military grade encryption" when they mean they have FDE or some other standard encryption at rest where they control the keys. Even better, educating the public about this.
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?
I have a social notes app (Turtl: https://turtlapp.com/) and it is end-to-end encrypted. It takes a bit of architecting, but the concept is completely doable.
There are downsides to everything. This whole blog sounds like an excuse: "we don't want to apply E2EE because it can be a little inconvenient so we will just go ahead and store everything in plaintext because who cares!"
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.
I read the article but I'm not sure what the objective was in the end. It seem a way to lengthy education course on E2EE. Almost like you're trying to convince someone of something you think they don't need. That usually ends badly in my experience.
Actually the opposite! We have many users that ask about end-to-end encryption and what that means and if we have it, so this blog post was written to try to answer those questions all at once, in what I hope is a way that non-users of Supernotes also find educational.
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.
Still sounds like you are trying to convince people that its not needed. I have found that people who spend more energy on explaining why they think something is the way it is ends up being more about them wanting to convince others of an opinion, than stating outright, short and sweet, why you aren't going to implement something. Personally I don't think its necessary to have a big education course one what E2EE is, there is plenty o material on the subject that can be pointed to.
People DEFINITELY don't know what e2ee means, and it's wildly abused as a buzzword. Explaining what it is and what complementary requirements are necessary is just universally positive, no matter where in the privacy debate you sit.
What about things like Trusted Execution Environments? I know that people love bashing them for being broken, but realistically speaking.. if you don't have malicious nation state level actor in your threat model(since legally there is no way to get the data, only by breaking it, and even then with a lot of asterisks), they could help a lot with moving things server side in an encrypted form.
Hobbyists are pulling keys out of current TPM chips, but why bother with that (it requires physical access), when automated, fully remote attacks are available:
Welcome. BE NOT TROUBLED anymore. you’re at the right place. Nothing like having trustworthy hackers. have you lost money before or bitcoins and are looking for a hacker to get your money back? You should contact Albert Gonzalez Wizard right away it’s very affordable and we give guarantee to our clients. Our hacking services are as follows: -hack into any nkind of phone _Increase Credit Scores _western union, bitcoin and money gram hacking _criminal records deletion _Hacking of phones(that of your spouse, boss, friends, and see whatever is being discussed behind your back) _Security system hacking...and so much more. Contact THEM now and get whatever you want at info@albertgonzalezwizard.online / albertgonzalezwizard@gmail.com Whatassp Number: +31685248506 Telegram Number: +31685248506
Last year was a bad year for me, I lost all my savings to AutoBinarySignals, I invested over $15,000.00, When it got to the time where I wanted to withdraw my money, I was denied access, i called them and they were unreachable. I emailed them and I got a reply asking me to deposit more money for me to be able to withdraw my money, I disagreed and they threatened me. After weeks of trying to get my money and also getting the assistant of a lawyer, I was still unable to get my funds. a friend referred me to [ info@albertgonzalezwizard.online or whatsapp +31685248506 Telegramm: +31685248506 ] a certified Binary option recovery expert who guided me on steps to take to recover my funds. I have recovered all my money in weeks and I still find it hard to believe.
Now that E2EE is considered a desirable thing, due to marketing, everything that does encryption of any sort is called E2EE. It doesn't really mean anything anymore.
I added end-to-end encryption to my contact information sharing app, Neucards, because it is a perfect fit for the technology - sensitive information that is useful when shared with friends and potentially valuable to 3rd parties or open to abuse. It took almost a year to add this feature working on my own, but I sleep better knowing everyone's information is protected.
An ad maybe, it's clearly written by a company that has a note keeping app and they mention their app a few times.
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.
Try Turtl (https://turtlapp.com). Disclosure: I built it. It's actually end-to-end encrypted (ie, don't lose your password) and has collaboration features. I've mentioned elsewhere in this post that the conflict resolution is terrible, and also I haven't done a release in quite some time, but I'm (slowly) working on an updated version at the moment (hopefully with better conflict resolution).
The problem with end-to-end encryption, is that you just have to have the vendor’s word for it, and its next client version can be compromised anytime.
Good luck with that, we don't have any app stores that let third parties verify checksums of open source projects. The trusted computing base is controlled by Google and Apple basically, and they don't allow certificates from third parties who do audits.
You can't completely remove the trust factor no matter what you do. Can you completely 100% trust your computing device? Maybe. Can you 100% trust your network? Maybe.
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.
Author here! If you 100% need E2EE for your notes then not using Supernotes is actually our recommendation as well. But as I tried to show in the post, it's hard to do and arguably even harder to prove that it has been done correctly. And E2EE not done correctly might as well not be done at all.
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.
I don't think touting no E2EE is going to get you more users. Fine, don't do it, but I'm pretty sure the people who want E2EE (myself included) are likely very convinced it's what they need and will act accordingly. And those who don't care for E2EE won't care whether you offer it or not.
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.
Yep, getting more users wasn't really the goal of this blog post. Mainly it was intended as a response to the many support requests we get asking about what kind of encryption is utilized in Supernotes, which frequently lacked a clear understanding of different types of encryption and what that means. That is why I tried to structure it as a helpful tutorial that anyone can read to hopefully gain a better understand of encryption basics.
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.
Implementing E2EE encryption safely is difficult. If it's not your core competenancy, should you really expect them to do that? If you don't know what you're asking for.
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.
I'm a security professional, btw. There are avenues like social key recovery which could be used to prevent absolute data loss, and UI approaches which ensure the user actually wrote down their recovery key (e.g. prevent copy and paste and have them type it in on the next screen, where it is not visible).
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?)
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.
Assuming that you're not a famous A-list celebrity/influencer or something, or some high ranking exec at a publicly traded company, I'd wager that the answer is no. In fact, most headlines phrased as questions can be answered in the negative.
Quite simply, no one cares about you, much less your notes.
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.