Should notes be end-to-end encrypted?
One other major downside of end-to-end encryption: everything <i>has</i> 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 <i>aren’t</i> encrypted, so the <i>explicit goal</i> 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 <i>store</i>) maybe 10GB, maybe only 100MB, but a whole lot more.<p>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.<p>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 <i>any</i> platform with automatic updates, E2EE is fundamentally broken; and, first-party end-to-end encryption is snake oil.