New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update unknown device warning logic #11750
Comments
sgtm. i don't /think/ we're killing off blacklisting ftr |
The other complication here is how this interacts with both the setting we currently have ("Never send encrypted messages to unverified devices from this device") and the new one ("Never send messages to untrusted sessions"). The new settings will come later, so for now this describes how sending messages interacts with the old flag.
|
Mostly note to self: the js-sdk doesn't have the tools to do this right now, since an unverified device from a verified user would just go back to 'unverified, unknown' which would be the same as an unverified device from an unverified user. |
When cross-signing is enabled, we no longer want to fail and prompt the user to ack every device in the room. All the info should be conveyed in the shield colour (although isn't fully just yet). Fixes element-hq/element-web#11750 Requires matrix-org/matrix-js-sdk#1150
@dbkr, does your PR implement "room has green or black shield: send only to verified devices", or is that future work? It seems like it only disables this existing warning when cross-signing is on...? |
yep, with the paranoia flag on it will only encrypt to verified devices as it did before (in this case it just doesn't send keys to them rather than erroring) |
With cross signing flag off, everything should stay as it is currently. With cross-signing on, send keys to all devices (except blacklisted ones maybe?) Note: there will be a "Confirm before sending messages to untrusted sessions" toggle which will cause a dialog like this if turned on, but this can come later (and the dialog will probably be sufficiently different that we won't want to re-use the old one anyway).
Edit: this tracks the target behaviour before implementing new settings. For after, see #11808
The text was updated successfully, but these errors were encountered: