[HN Gopher] Should notes be end-to-end encrypted?
___________________________________________________________________
Should notes be end-to-end encrypted?
Author : fastball
Score : 126 points
Date : 2022-08-23 08:48 UTC (14 hours ago)
(HTM) web link (supernotes.app)
(TXT) w3m dump (supernotes.app)
| maksim-m wrote:
| > 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.
| break_the_bank wrote:
| 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.
| longrod wrote:
| The best I have found so far is Notesnook Monographs [0].
|
| [0] https://monograph.notesnook.com
| piaste wrote:
| Hit the Share button in Joplin and select your blogging app
| of choice.
|
| Note-taking and publishing are different enough to deserve
| being separate apps, especially when the notes can contain
| private material.
| crabmusket wrote:
| For this I use Standard Notes and Listed.to for E2EE
| encrypted writing as well as one-click sharing to either my
| little blog, or an anonymous link.
| BxGyw2 wrote:
| Yeah. It's called a web server and it's been around for ages,
| try it out some time
| aliqot wrote:
| > Yeah. It's called a web server and it's been around for
| ages, try it out some time
|
| come on, now.
| inkblotuniverse wrote:
| What?
| [deleted]
| adripop wrote:
| Relax
| jmnicolas wrote:
| IMHO this is not the role of a note app. For this, get a
| private blog or use Medium.
| anthropodie wrote:
| Checkout Notable https://github.com/notable/notable
| sodality2 wrote:
| Trilium Notes offers this: https://github.com/zadam/trilium/
|
| 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/
| secretary-horse wrote:
| If you sign up for joplin cloud you can publish your notes.
| https://joplinapp.org/plans/
| chrismorgan wrote:
| 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(tm)", 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.
| coldtea wrote:
| > _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._
|
| That sounds like a feature...
| chrismorgan wrote:
| 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.)
| eadmund wrote:
| > 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.
| chrismorgan wrote:
| > _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.
| jdvh wrote:
| 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.
|
| [1] https://thymer.com
| throwaway888abc wrote:
| That's looks pretty cool. Looking forward for invite.
| Just signed up.
| geoduck14 wrote:
| 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?
| pc86 wrote:
| 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.
| sipjca wrote:
| I think this depends on if homomorphic encryption is feasible
| and fast. This would alleviate most of the concerns here.
| crabmusket wrote:
| 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.
| jeroenhd wrote:
| > 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!
| operator-name wrote:
| > 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.
| kmeisthax wrote:
| 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.
| operator-name wrote:
| Trusting trust is required for E2EE to have value at all,
| otherwise E2EE is just a claim that cannot be taken at face
| value.
| ilammy wrote:
| > _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...
| yunohn wrote:
| It is possible, but it isn't very feasible right now. Maybe
| in the future?
| eduction wrote:
| 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.
| sleepybrett wrote:
| 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.
| remram wrote:
| The photographs can be retrieved as needed while still
| being encrypted and not impeding text search.
| tetromino_ wrote:
| How do you propose searching the content of your
| photographs and diagrams? ("Show me notes with gardening
| photos")
| remram wrote:
| What scheme would you use for searching the content of
| your photographs _that requires the full photograph blob
| to be available for search_?
| tetromino_ wrote:
| 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.
| saurik wrote:
| (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.)
| chrismorgan wrote:
| 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".
| thrwawy74 wrote:
| We've been hearing about homomorphic encryption for years, but
| I haven't seen it applied in a very practical way.
| polygamous_bat wrote:
| 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.
| Anunayj wrote:
| There was a pretty neat recent post on a pratical
| Homomorphic Encryption project [1]. Maybe not practical,
| but pretty cool nevertheless.
|
| 1. https://news.ycombinator.com/item?id=31668814
| badrabbit wrote:
| Homomorphic search is a thing, new "web3" stuff shouldn't even
| store on a server, servers become app hosters and routers
| basically.
| basilgohar wrote:
| > 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.
| lasereyes136 wrote:
| > 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.
| trinsic2 wrote:
| 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.
| fastball wrote:
| 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.
| trinsic2 wrote:
| 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.
|
| My 2 cents.
| klabb3 wrote:
| 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.
| threeseed wrote:
| > Our team will never read or access your note content, unless we
| have received your express permission during a customer support
| interaction
|
| 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.
| xoa wrote:
| 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?
|
| ----
|
| 0: https://news.ycombinator.com/item?id=32562294
| Shank wrote:
| > 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.
| tshaddox wrote:
| 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.
| panick21_ wrote:
| 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.
| tshaddox wrote:
| 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.
| panick21_ wrote:
| And I disagree, one is much harder then the other.
| hedora wrote:
| > _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.)
| orthecreedence wrote:
| What? Any cloud-based e2ee app has this property and is
| perfectly legal in the US, at least for the time being.
| coldtea wrote:
| > _> 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).
|
| /s
| LtWorf wrote:
| At this point, why even trust random corporation when they
| claim to be doing end to end encryption with some proprietary
| client?
| tobeagram wrote:
| 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.
|
| [1] https://supernotes.app/features/friends
| orthecreedence wrote:
| 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.
| klabb3 wrote:
| 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?
| pclmulqdq wrote:
| I'm not sure that social sharing of knowledge is what I want
| from a "notes" app. That sounds more like a text-based social
| media app.
| dominojab wrote:
| [deleted]
| nibbleshifter wrote:
| The important part:
|
| > 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.
| longrod wrote:
| Have you tried Notesnook [0]? It's pretty good and going open
| source this month.
|
| [0] https://notesnook.com/
| orthecreedence wrote:
| 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).
| yokoprime wrote:
| I don't really care if anyone reads my todo.md and notes.md to be
| honest. But if I had to choose, I would choose end-to-end
| encrypted.
| amadeuspagel wrote:
| > In the end, trust is Still Required(tm)
|
| This entire section is FUD. Trust is "Still Required(tm)" -
| 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?
| fastball wrote:
| 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?
| amadeuspagel wrote:
| 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.
| longrod wrote:
| 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.
|
| [0] https://vericrypt.notesnook.com/
| jcynix wrote:
| Hmm,
|
| 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.
| blfr wrote:
| 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.
| secretary-horse wrote:
| How about the ease of use and storage?
| RedCary228 wrote:
| I'm sure ease of use would decrease if they introduce E2EE
| bdominy wrote:
| 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.
| dirty_wipes wrote:
| lasereyes136 wrote:
| Contrary to Betteridge's law
| https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline... I
| would say the answer is maybe. Sure there are cases where it
| might make a big difference. Most cases it will not.
|
| 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.
| lenova wrote:
| Standard Notes is a note taking app that provides end-to-end
| encryption:
|
| https://standardnotes.com/
| hedora wrote:
| It's the best cross platform one I could find a few months ago.
| Its conflict resolution isn't great.
|
| Looking for a replacement that handles write-write conflicts
| better.
| longrod wrote:
| Maybe try Notesnook[0]?
|
| [0] https://notesnook.com/
| orthecreedence wrote:
| Avoid Turtl for now, it's e2ee but last-write-wins at the
| note level. I'm exploring moving to a CRDT model sometime
| soon.
| jacooper wrote:
| Also it supports creating blogs from your notes
|
| https://listed.to/
|
| And you can self host it too
|
| https://github.com/standardnotes/app
| upofadown wrote:
| Why the mention of forward secrecy? You can't be off the record
| when the whole point here is to make a record.
| TheRealNGenius wrote:
| 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.
| jrm4 wrote:
| Bigger question for me.
|
| 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.
| Johnny555 wrote:
| _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.
| jrm4 wrote:
| But with an app that doesn't use a 3rd party, you don't have
| to much worry about E2EE at all, as I understand it. E.g.
| Syncthing + Markor.
| Johnny555 wrote:
| 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.
| jrm4 wrote:
| 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.
| upofadown wrote:
| 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.
| personjerry wrote:
| Pretty sure this is a clickbait ad
| wartijn_ wrote:
| 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.
| samsquire wrote:
| 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.
|
| 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
| swah wrote:
| 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.
| XorNot wrote:
| This is why I just use Markdown and Syncthing. Works on every
| platform I have including my phone and for more then just notes.
|
| I really don't like every app reimplementing secure block storage
| and exchange or whatever.
| trinsic2 wrote:
| Thanks for that. Been looking for something like this for a
| long time.
| EGreg wrote:
| 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.
| crabmusket wrote:
| Client must be open-source, and clients and servers must be
| interoperable.
| EGreg wrote:
| 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.
| longrod wrote:
| 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.
| makach wrote:
| Yes. Encrypt everything everywhere always. It's easy.
| adastra22 wrote:
| Great explanation of end-to-end encryption, followed by "but
| we're too lazy to do that."
|
| Not going to ever touch Supernotes now.
| fastball wrote:
| 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.
| vbo wrote:
| 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.
| fastball wrote:
| 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.
| samsquire wrote:
| 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.
| vbo wrote:
| > Why should they listen to voices on the internet who
| aren't even their customers?
|
| People tend to exchange and discuss ideas on HN and this
| is no different.
| hammyhavoc wrote:
| Beware the trickledown effect of who recommends software to
| non-techies.
| panick21_ wrote:
| I would not use your app, but I understand the choice. Most
| important thing is to be honest about what you are offering.
| samsquire wrote:
| Why do you say that in such a tone as if to inflict spite?
|
| If you knew how hard it was to write E2EE you would be more
| respectful of others honesty.
| danielgh7 wrote:
| A+
| tailspin2019 wrote:
| I think I would have only awarded an A+ if the conclusion was
| that their notes are actually E2EE encrypted!
|
| Good explanation though.
| svacko wrote:
| 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)
| tekchip wrote:
| 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.
| puszczyk wrote:
| What should they charge for then?
| remram wrote:
| They seem to charge $60/year for markdown (free plan only
| has plaintext). I wouldn't even want to evaluate it.
| amadeuspagel wrote:
| What if the entire app is behind a paywall, no free version
| at all? Is that also wrong?
| jan_Inkepa wrote:
| https://standardnotes.com/plans 2fa looks to be in the free
| plan now, fwiw. (long-term standard notes user here)
| imwillofficial wrote:
| I did not enjoy the attitude displayed in this article.
|
| Yes, notes, often containing the most sensitive material of our
| lives should be encrypted at every stage of the lifecycle.
| hammyhavoc wrote:
| 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.
| longrod wrote:
| 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.
___________________________________________________________________
(page generated 2022-08-23 23:01 UTC)