MSC1544: Key verification using QR codes #1544
Conversation
|
Can we not reuse the "Interactive Key Verification" method, and simply have the QR code used to set the user and device that is being verified? |
Possibly, but if we're scanning a QR code, it doesn't inconvenience the user to also throw in the key data. Also, the interactive key verification is more complicated, and so people may implement this before implementing the other. |
My main concern is basically being able to reuse the same method for other QR code style mechanisms, but I take your point. I was hoping that we could split up IKV into two steps or something, so that you could reuse some of it when you already had a shared secret |
| @@ -0,0 +1,375 @@ | |||
| Bi-directional Key verification using QR codes | |||
There was a problem hiding this comment.
Unfortunately soru sees several issues with how this proposal is currently layed out:
1st: It does not seem to be in-line with the current spec. Sending m.key.verification.start is supposed to start the verification process, here QR codes are displayed (and thus the verification process started) before that is sent.
2nd: If both sides of the verification advertise as being able to be able to both scan and display a QR code, we get a problem: As there is no additional message exchanged on what was agreed to verify with, it could happen that both get a QR code displayed or both get a camera to scan the others code. While a button could be introduced in the UI to switch between scan and display, this scenario will likely leave many people baffled and "meh, this is broken" and then not verify each other
3rd: There is no real way to do SAS instead of QR code verification: As QR codes are displayed / scanned after receiving m.key.verification.ready, it is impossible to pick e.g. SAS instead of QR code verification. While a button could be introduced for "Oh no, I actually want to do SAS" this is bad UX.
4th: This is not future-proof: Let's say in the future an even more seemless verification method is introduced (background bluetooth/NFC or something between two phones?), how should this be started? Also before sending m.key.verification.start? What if both can do the new method and QR code? What if one displays the QR code and the other one expects to do the new method? The user is likely to think that the verification process is broken, even if there is a button to switch between different methods.
5th: This diminishes a big advantage of #2366 : One point of #2366 was to introduce m.key.verification.ready so that both parties can pick which verification method to use, if e.g. one of them is more tech savvy and uses a more tech savvy client. As verification starts prior sending m.key.verification.start this becomes impossible, diminishing its affects.
All these points seem to be fixed by not displaying / scanning QR codes until after an m.key.verification.start is sent, with the method (m.reciprocate.v2 (v2 as v1 is already implemented in many and this is a breaking change to this proposal)) and what the other person should do, based on their capabilities (m.qr_code.show.v1, m.qr_code.scan.v1). Then, after scanning a new message is sent (m.key.verification.reciprocate?) which contains the information currently in m.key.verification.start. With that, all the mentioned issues are solved.
A client can still automatically pick QR code over SAS, for example, but, as the clients agree on what to verify with prior to verifying we diminish the situation that, e.g. in the future, if there is let's say bluetooth verification, and both clients can do QR, bluetooth and SAS, one will pick to do QR and one will pick to do bluetooth. Explicitly stating what is to be done in m.key.verification.start is appropriate here.
There was a problem hiding this comment.
Re-visiting this a bit later, soru would propose the following flow to decide which key verification method to use:
- A
requestandreadyis exchanged like before - Clients can then auto-pick a method (sas, reciprocate, etc.), sending a
start. If a client does this automatically, it should only do so if it was also the one initiating the request. - Any other client can also send a
start. startgets a new, optional, attribute,priority. This is an integer. Higher integer means higher priority. A missing priority is assumed to be 0.- The
startwith the highest priority is picked. If two have the same priority, then the current methods for determening whos start to use are being used - It does not matter if the
start's pick different methods.
This way it is always clear which verification method to display, in addition to allowing the flexibility a pro-user might want.
In most cases, clients would just auto-pick a method, without sending a priority at all. For the QR code scanning, the "Use emojis instead" would then send a start with a priority of 1.
A pro-user could just override whatever method the person they are trying to verify with automatically picked.
There was a problem hiding this comment.
Sorry for not responding earlier. The intended UX for this is that, once verification is accepted, the client displays a screen that shows the QR code and offers to scan a QR code or verify by emoji instead. This is similar to (and probably inspired by) Signal's "Verify safety numbers" screen which shows a QR code, allows the user to scan a QR code, and displays the safety numbers for users to read out. I think that by immediately showing the QR code, this makes it easier for people to verify each other.
1st: It does not seem to be in-line with the current spec. Sending m.key.verification.start is supposed to start the verification process, here QR codes are displayed (and thus the verification process started) before that is sent.
The wording in the spec is maybe slightly inaccurate. m.key.verification.start is the first message sent in a key verification. QR code scanning doesn't need messages to be exchanged, so it doesn't send an m.key.verification.start. I can add a note in this MSC about this. But if a verification method doesn't need Matrix messages to be sent, then we should avoid sending unnecessary messages.
2nd: If both sides of the verification advertise as being able to be able to both scan and display a QR code, we get a problem: As there is no additional message exchanged on what was agreed to verify with, it could happen that both get a QR code displayed or both get a camera to scan the others code.
The idea is that both sides will automatically show the QR code, and offer to scan instead.
3rd: There is no real way to do SAS instead of QR code verification: As QR codes are displayed / scanned after receiving m.key.verification.ready, it is impossible to pick e.g. SAS instead of QR code verification. While a button could be introduced for "Oh no, I actually want to do SAS" this is bad UX.
I disagree that "Oh no, I actually want to do SAS" is bad UX with the way this is intended to work. If you prompt the user for what method to use before doing anything, then you display three things: a button saying "show QR code", a button saying "scan QR code", and a button saying "verify by emoji". If you immediately show the QR code without waiting for interaction, you display three things: the QR code, a button saying "scan QR code", and a button saying "verify by emoji". So the only difference is that you show a QR code instead of a button, which means that the QR code is immediately accessible, and the user only has two buttons to read instead of three.
4th: This is not future-proof: Let's say in the future an even more seemless verification method is introduced (background bluetooth/NFC or something between two phones?), how should this be started?
It would depend on the exact verification method. If it's some sort of wireless thing, the devices could immediately start broadcasting without exchanging Matrix messages. Devices should be capable of broadcasting a wireless signal, displaying a QR code, and showing a couple buttons at the same time.
One thing to note is that even if a client displays a QR code, it is not committed to using the QR code to verify. All the other methods are still available until the m.key.verification.start is actually sent.
There was a problem hiding this comment.
I disagree that "Oh no, I actually want to do SAS" is bad UX with the way this is intended to work. If you prompt the user for what method to use before doing anything, then you display three things: a button saying "show QR code", a button saying "scan QR code", and a button saying "verify by emoji". If you immediately show the QR code without waiting for interaction, you display three things: the QR code, a button saying "scan QR code", and a button saying "verify by emoji". So the only difference is that you show a QR code instead of a button, which means that the QR code is immediately accessible, and the user only has two buttons to read instead of three.
The problem is that with QR code (and possible future methods) the other party does not know what the first party selected, due to no data being transmitted. Clients will inevitebly just show a QR code with a button "ohno, i want to use emojis instead", such as....element-android already does.
What about sorus suggestion of 14 days ago which solves all these issues by transmitting packages of what is actually happening?
As it stands, without advertising to display / scan QR codes we are blocking any future method which could just be automatically started in the future. We will always have to show a QR code by default.
There was a problem hiding this comment.
The problem is that with QR code (and possible future methods) the other party does not know what the first party selected, due to no data being transmitted.
The point is that the first party did not "select" anything. It is just presenting a QR code that is available to be scanned, but does not need to be.
Clients will inevitebly just show a QR code with a button "ohno, i want to use emojis instead", such as....element-android already does.
That's basically how it's intended to operate. Except that it isn't really an "ohno, I want to use emojis instead". It's "you have a choice between having the other person scan this QR code that's already displayed, or scanning their QR code, or starting an emoji-based verification." Though I suppose it's just a matter of opinion how it's viewed.
What about sorus suggestion of 14 days ago which solves all these issues by transmitting packages of what is actually happening?
We don't want to automatically "pick" anything. And sending messages when they're not needed will just increase latency.
As it stands, without advertising to display / scan QR codes we are blocking any future method which could just be automatically started in the future. We will always have to show a QR code by default.
I think that it's unlikely that we're going to add many more verification methods. Maybe one or two more, and it's unlikely that it's something that would collide with showing a QR code. I think having one method (emoji/decimal) for low-tech or not-in-person verifications, one method (QR) for more capable devices is sufficient. Maybe we might add some fancy wireless thing (NFC) but we're getting into diminishing returns territory as I'm not sure what practical benefit that would have over QR codes.
There was a problem hiding this comment.
This spec is future proof - the clients can come up with UX that suits them. If we were to add another method that gets displayed before the start event like QR codes, clients could show their favourite option and have a button for "show QR code instead". Clients could also stop advertising support for QR codes in their methods, thus indicating that they really don't want a QR code.
The signaling of which client is supposed to scan vs show is largely a UX problem for the clients themselves. The verification flows do not care which person scans, so one of the clients is failing to represent its UX properly.
Additional signaling feels more like piling onto a problem than solving one, unfortunately. Clients will end up implementing it wrong or be overly confused as to why they have to stack rank two sets of capabilities.
There was a problem hiding this comment.
This spec is future proof
Not with this MSC. As soon as another verification method is added that can be displayed etc. before any signaling, there will be some clients that disagree if they should display a qr code or the new method. For that you need explicit signaling. And, with explicit signaling under the hood, you can have still exactly the same UX for clients, only with the added benifit that you actually know what is going on. The client will reply to the ready with a start already, with whatever it picked as default. Both sides can still display "use method xyz" instead. the UX is the same, only that you are actually future-proof then.
There was a problem hiding this comment.
It doesn't sound like you're reading the comments we're posting or trying to understand why the system is proposed as it is, and instead repeating the same argument over and over which has been responded to over and over. As such, I'm personally not convinced that this thread is in a state to block FCP on.
There was a problem hiding this comment.
To soru it sounds exactly the same way, as if you aren't reading or trying to understand her comments.
So it sounds like there is some bad misscommunication here. If it helps, soru'd be willing to hop in a voicecall or something to explain better.
There was a problem hiding this comment.
We've discussed this extensively in #matrix-spec:matrix.org and are largely concluding this thread as it currently stands. There's far too many points to cover in a summary comment like this, but the short version is that this MSC is going ahead regardless of this thread and this thread will continue through manifestation of a different MSC which revamps the verification process as a whole. Currently that discussion is being held on an issue until someone has a chance to convert the ideas to an MSC: https://github.com/matrix-org/matrix-doc/issues/2879
|
|
||
| QR codes can also be used by a user to verify their own devices. These examples | ||
| shows Alice verifying two devices, one of them (Osborne2) having cross-signing | ||
| already set up, and the other one (Dynabook) having just logged in. |
There was a problem hiding this comment.
How do we know which device just logged in and which one not?
There was a problem hiding this comment.
The one that has not yet been signed by the cross-signing key is the one that just logged in.
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
| @@ -0,0 +1,375 @@ | |||
| Bi-directional Key verification using QR codes | |||
There was a problem hiding this comment.
While soru knows that she isn't part of the spec core team she is concerned that this isn't addressed properly. Without having more ping-pong game going around to actually know what is going on key verification is not future-proof for when new methods come around.
Soru has discussed alternatives of how the exact same UX could be implemented, with the only difference being that, well, it is future proof.
Just re-iterating this as the MSC is enting FCP and that is something that the spec core team should probably take into consideration.
Co-authored-by: David Baker <[email protected]>
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
|
This has finished FCP and we've talked about the contentious points extensively in the #matrix-spec:matrix.org room - see those threads for details on their conclusion. As such, this MSC is landing as-is though can't be converted to spec until #2366 also lands. It is my intention to propose 2366 for the spec core team's focus for the coming week. We don't really have a label state for this sort of case, so I'm just going to leave it in finished-fcp until 2366 is landed too. |
|
Merged! 🎉 |
Rendered: https://github.com/uhoreg/matrix-doc/blob/qr_key_verification/proposals/1543-qr_code_key_verification.md