I implemented this several times for various closed systems. I always attached a per message timeout that started the moment the message was read. No timeout changes after a message has already been sent. Ironically most of my implementations would probably be compatible with each other if it weren’t for the closed, non federating systems. I brought this up in the xsf muc recently if I should write a XEP for what I’ve been implementing repeatedly. But people didn’t seem very interested.
cheers Daniel 2018-05-10 2:12 GMT+02:00 Alexander Krotov <ilab...@gmail.com>: > I propose to extend OMEMO with disappearing messages. > > There is already a thread with a subject: "Self-destruct" message timeout > deletion hints. > It started with this message: > https://mail.jabber.org/pipermail/standards/2016-October/031515.html > Continued in November: > https://mail.jabber.org/pipermail/standards/2016-November/031595.html > Last message is from 2017: > https://mail.jabber.org/pipermail/standards/2017-February/032092.html > > The thread was started shortly after Signal announced its implementation > of disappearing messages in October 2016.[1] Rationale provided in > the blog post is worth repeating here to avoid talking about the > goals of this feature again, because it causes confusion all the > time (emphasis mine): >> Disappearing messages are a way for you and your friends to keep >> your message history tidy. They are a *collaborative feature* for >> conversations where all participants want to automate minimalist >> data hygiene, *not for situations where your contact is your adversary* >> — after all, if someone who receives a disappearing message really >> wants a record of it, they can always use another camera to take a >> photo of the screen before the message disappears. > See also the Signal FAQ entry for disappearing messages[2]. > > Implementing Snapchat-over-XMPP is a non-goal, so we don't have to > take into account hostile clients. Someone may run a client that > advertises support for disappearing messages and does not actually > delete them, but it is the problem of trust between users. Hostile > user may just as well run a client that advertises end-to-end > encryption, but leaks encryption keys or message contents later. > > The problem with previous thread is that it was about *message > hints*, as defined in XEP-0334[3]. Legacy clients, as well as > legacy or hostile servers, may not implement these hints and store > messages permanently without any way for users to ensure their > messages are deleted. Therefore, any plaintext message should be > assumed to be stored permanently, and there is no point in implementing > timers for them. Telegram developers seem to understand it too, and > only implement timed messages for end-to-end encrypted "secret > chats", in contrast to plaintext "cloud chats". > > What I propose instead of message hints is to extend OMEMO with: > 1. a way to discover disappearing message timer support per device, > 2. a way to specify timer value in messages, > 3. specification of timer value semantics, > 4. a protocol to negotiate common disappearing message timer. > > Signal solutions to these problems cannot be copied exactly for > several reasons, which I describe below. > > 1. A way to discover disappearing message timer support per device. > > In XMPP, some devices will never get the support for disappearing > messages. Therefore, disappearing messages must be encrypted only > for devices which advertise their support. > > Signal didn't have to deal with this problem. All devices were > eventually updated to the newest version of the Signal and processed > disappearing messages. > > As I understand from OMEMO specification[4], the best place to > advertise support for disappearing messages is the device bundle. > > As for UI, OMEMO+Timers can be treated simply as another encryption > method. User will have to choose between None, OpenPGP, OTR, OMEMO > and OMEMO+Timers. If user selects OMEMO+Timers, devices which only > support OMEMO will receive a message they can't decrypt. > > Devices that don't support OMEMO+Timers will leave the trace of > communication, but little can be done about it I believe. Proper > metadata protection, i.e., hiding the fact of communication, is > impossible in XMPP, so it is a non-goal for this proposal. > > 2. A way to specify timer value in messages. > > Timer value should be placed somewhere in <message> tag. I would > also like to make it encrypted. Problem is, the only encrypted part > of the message is the <payload> which contains plaintext message > corresponding to the contents of <body> and is not extensible. > > OX (XEP-0374) solves the problem by treating payload contents as > the <message> contents, i.e., the payload can contain multiple > <body> tags, chat state notifications etc. > > I believe this approach can be copied to OMEMO in backwards-compatible > way. Until then, I suggest that we send message timers unencrypted, > just like chat state notifications, and move both inside encrypted > part later. Even though OMEMO+Timers has to be treated as different > encryption method, I would like to keep the changes minimal, avoid > changing namespaces and maintaining two completely separate > implementations. > > <timer> tag with some namespace, which probably should be registered > with XMPP Registrar, will contain the timer value in seconds. > > 3. Specification of timer value semantics. > > We should define what timer value means. To see what the options > are, it is worth to take look at Wickr. It has both the Expiration > Timer and Burn-on-Read timer[5]. > > Expiration timer is synchronous. Looks like the motivation behind > it is to save data storage more than privacy[6]. XMPP already > implements similar functionality as "expire-at" AMP condition[7]. > > What we want instead is the Burn-on-Read semantics. That is what > Signal and Telegram implement. > > It should be clearly specified when the timer starts on each of the > devices. > > According to the Telegram FAQ[8], the timer starts counting as soon > as the message is read on the receiver device, and as soon as the > reading receipt is received on the sender device. This approach > cannot be applied to XMPP, because reading receipts are not guaranteed > to be enabled. Besides that, Telegram does not support more than > two devices per secret chat, so it is not clear how to extend it > to multiple device setting. > > In Signal, protocol is asynchronous. Timer starts counting on the > sender device after the message is sent. CONTRIBUTING.md file in > Signal-Android repository states it as one of the design principles > of Signal: "There is no such thing as time. Protocol ideas that > require synchronized clocks are doomed to failure." I think we > should adopt this principle too, because we don't want message to > be kept for longer than they should on devices with lagging clocks. > > So, the following semantics apply. On the sender device the timer > starts immediately. On each receiver device the timer starts counting > as soon as the message is read. On own devices, the message must > be considered read immediately. > > Signal seems to violate its own principle of asynchronism here. > Instead of simply starting the timer on all own devices, it starts > the timer on the originating device and synchronizes the message > together with absolute timestamp of the timer start. The reason for > this absolute timestamp I can think of is own devices which were > offline when the message was sent. Perhaps we should also send > absolute timestamp to own devices and take minimum of the received > timestamp and current time as the moment of timer start. Or, invent > some other way to subtract delivery time from the timer value. > > Similar synchronization concerns apply to the receiving side. What > happens when message expires on one of the devices? Signal avoids > this by synchronizing read state across devices, so timers start > almost simultaneously on all devices. We should also send read > receipts to own devices, even if sending read receipts to originating > parties is disabled, and start timers when we receive such "carbon > copy" read receipts. > > 4. A protocol to negotiate common disappearing message timer. > > It is an essential feature, which Signal and Telegram implement. > Wire and Wickr don't, and it makes disappearing messages way less > usable: if one has it enabled, but someone else in a group doesn't, > everyone ends up with a partial conversation history. Even worse > when different timer values are used. > > When user changes the setting, Signal sends special "expiration > timer update" to all other devices in a group. In XMPP it can be > implemented by sending a message without body, in the same way as > <composing/> chat state notifications are sent. > > In rare case expiration timer update can be lost. To synchronize > the setting, timer values form normal messages are treated as > expiration timer updates too. > > This can lead to a problem when user changes the setting, expiration > timer update is lost, and then it receives a message with old > setting. In this case the setting is reverted, and user has to set > it again. > > However, this race condition should be rare and I can't find more > reliable solution which does not involve absolute timestamps and > timer update retransmissions. Described protocol is simple and good > enough already. This setting synchronization is a Byzantine agreement > problem, so there is no perfect solution anyway. > > I have not looked into Telegram implementation of timer synchronization, > but it is unlikely we can learn much from it, as it only supports > two devices. > > > So far I have done this research on existing solutions and outlined > what I want to formally propose. Next steps would be writing a XEP > and implementing a prototype on top of some desktop OMEMO implementation, > most likely Gajim or Dino. > > Any input and help are welcome. > > [1] https://signal.org/blog/disappearing-messages/ > [2] > https://support.signal.org/hc/en-us/articles/213134237-Does-Signal-have-disappearing-messages- > [3] https://xmpp.org/extensions/xep-0334.html > [4] https://xmpp.org/extensions/xep-0384.html > [5] > https://support.wickr.com/hc/en-us/articles/115007397548-Auto-Destruction-Expiration-and-Burn-on-read-BOR- > [6] > https://medium.com/cryptoblog/the-rising-cost-of-storage-why-data-should-not-live-beyond-its-useful-life-1266a8e94983 > [7] https://xmpp.org/extensions/xep-0079.html#conditions-def-expireat > [8] https://telegram.org/faq#q-how-do-self-destructing-messages-work > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
