Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
We do not encrypt messages proactively for invited users who have yet to join. #3821
Comments
ara4n
added
feature
type:e2e
p2
labels
May 5, 2017
ara4n
referenced this issue
Jun 5, 2017
Open
warn users turning on e2e in rooms with invited users that invitees won't be able to decrypt #4190
|
increasing the priority as (proportionally speaking) this is starting to be a major cause of UISIs for me |
ara4n
added
p1
and removed
p2
labels
Jul 19, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ara4n commentedMay 5, 2017
This is a problem for encrypted 1:1s, where it's a common idiom that I'd start a 1:1, make it encrypted, send a secret message, and wait for the other person to accept the invite and answer it -
except right now we don't encrypt these pre-invite messages.
As I understand it, the sender client just needs to check the history visibility settings for a room when issuing an invite, and encrypt appropriately. If the target user doesn't exist or has no devices, then we fall back on #2286 to resolve things.