MSC4287: Sharing key backup preference between clients #4287
Conversation
andybalaam
changed the title
turt2live
added
e2e
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client setting value
- Client using value
There was a problem hiding this comment.
element-hq/element-web#29912 implements this in Element Web.
| ## Security considerations | ||
|
|
||
| Unencrypted account data is under the control of the server, so a malicious | ||
| server could: |
There was a problem hiding this comment.
Something that could offset this a bit is strong requirements for clients to announce the setting to users. Either as a toast or dialog or something attention-grabby.
There was a problem hiding this comment.
I'm not sure whether clients should be required to bring this setting to users' attention on sign-in. Could be reasonable?
| * If this event type exists in account data and contains the specified property | ||
| in the correct format, clients MUST use it to determine whether key backups | ||
| are enabled for a user. |
There was a problem hiding this comment.
In the current impl, if there is a key backup on the server, and a matching private key is received (either from another client via secret gossiping or via recovery), do we actually check m.org.matrix.custom.backup_disabled? If so, what do we do if it is set to disabled:true? Do we delete the backup on the server?
There was a problem hiding this comment.
We don't check it anywhere except sign-on in EW.
| When a user signs in: | ||
|
|
||
| * If this event type exists in account data and contains the specified property | ||
| in the correct format, clients MUST use it to determine whether key backups |
There was a problem hiding this comment.
MUST feels a bit strong to me here, and throughout. I think SHOULD would be better?
There was a problem hiding this comment.
Do you have an intuition for why? I'm thinking that if a client supports key backup but doesn't obey this flag it will really confuse other clients, so MUST seems appropriate, but I'm not sure of the conventions here.
|
|
||
| * If this event type exists in account data and contains the specified property | ||
| in the correct format, clients MUST use it to determine whether key backups | ||
| are enabled for a user. |
There was a problem hiding this comment.
| are enabled for a user. | |
| should be enabled. |
There was a problem hiding this comment.
When we say "backups are enabled": do we mean the process of backing up new keys, the process of downloading existing keys, or both?
I guess probably "both" but I think you could make a strong argument that downloading old keys could happen even if uploading new keys is disabled.
There was a problem hiding this comment.
When we say "backups are enabled": do we mean the process of backing up new keys, the process of downloading existing keys, or both?
I guess probably "both" but I think you could make a strong argument that downloading old keys could happen even if uploading new keys is disabled.
I was thinking of both, but your comment makes me think we should only ever opt out of uploading, and downloading should always be on? Maybe that's a wider discussion though.
| As specified, this only affects client behaviour when a user signs in. We could | ||
| specify that clients must watch the value of this account data and dynamically | ||
| change their key backup behaviour when it changes. This would increase the | ||
| severity of the security issues discussed below. Whether this behaviour would be | ||
| more or less surprising for the user is a potential discussion point. |
There was a problem hiding this comment.
It's worth noting that clients should already notice key backup being turned OFF, because attempts to upload new keys start failing. (EW has a NewRecoveryMethodDialog and a RecoveryMethodRemovedDialog, neither of which work very well, but they exist).
There was a problem hiding this comment.
Fixed in 3d926bd except I talked about it being deleted, because I think that is what will cause us to notice, right?
| undetermined and the client should either treat it as off, or make a choice and | ||
| update the value to reflect it. | ||
|
|
||
| ### Behaviour on sign-in |
There was a problem hiding this comment.
Is it correct that we only check the flag on sign-in? Or do we check it at other times too?
There was a problem hiding this comment.
That is correct in the current implementation.
Rendered
I am employed by Element and a Matrix community member. This proposal was written and published with my Element client developer hat on.