Great explanation of end-to-end encryption, followed by "but we're too lazy to do that." Not going to ever touch Supernotes now.
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 bet…
Should notes be end-to-end encrypted?
91–100 of 151 posts
Re: Should notes be end-to-end encrypted?
#92Earlier quoted context omitted.
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…
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 year…
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?
Re: Should notes be end-to-end encrypted?
#93Co-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, tr…
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?
Re: Should notes be end-to-end encrypted?
#94Earlier quoted context omitted.
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 prio…
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,…
Re: Should notes be end-to-end encrypted?
#95> Should Your Notes Be End-to-End Encrypted? 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.
Re: Should notes be end-to-end encrypted?
#96One 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…
Re: Should notes be end-to-end encrypted?
#97> 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.
Re: Should notes be end-to-end encrypted?
#98Earlier quoted context omitted.
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 awar…
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.
Re: Should notes be end-to-end encrypted?
#99Re: Should notes be end-to-end encrypted?
#100One 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…
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!