Make option for disable E2E encryption on DMs by default and on room creation dialog #13539
Comments
MurzNN
changed the title
|
This is really important for corporate environments. We have about 200 users and no way we're going to verify each other just to be sure the private conversations can't be read in our own database (every user would need to verify 199 other users, that's borderline insane). It's very redundant for any private installation and without that there are confusing popups about untrusted devices every time you send the first message to a new conversation room. My suggestion is to revert encryption by default or at least provide the same toggle that's present in the room creation dialog (these two are technically the same anyway). A better way would be to control this default from the server side as a Synapse config option. This way we'd be able to set it for all our users universally and don't tell them to switch this option off every time they start a new conversation. Or make it a Riot option that can be turned off once but in this case we'd need to do that at every workplace. I understand that privacy is important but Matrix isn't only used on the Internet and I don't see how there might be a compromise between security and usability in a corporate environment with hundreds and thousands of users. For now I guess we'll have to stop updating Riot to prevent this antifeature from spreading. |
https://github.com/matrix-org/matrix-doc/issues/2528 |
That's slightly different while it's also important. I don't propose to prevent using e2ee completely, only to disable it by default. These requirements might be different in different companies so both are important. But being able to tell the clients of the home server not to force e2ee by default would be just great. I wonder how the French government (the most well known big private Matrix instance) would react to this enforced encryption now that they'd need all their workers to verify each other. They'd need to dedicate a day or two just for that process alone. |
|
I added to my post on matrix-org/matrix-spec#616 to include extra options for the variable. Enforced off, default off, default on, enforced on. Which I believe covers your use case as well. |
|
A good workaround for this issue for now, at least that I've found, is to create a new empty room with encryption turned off, invite in whoever you want to talk to, and then change the room to a Direct Chat. This moves the room up into the Direct Messages section of Riot and seems to restore the functionality of a normal DM, minus encryption. Correct me if I'm wrong on this...
|
|
Yes, I did the same. The problem is all these extra steps that are not obvious for an average user. Also, I forgot about another huge issue: bots. You will not be able to chat with bots 1-on-1 with this enforced encryption because AFAIK there's no support for encryption in all popular SDKs and frameworks. They will still work in public and private multi-user rooms but if you explicitly start a new conversation with a bot chances are your messages won't be processed. You will be able to read the bot's messages but your own messages will always be encrypted and the bot most likely won't be able to decrypt them. |
|
Fully agree here. Most of our users are naive, and don't know/care about e2ee -- forcing key setup at account creation will cause drop-off in usage, and automatically enabling encryption on room creation has already caused us problems setting up rooms with a support bot not yet capable of encryption. Would love an option we can set in Riot of "default off", that does not disable e2ee entirely, but makes new DMs and rooms default to e2ee of off (can be toggled on if desired). Also would like this to skip the key passphrase/download step on account creation, though that might be a separate option? |
|
Yeah, that passphrase step is weird to require for everyone by default. You effectively need TWO password just for chatting, that's too much. I bet new users would set the same password in the best case scenario (which I'd prefer to be the default with the option to set it manually if you need more security). So the main issues that currently I don't see a way to fix properly are:
I seriously don't see how the benefits of secure communication (that protect the messages from the homeserver admins only, they're already protected by TLS from other attacks) overweight these very real use cases and scenarios. Please revert it back and let the users decide. A better UX would be a questionnaire of sorts that pops up on first launch, describes the pros/cons of E2EE and asks if the user wants to enable it by default. |
This is a private vs public server issue. e2ee makes perfect sense for public/federating servers for the users that care about it. But as t3chguy pointed out, this is a spec issue. Server side options need to be established that clients understand and respond appropriately. |
Fair enough. There are not many public servers though, new users would most likely use matrix.org by default and those who are curious enough to change the defaults would rather setup their own homeservers. That was my experience at least, I know there are many public servers in the wild but the list has to be googled, it's not referenced in the client. And if you have reasons not to use matrix.org probably for the same reasons you'd like to run your own server.
Absolutely, that's why such an option can't be added immediately to fix the aforementioned issues. That's why a client-side option and saner defaults are preferred for now. |
Bots and other clients without encryption support should already be handled as part of the implementation: when creating a new room, we first check if the other users being added to the new room have at least one device that has uploaded message keys as a proxy for "can this account use encryption". Room encryption only defaults on if that test passes. If you have observed different behaviour, that's a bug and should be filed separately from this issue. |
@jryans there's an ecosystem issue with bots where the first thing most people do is register the account for the bot with riot, which uploads keys. They then use the access token/credentials in their bot, which doesn't support encryption. It's unclear how people who have got themselves into this situation (myself included) should correct it :( |
Aha, perhaps we should craft a best practice approach to registering a bot account that is both easy and does not send up message keys and signal encryption support... Either way though, I think the bot situation may deserve a separate issue, as it seems like we'd improve it through targetted fixes specific to that case that may look very different to the core suggestion of this issue. |
|
https://github.com/vector-im/riot-web/issues/13644 for the bots, with a bit of additional context. |
|
This is a really painful situation that really could use a quick fix (even a config option in config.json would be helpful in the short term for web clients anyway). The combo of
has led to a an avalanche of support requests from all user skill levels on the private corporate servers I admin, demanding I turn off the default-on E2E encryption. I cannot do this though, and the answer "all DM's being E2E is actually what is in the spec" has not satisfied anybody I've told that to. Common sense for the users (I know, I roll my eyes too, but that doesn't invalidate their experience and them being right) is that: this was working up until the last release and I just want it back like that. I understand where they are coming from there, even as I also understand the laudable goal of baking strong privacy into the server spec. But... having deployed it already and having live business users who are used to a certain behavior.... it's very difficult to now force what is seen by everyone as a downgrade upon them. Suddenly for the first week since we migrated off Slack, people are bringing that S word again and we definitely can't have that! It's unclear whether client-side E2E search is working now in the latest releases, I will test that tonight in hopes that will alleviate some of the pain. The major complaint seems to be about the key backup dialogs rather than the search, but I suspect it just hasn't been long enough for people to notice the missing search functionality. Anyway, my story is another hopeful +1 for a way to make this a configurable default somehow, or have some kind of path backwards for admins in my position. I totally understand the rationalization for the change, but since there are probably many deployments like mine out there with users confused/upset, I think it would be good to have a way back to the previous behaviour, even if it didn't have a UX option and is not yet fleshed out in the spec. I'd be happy with patching my vector source and tell desktop users "too bad, use the web client" if that is the only option, and then providing instructions for others to follow. I'm also happy to help out and figure out a proper patch to make it configurable, if that would be helpful (but I am totally unfamiliar with everything so it may be easier for someone to just do it if it's a one liner type thing). |
|
@damienvancouver if you're okay with using the web client you can compile the older version yourself as I did. Use these versions:
I fully agree this experience is extremely painful for non tech-savvy users, I wasn't even aware that they're going to force E2EE, all I heard is something about cross-signing and enabling E2EE by default which is a rather different approach (I expected just a switch in the room creation dialog turned on, not removing it completely in an "always on" state!). If I knew they went this route I'd at least voted against it before the release even though my voice matters barely more than nothing. Now it's a disaster and it's good that I noticed it early, before everyone upgraded so we issued an internal memo for the users not to upgrade. I'd very like to hear some thoughts from the actual developers. What do you plan to do with all this? Is it gonna be a "WONTFIX" or something better like a rollback, a client-side setting, a separate update channel for users who explicitly don't need E2EE? Is there any feedback from other corporate users like governments? |
We're actively looking at this in detail. We started looking first for quick fixes, like the
We're trying to find something that satisfies all of our requirements, front-loading quick fixes once we've de-risked them for the long term. Every potential solution has tradeoffs, which we're working through and hope to have resolution on soon. |
|
Thanks for the answers! Regarding mobile clients, don't forget that the original Riot for Android is still the most used one (my guess) because it has the most features. There's no VoIP in RiotX yet, no i18n as well (which is very important for corporate users, not all of them know English, in our case it's like 99% don't even know the English alphabet). So until at least these concerns are solved we can't switch to RiotX. Enabled E2EE causes these verification popups in the classic version and that's ugly. I know that verification is now optional in 1.6.x web/desktop versions (so it's not annoying) but not in the classic mobile version. And the classic version, as I understand it, no longer gets any new features. I do believe this decision to force E2EE is rushed because of all these issues. Maybe first finish implementing the major features in the mobile clients and only then turn E2EE on? In the meanwhile make it optional again and polish the experience so it's as painless as possible when the time comes. I mean it worked fine before so why not revert the UI back, let people use Matrix/Riot as they used to, fix the UI/UX issues, reach feature parity between RiotX and old Riot and then when most people use the current versions try it again? |
|
@rkfg there's a lot to unpack re the original Android app & RiotX, which would largely fall outside of the scope of this issue, but what I would say is:
|
|
I would think a reasonable starting place that should be relatively easy to implement is simply a config option for Riot Web, e.g. in config.json. There are already options there for things like sending presence notifications, custom home page, homeserver, labs settings, etc. For a company environment, it seems reasonable to me to say, "use this Riot Web URL" and expect most users to just log in there and pick up the defaults. Or to bundle up a custom Riot desktop with the config baked in. And also can say "Create rooms using Riot Web, not your iOS/Android". You can always train more advanced users who push back to disable encryption in their mobile app... There's certainly room for improving the entire scheme here, but just a "simple" config setting for a self-hosted Riot.im would be a huge improvement over what we have today, and likely meet the needs for most of us who are currently dealing with this issue! |
Unfortunately, outside an enterprise context, some of the most basic users actually only use their phones, and so only the mobile apps... |
|
Done, documented by #13914 |
@dakotawhitevalley Is it even possible to do this any more using Element? |
|
@myii this is off-topic for this CLOSED issue. but yes there is |
This comment was marked as spam.
This comment was marked as spam.
and others
At now on last 1.6 release Riot forced enabling E2EE by default in all new DMs rooms, without any way to disable it and without warnings, that users will lost server-side search in those rooms.
So please make an option to disable E2EE in new DM room dialog, with proper description of E2E limitations (no server-side search, no support in some Matrix clients, no way to disable e2e later in this room, etc).
Also please add option to Riot's
config.jsonto disable E2EE by default in DMs for all users (with ability to enable it manually, if needed for current room).The text was updated successfully, but these errors were encountered: