Live data from Hacker News

Should notes be end-to-end encrypted?

supernotes.app

91–100 of 151 posts

Re: Should notes be end-to-end encrypted?

#91

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…

I would not use your app, but I understand the choice. Most important thing is to be honest about what you are offering.

Re: Should notes be end-to-end encrypted?

#92
post #43

Earlier 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…

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?

Re: Should notes be end-to-end encrypted?

#93

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, tr…

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?

Re: Should notes be end-to-end encrypted?

#94

Earlier 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,…

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.

Re: Should notes be end-to-end encrypted?

#95
post #6

> 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.

Checkout Notable https://github.com/notable/notable

Re: Should notes be end-to-end encrypted?

#96

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…

I think this depends on if homomorphic encryption is feasible and fast. This would alleviate most of the concerns here.

Re: Should notes be end-to-end encrypted?

#98

Earlier 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.

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.

Re: Should notes be end-to-end encrypted?

#100

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…

> your probably-slow phone processor and storage

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!

Post reply on HN