Rethink the decision to enable e2ee by default in 1-1 chats #310
Comments
This just isn't true, only messages sent whilst you have 0 logged in devices will be undecryptable.
is already possible using dehydration just isn't exposed to the user at this time. |
Okay, then say that instead (as I said in other places in my issue).
Then it's irrelevant. Anything that isn't available to users is not part of the software. If it gets added as a supported feature that that would (if I understand you right) resolve this with option 3, although as I said I don't consider that the best solution. |
|
I agree that it is confusing. I think the encryption key should prompt to link to a cloud account with google drive/OneDrive in setup and be automatic to read/write from. It will be much more user friendly. |
|
I would strongly prefer solution 1 over everything else. Every user who wants e2ee should have the possibility to do so, but it shouldnt be the default. |
|
Even though I consider myself an "advanced user", I lost a bunch of encrypted history to how Element and e2ee operate. Besides logging out, it is too easy to lose the browser profile and say goodbye to my Element device/session.
Just having other logged in devices/sessions is not enough because they don't always share the keys.
Offline key backup is PITA in practice: you have to do it manually and frequently, like daily, and in a perfect universe after each sent/received encrypted message. And if you forget to do it and lose the session(s), the history since last backup will be undecryptable. I tested this negative path and it didn't feel good. Oh and the key blob grows quickly and I wonder at what size import/export will start falling apart. Will it still work at 50 MiB? 100 MiB? "Online key backup" sounds just sad for users with higher requirements. "Cross-signing" too, until "private keys stored on the server" issue is fixed (it was described in the May 2020 blog, search "on the server"). Most of my sad experiences with Element/Matrix boil down to losing access to history. A big part of it was due to using it via the browser with all its state fragility. So one direction is to reduce that fragility with the solutions suggested in the first comment. As a part of that, one simple thing I suggested is to make it easy to create unencrypted rooms (#16827). Another direction is to switch to proper desktop clients that just don't lose state too easily. This is what I plan to do eventually, the problem is all clients are either too fat or are not mature enough. I hope that a non-bloated but e2ee-enabled client will show up one day. One idea for Element and the community is to promote proper clients over browser clients because real clients are better in everything (security, privacy, reliability, speed, UX) except "automatic software installation and updates" (the only reason to go "web apps", imo). Finally, an approach that cuts the problem at its root is to stop relying (and training users to rely) on very complex encrypted server-hosted history. With decades-old IRC and XMPP clients I have chat history in my local text files, I can search/encrypt/do whatever I want with it. Plaintext history text files are also trivial to host on a static server and it is done for many IRC chat rooms today. And for archivists these text files are trivial to download and mirror. In other words, in terms of practical history access, Matrix is currently less decentralized than IRC and XMPP. And current encryption dance is only making it worse. The straightforward solution is to make it easy to save unencrypted history. This cannot be done with seamless UX in browser clients, but export feature is a good workaround (#2630). For desktop clients it is just a common "save logs" checkbox. |
If you verify your own devices then they will gossip keys securely between each other even without Secure Backup enabled. |
|
The main thing from my perspective is that e2ee as default should be the very last thing that happens in terms of e2ee rollout. When e2ee is working great in every situation and no one is ever losing any messages, then we can think about making it the default. Making it the default before all these wrinkles are ironed out was premature. E2ee remains broken from a usability perspective and shouldn't be the default until it works transparently and painlessly across all use scenarios. |
|
Hi! This is my first ever post/comment on Github and while I've only discovered the matrix protocol last year, I'd like to put in my 2 cents. I think the author brought up a very good point on E2EE being broken from a usability perspective. With the 'Export chats' feature still 'on the way' for Element (There's a GSOC project currently ongoing iirc), the author couldn't be more clear in saying that Users shouldn't come across a scenario where they lose access to their encrypted messages. Online key backups while 'usable', is a feature some privacy minded individuals may not like, but as mentioned it is really annoying if offline key backup has to be something I have to do everyday. However, I still believe that E2EE should be the default setting. Where I come from, the top apps in the country are Telegram and WhatsApp, with FB Messenger not far behind. Element to me seems like the next step forward where E2EE and accessibility to chat messages all seem to be a tradeoff between Telegram and WhatsApp. While it's not perfect right now, I think having the default messages set to enabled is beneficial towards the illiterate user who just happened to switch from one of the main messaging apps. If I were to ask my friends to migrate to Element/Fluffychat now, I can have peace knowing that our messages have E2EE. If we set the default to disabled, then these same illiterate users will find themselves communicating in unencrypted rooms they believe to be E2EE. Thus, while broken from a usability perspective, I think having E2EE disabled by default is a step back. All in all, I believe that privacy is a right, and that E2EE should continue to be set to default to help users be confident that their right is respected. I suggest that OPs second solution is a much better option. Current logout flowLogging off element as of 21 May 2021 gives me this
As discussed above, this isn't a clear enough warning for users to understand the implications of their actions.We should drastically increase the warnings whenever a user attempts to log out or whenever they create a new room. Until we are certain the user knows what he/she is doing, an warning with the appropriate logo should be shown to the user. The example message by OP is perfect for this with minor adjustments. Suggested logout flowIf the user has more than 1 session active, the messages could be Logout screen with more than 1 device active "Warning! Without the right key backup, logging out of all devices may result in permanently losing access to encrypted messages sent. Do you want to log out?" Logout screen with only 1 device active "Warning! Logging out of this device WILL result in permanently losing access to encrypted messages unless you have the right key backups. Are you sure you want to log out?" If the user with 1 device left still attempts to log out, we should have the user authenticate with his password (or with SSO) to show that we mean business. If 2FA is enabled (in the future), we should have also get him to proceed with 2FA authentication. Note: The assumption here is that most users have a more 'permanent' session on at least one of their devices, so having the user continuously authenticate when he still has another session active is a bit excessive to me At both logout flows, we could also put in a Learn more link, so that we can educate the user on E2EE and Online Key Backups. This way, we try at best to guarantee E2EE while informing user of the potential risks of performing said action. Current create room flowAs of 21 May 2021 the create room dialog gives me this
This is also not clear enough a warning to users on the implications of their actions should they leave it enabled. A visible warning showing the implications of communicating in an encrypted room should be clearly laid out. Suggested create room flowWhenever a user creates a room, a general informational warning could be "Messages in this room will be encrypted, if you logout of all devices you may lose access to the encrypted messages. Bots and Bridges may also not be able to communicate on encrypted rooms." Like the suggested logout, a learn more hyperlink(not button) could be linked to the footer of the warning to allow users to educate themselves on E2EE. ConclusionE2EE should remain the default but I believe educating users on how to navigate Element would be how we can get everyone to benefit, and if this is so, I'd like to be a part of making this happen in the different platforms (since I'm on my summer break now) Sidenotes:
After the user is invited, the room created will be unencrypted by default (this is understandable as the user may sometimes chat with bots who may not be able to speak E2EE. I think we should have a button to allow the user to turn on E2EE with the same principles set. EDIT: I just learnt that 1:1 chats will be enabled by default if the other party supports E2EE. The next step forward should be an informational warning like how rooms are created as explained above.
Again, if anyone at element sees this and believes that this makes sense, please reach out to me because I'm willing to do my part to contribute to this amazing community. I can't wait to bring my friends over to the matrix --John Francis Sukamto @jack_hq1:jfsinterchange.tech or @jack_hq1:matrix.org Twitter: @jack_hq1 |
|
I largely agree with your message. The problem is not that E2E is on by default. The problem is that the user is not told enough information about how E2E works to be able to use it. People just think E2E is broken because they don't have know why it doesn't work sometimes. Element needs to put more information in the interface and I think they should also write a detailed user manual. Just wanted to correct one thing:
It is true that there is no setting here but it is not unencrypted by default. If the user you are creating a chat with is logged in to a client that can do encryption then it will be encrypted by default. If they are not logged in to any E2E capable clients then it will be unencrypted by default. There is a button to enable encryption in the room settings. |
|
I agree with most of your suggestions about better messages and so on, but I don't agree that they mean e2ee should be on by default. As I said before, enabling it by default should be the last thing done. If any of the problems you describe with messaging, documentation, etc. exist (and they do), then e2ee should not be on by default. When we go six months without one person needing to ask "how do I recover my messages from an encrypted room after logging out" then we can think about turning e2ee on by default. I also want to just respond to one point you made:
Whether privacy is a right isn't really the issue. Even supposing it is a right, it's still the user's prerogative to exercise it or not. Respecting a user's right to privacy means enabling them to keep their conversations private, not forcing them to do so. Also, if we want to talk about rights, I would say an even more basic right is the right to never lose access to your messages without explicitly discarding/deleting them, and that is currently not provided due to the problems mentioned above. |
|
The thing is even if you are right that it shouldn't have been turned on by default, it already happened. They turned it on by default, made blog posts about it, people have been using it, and so everyone expects it to be on by default. How could they possibly turn it back off now? If they turn it off now then a huge number of people are going to be more confused and will lose trust in the app. The only solution at this point is to improve encryption. There is no time machine. |
|
Two options:
|
|
Here are several other issues that all arise from the failure to get e2ee fully working before deploying it: element-hq/element-web#12275 Why was e2ee enabled without first resolving all such issues, and why is it still default even though some of them are still open (in some cases after 3+ years)? |
That's not realistic considering how software development works, especially not a commercial one. Element's got to work with limited resources to achieve so many things at once, while E2EE is one of them, a customer can see UX, server flexibility, or things like Spaces as as important, or more. This matters, because Element opens itself up for sponsored and commercially-requested features, alongside community and general features. E2EE is "fine as it is", yes, it has a lot of problems, but there's not much resources to warrant such a big impulse of "working on it". Right now the overall arching effort is to finish and ship spaces, then the next thing can be done (which to me either looks like threading or voice messages) visible on the roadmap. From a business perspective, these problems are fixable, but not critical. I think this'll continue to be the case for as long as Element has a backlog, because a backlog means that things have to be prioritized, and more often than not it's going to be things that paying customers will care about (mozilla, french gov, etc.) |
|
Here is yet another instance of a user questioning whether matrix is usable for them because they will not be able to receive encrypted messages while logged out. It is not a rare occurrence for people to come on the Matrix HQ or Element rooms asking why they can't see their messages after logging out. This is not a corner case. It is a major issue for Matrix usability. |
|
@BrenBarn when classifying it as "major", please show that a majority of users experience this problem. |
SimonBrandner
added
the
O-Occasional
|
I completely agree with BrenBarn's sentiment and proposed solution and the fact that this is seemingly swept under the rug honestly keeps me from committing my business to this platform in the long-term. The fact that you can't even create an unencrypted DM in Element (without fucking around trying to make an unencrypted room look and categorize like a DM) is mind-boggling. |
Do not disable e2ee, at all, ever. |
What you call a bug is indeed a feature. |
Oh, and losing chat because key management is still a clusterfuck is also a feature I suppose? Completely unacceptable. |
As with all software, RTFM. |
|
I'm just going to dump here several cases of people being confused by this. These are just a few cases that I happened to notice and was able to find by searching my own Element history for about five minutes. This. Is. A. Major. Problem. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Instead of spamming everyone's mailbox each time you feel like posting an additional link, I suggest you make use of the edit feature. |
|
I would strongly disagree with disabling E2EE by default. Most users are not aware of the implications that comes with disabling encryption, especially in decentralized systems, where there is no central institution being a single attack vector with huge amounts of money and a reputation to lose, but we rely on homemade server administrators protecting our data. But I agree that most Matrix clients make it too easy to create encrypted chats without having backed up your keys. And we should not rely on users thinking about that. So I propose the following (following "don't rely on the user" and "do not decrease privacy & security by default" and "don't warn users when they are safe"):
|
|
This, we shouldn't consider disabling E2EE by default, we should fix E2EE, and educate users. I'd rather have Element take the stance that state/hostile surveillance is real, and protect its users, than ignore it's existence, and expose all users to it, in exchange for some minor UX improvement and user's ignorance in what they could do to protect themselves. Encryption is not meant only for those who are actively aware of it, but also for those who don't, especially for those who don't. |
Description
This issue is really an Element meta-issue across all platforms.
The problem is that logging out of all devices results in any e2ee messages sent during that time becoming permanently unreadable, and this is not made clear to users, as evidenced by periodic questions from new users on the Matrix/Element rooms where people are surprised to find that logging out makes this kind of massive difference. (See also element-hq/element-web#14820.)
There are several possible solutions:
1. Do not enable e2ee by default, ever.
I find this the most appealing option. Anything that can ever make any messages permanently unreadable should not be enabled by default. I feel that the decision to enable e2ee-by-default was made without adequate consideration of the magnitude of this failure mode. Logging out is a completely normal thing to do; irrevocably losing messages is a complete code-red faceplant; that the one can lead directly to the other is a major problem.
2. Drastically increase the warnings before logging out and before turning on e2ee
Right now when you go to log out from Element you just get a confirmation dialog saying "Are you sure you want to sign out?" It should be much scarier. It should say something like "Warning! Logging out of all devices may result in permanently losing access to messages sent while you are logged out. Do you want to log out?" Perhaps it could show a summary of currently logged in devices to help the user make the decision.
The point is that anything that can lead to permanent message loss is a major decision and should be signalled as such. Either logging out is a fairly normal user action, or logging out can lead to permanent message loss; it can't be both.
A similar warning should be displayed before turning on e2ee in any room. If e2ee remains the default for 1-1 chats, a similar message should be displayed before starting a 1-1 chat (e.g., "Warning! Any messages in this chat may be lost if you log out of all devices. If you don't want this, disable e2ee with this button...").
3. Consider some kind of intermediate level of e2ee that does not have these problems
I've not delved into the details of Matrix's encryption algorithms, so I don't really know what I'm talking about here. But my understanding is that the can't-log-out problem arises because messages are encrypted with specific keys for each logged-in session, and these keys change frequently so a logged out device will "miss" the necessary key rotations. An alternative would be to allow some kind of "placeholder" session, where when you log out on a particular device, it "freezes" an encryption key for all messages received until it logs in again, and stores the needed decryption key on the device, so when it logs in again the device itself has all the necessary information to decrypt messages left on the server in the interim.
This would provide a lower level of security, but for most people it would likely be enough. (In fact, most people probably don't need e2ee at all, which is why I think I prefer option 1.) Most people are probably fine with accepting some risk of unlikely snooping modes (e.g., their homeserver operator is malicious and tries to crack the stored messages) in exchange for being able to freely log in and out whenever they choose.
Conclusion
The main point that I want to reiterate (even though I know I've reiterated it a number of times) is that permanent message loss is a doomsday scenario for a messaging system. It is bad enough that it is even possible, but might be acceptable in cases where the user explicitly accepts the tradeoffs (e.g., for greater encryption secrecy). But to enable it by default is just a bad idea; it makes it way too easy for people to lose their messages without ever even realizing that such a thing was possible.
Most people don't need e2ee to be on by default. For most users, it is more important the intended recipient does see the message than that eavesdroppers do not see the message. This is especially true because, for most users, the likelihood of anyone caring enough to eavesdrop on their messages is very low.
The text was updated successfully, but these errors were encountered: