Allow homeserver to disable encryption in Element Pro

[jmartinesp]

Content

Add force_disable_e2ee support in the Element well known retriever and cache.

Use it to disable creating rooms with e2ee enabled or enabling encryption in existing ones.

Motivation and context

Allowing a homeserver to disable encrypted room creation and disable enabling encryption in an existing room in Element Pro clients.

Tests

• Hardcode DefaultSessionEnterpriseService.isEncryptionDisabledByHomeserver to return true.
• Open an existing non-encrypted room, check the security settings screen doesn't contain the 'enable encryption' toggle.
• Try creating private rooms and DMs, both should be unencrypted (without this, they would be encrypted by default).

Tested devices

• Physical
• Emulator
• OS version(s): 15

Checklist

• I am aware of the etiquette.
• This PR was made with the help of AI:
  • Yes. In this case, please request a review by Copilot.
  • No.
• Changes have been tested on an Android device or Android emulator with API 24
• UI change has been tested on both light and dark themes
• Accessibility has been taken into account. See https://github.com/element-hq/element-x-android/blob/develop/CONTRIBUTING.md#accessibility
• Pull request is based on the develop branch
• Pull request title will be used in the release note, it clearly defines what will change for the user
• Pull request includes screenshots or videos if containing UI changes
• You've made a self review of your PR

[github-actions]

📱 Scan the QR code below to install the build (arm64 only) for this PR.

If you can't scan the QR code you can install the build via this link: https://i.diawi.com/i9RrzH

[codecov]

Codecov Report

❌ Patch coverage is 90.90909% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.54%. Comparing base (03304b3) to head (e738c88).
⚠️ Report is 11 commits behind head on develop.

Files with missing lines	Patch %	Lines
...enterprise/impl/DefaultSessionEnterpriseService.kt	0.00%	1 Missing ⚠️
...ndprivacy/impl/root/SecurityAndPrivacyPresenter.kt	66.66%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #7198   +/-   ##
========================================
  Coverage    80.53%   80.54%           
========================================
  Files         2730     2730           
  Lines        78927    78943   +16     
  Branches     10695    10696    +1     
========================================
+ Hits         63567    63581   +14     
- Misses       11222    11223    +1     
- Partials      4138     4139    +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bxdxnn]

I think basically any deployment that trust its own server would want this feature as well? Why is this Element Pro?

[jmartinesp]

I think basically any deployment that trust its own server would want this feature as well? Why is this Element Pro?

I think Element's strategy is using E2EE chats as much as possible, this is mostly a workaround to allow some customers to upgrade their Element Classic users to Element X, and we made it this way mainly because we didn't think community users would be interested in it and because it's way faster than adding an MSC for it, but I don't think we'd be against implementing a proper MSC with a similar goal if it existed (cc @mxandreas maybe?).

[mxandreas]

Yes, our goal is to generally optimize the clients for E2EE (Pro or not) as optimizing for "everything" tends to lead poor experience for everybody or a more complex product that is harder to understand, configure, maintain and further enhance. Having said that, we don't of course do anything intentionally to just block non-E2EE usage - this only applies when we have to make compromises.

Therefore, yes, we do not want to put the disabling of E2EE into our clients generally - it is rather keeping backward compatibility with what existed before for those who have paid for that in the past.

[bmarty]

LGTM, thanks!

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud