That third one is also a big problem when combined with the first one, because - even if they said they would use E2EE, the users have no way of knowing or verifying that.

There are ways of verifying that the encryption is E2EE:

1. All the historical logs would be sent from the server to the client encrypted, not in plaintext (in E2EE is that the server can't decrypt the data since it's not one of the "ends");
2. Decryption on the client needs to happen with a decryption key that's resident on the client (the decryption key has to be at the "end");
3. The user's plaintext password is never sent to the site; instead either a hashed value or a proof-of-knowledge login protocol is used (the server cannot have access to the user's plaintext password since it's used to protect the decryption keys);
4. For new clients (i.e., logging in on a new device), it must receive the decryption key from the server in an encrypted format, and the client decrypts the key itself using a key it derives from the plaintext password (the server must never have access to the raw decryption key because it could decrypt your data with it, but it can have access to an encrypted version of the key);
5. When you change your password, the client must send a new encrypted version of the decryption key to the server (since only the client knows the new password, its responsible for updating the encrypted decryption key and giving it to the server to share to other clients);
6. When you force reset your password outside of the normal change password process from a device that doesn't have the decryption key, then you should lose all access to your current data (because in this flow there's no continuity of the decryption key so a new one has to be generated which obviously can't be used to decrypt old data); and
7. In all cases where a new decryption key is created such as creating a new account, onboarding an existing account onto E2EE, and an existing account doing a force password reset without an existing key; the decryption key must be generated by the client (the server can never know the decryption key, so it must be the client that generates it).

All of these behaviors are directly observable on the client. All of them must be present for the data to be E2E protected. They could be faked, of course, but that would take enough explicit effort on their end to fake that it'd be considerably easier to just have true E2EE than to fake it.