Hide algorithm from the message about turning on encryption

[aaronraimist]

Fixes element-hq/element-web#8829

Before:

After:

[turt2live]

code lgtm, just double checking with product (and CI)

[nadonomy]

Also LGTM! :)

[ara4n]

might be worth keeping the info around somewhere though (perhaps hidden behind a <details/>)?
what happens if someone sends an m.room.encryption with an unrecognised algorithm? we don't want to claim the room is encrypted if the client then can't actually encrypt for that algorithm.

[uhoreg]

I think the information should still be available in the "View Source" for the event, for those who care about it?

[aaronraimist]

Would need matrix-org/matrix-spec-proposals#2184

[nadonomy]

I think the information should still be available in the "View Source" for the event, for those who care about it?

This seems reasonable. Is it tractable for us to also display the encryption algorithm being used in Room Settings?

[turt2live]

(shouldn't need spec support - we can render whatever we want)

[aaronraimist]

what happens if someone sends an m.room.encryption with an unrecognised algorithm? we don't want to claim the room is encrypted if the client then can't actually encrypt for that algorithm.

This would be something for another issue. This problem already exists.

The room appears to be encrypted (shows icons and stuff) but doesn't let me send anything.

[uhoreg]

I think that for the average end-user, just removing the algorithm is no worse than what we have security-wise, since they don't know what algorithm is right. We should probably have another issue for displaying an error message for when the algorithm is something we don't understand. The room decoration should probably also be something that reflects that we don't understand the encryption algorithm (maybe the same decoration as an unencrypted room?).

So my vote would be to merge this as-is, and create new issues for dealing with unknown algorithms.

[turt2live]

This is blocked on design/product oversight to settle the <details> or no <details> argument.

[jryans]

This is blocked on design/product oversight to settle the <details> or no <details> argument.

I've requested @nadonomy's review in hopes of getting a decision on this.

[jryans]

While chatting more with @ara4n, he would like to have some kind of handling of unknown algorithms at the same time as the propose hiding here. I think he came up with a decent approach:

• When the algorithm is the one we expect (m.megolm.v1.aes-sha2), hide the algorithm as in this existing PR: %(senderName)s turned on end-to-end encryption.
• For anything else, show the algorithm as unrecognised: %(senderName)s turned on end-to-end encryption (unrecognised algorithm %(algorithm)s).

@aaronraimist, could you update the PR to that, if it seems reasonable to you as well?

[jryans]

@aaronraimist, thanks again for working on this! We've decided we want to have this resolved for FOSDEM, so I've opened #3936 with the approach mentioned above. Sorry for the delay in reaching as decision here.