Element-web: Add admin option to disable E2EE for DMs / private rooms (users can still enable)

[jryans]

Add a .well-known option to allow homeserver admins to set the default E2EE behaviour back to disabled for DMs / private rooms (as it was before 1.6) for various environments where this is desired.

This variant would still allow users to enable encryption, so it would only influence the default behaviour.

In more detail, a homeserver admin can add the following to /.well-known/matrix/client:

{
  "im.vector.riot.e2ee": {
    "default": false
  }
}

which will cause the following behaviour changes in Riot:

• [x] When creating a private room
  
  
  
  • [x] The ‘Enable end-to-end encryption’ toggle should be set to off, where users can still enable it
  
  
  • [x] The micro copy should say “Your server admin has disabled end-to-end encryption by default in private rooms & Direct Messages.” instead of “You can’t disable this later. Bridges & most bots won’t work yet.”
  
  
• [x] Riot shouldn’t prompt users who haven't bootstrapped or enabled cross-signing to do so
  
  
  
  • [x] On sign up & login, toasts, banners: all hidden
  
  
  • [x] However, once the user has joined an E2EE room, toasts to setup cross-signing should still appear
  
  
• [x] In the common case, rooms will simply lack encryption decoration as it’s disabled
• [x] If a user joins a room with encryption enabled (e.g. by federation) then they should be decorated using the normal logic
  
  
  
  • [x] (black shields to indicate encryption, green for verified, then red for warning)
  
  
• [x] Riot should decorate account Settings with a warning
• [ ] Show tile similar to the Encryption enabled tile for non-e2ee rooms
  

[jryans]

Please ensure we use a "positive" name for the option that is then disabled to avoid double negatives, so something like e2eeDefaultForPrivateRooms which defaults to true but can be set to false.

[dbkr]

We also probably want the same option to control the verification toasts & dialogs after login / registration: there's no point verifying your devices if you're not using e2e (we may want to keep some form of the 'new login, was this you?' toast to help people notice unusual sign ins, but it would need different UX so I'd suggest this comes later).

[jryans]

We're continuing to discuss and revise the level of configurability to offer to here, so for the moment this is blocked on some product choices. Rest assured this remains a top priority for us; we just need to work out a few more details first.

[turt2live]

@jryans a variation of https://github.com/vector-im/riot-web/issues/13678 might help here

[jryans]

I have updated the issue body to match our latest thinking around using .well-known to control and changes to feature behaviour. This should now be ready to implement.

[jryans]

@jryans a variation of #13678 might help here

Thanks for the .well-known reminder here. https://github.com/vector-im/riot-web/issues/13678 seems to be a more generic things we can experiment with separately, while for this case I think we'll accept a specialised config setting for now to move quickly. I think the ideal place for this particular kind of admin choice is likely something likely https://github.com/matrix-org/matrix-doc/pull/2301, if it someday comes to exist for real. For now, .well-known seems like the best option out of the things that already exist.

[jryans]

Updated issue body to warn in both room creation and account settings when disabled by admin.

[jryans]

Updated issue body to reflect that cross-signing toasts should still appear once you join an E2EE room.

[MurzNN]

Maybe better "default": "false" or "force": "false" instead of "enabled": "false"?

[turt2live]

also I'm hoping the "false" is a typo and meant to be false (boolean, not a string).

[jryans]

Maybe better "default": "false" or "force": "false" instead of "enabled": "false"?

They all seem equal parts okay and possibly unclear to someone. enabled seems to match the way we're thinking about the concept so that's why I went for that.

[MurzNN]

Maybe better "default": "false" or "force": "false" instead of "enabled": "false"?

They all seem equal parts okay and possibly unclear to someone. enabled seems to match the way we're thinking about the concept so that's why I went for that.

If user see "enabled=false", he understand that it will be globally disabled, but users still can enable it, so this option is only disable it by default for DM, that's all.

[t3chguy]

To me enabled implies the other function of enforcing e2ee to be disabled, whilst "default": false gives the actual behaviour

[jryans]

Okay, I'm convinced, will update the spec. 😄 (Oh, I see @t3chguy already did!)

[t3chguy]

Show tile similar to the Encryption enabled tile for non-e2ee rooms

Where should we show this tile? The Encryption enabled tile is shown in place of the m.room.encryption event but in unencrypted rooms there is an absence of that event.

---

Do we additionally want to hide the Verify prompts on login? This seems to be handled by Dave's ongoing work

[t3chguy]

Show tile similar to the Encryption enabled tile for non-e2ee rooms

This has been descoped due to complexity with injecting tiles unrelated to timeline events and will be handled by next week's "Notifications" rework project.