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