Hi Germán, On 19 May 2017 at 15:02, Germán Márquez Mejía <[email protected]> wrote:
> My only question is: Are there any potential privacy issues > here? > Good question. The only situation where i can see this happening is when this protocol is used in a broadcast situation, e.g.: - an anonymous/semi-anonymous MUC where an admin sends an encrypted message to all recipients (but can't get anything back). - a pubsub publication by a node owner I'm not sure whether OMEMO is well suited for PubSub or MUC use cases. (e.g for MUC, maybe we should adopt a Megolm approach for scalability), and if it is, whether the broadcast use case is something we should be concerned with. Even without sending the JID, there's still a privacy leak: you can still match 'rid's to a database of known rid->jid mappings (which is public information anyway, you just have to go out and collect it). Alternatives I can think of are: - a 'to' attribute with 'receiver' or 'initiator'. This only works in a one-on-one situation. (i.e. we'd definitely need an extension for MUC) - a 'key' attribute with the public identity key instead of a 'jid,rid' pair. This is a bit verbose (44 bytes per envelope), although not much more than 'jid,rid' (especially not if you don't impose the artificial restriction to 32-bits for device ids). thanks, Remko
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
