Am Sa., 1. Dez. 2018 um 15:08 Uhr schrieb Maxime Buquet <[email protected]>: > > Hi Standards, > > When trying to implement OMEMO support in poezio, I came across a few > points that make me shiver like chalk on blackboard each time I read > them. > > All 3 points are in > https://xmpp.org/extensions/xep-0384.html#usecases-messagesend. > > > When an OMEMO element is received, the client MUST check whether there > > is a <key> element with an rid attribute matching its own device ID. > > If this is not the case, the element MUST be silently discarded.
This I don’t do and I don’t think it makes sense. Instead I display a 'message was not encrypted for this device' > > > If the element's contents are a SignalMessage, and the client has a > > session with the sender's device, it tries to decrypt the > > SignalMessage using this session. If the decryption fails or if the > > element's contents are not a SignalMessage either, the OMEMO element > > MUST be silently discarded. > > > If the OMEMO element contains a <payload>, it is an OMEMO message > > element. The client tries to decrypt the base64 encoded contents using > > the key and the authentication tag extracted from the <key> element. > > If the decryption fails, the client MUST silently discard the OMEMO > > message. > > Can anybody explain why as a library dev I would want to silently > discard messages and not let the end-users know they just lost messages? > So that they can then take appropriate actions, (e.g., ask the other > party to resend, file a bug in the library). I think a lot of the other discard rules originally come from the problem that through bad MAM catchup we might received messages twice and won’t be able to decrypt them another time. So in some cases 'discard them after decrypt failure' is based on the assumption that we have already decrypted them once. But I agree that this rule in that broad wording doesn’t make sense and should rather read; If you detect that a message has been decrypted already discard it. I think when OMEMO was written we didn’t have stanza-id and other types of more or less reliable dedup. Not excusing the standard here; just giving you some background. cheers Daniel _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
