mirror of https://github.com/moparisthebest/xeps
ProtoXEP: Rework ephemeral messages
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This commit is contained in:
Maxime “pep” Buquet
parent
b168f01e07
commit
23e9bfb41f
|
|
@ -1,14 +1,15 @@
|
|||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY ephemeral "urn:xmpp:ephemeral:0">
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
<!ENTITY EPHEMERAL '<ephemeral/>'>
|
||||
<!ENTITY eph0 'urn:xmpp:ephemeral:0'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Ephemeral Messages</title>
|
||||
<abstract>This specification defines a protocol to send ephemeral messages over XMPP and synchronize timer value setting across devices.</abstract>
|
||||
<abstract>This specification encourages a shift in privacy settings wrt. logging policies.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>xxxx</number>
|
||||
<status>ProtoXEP</status>
|
||||
|
|
@ -16,194 +17,208 @@
|
|||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0004</spec>
|
||||
<spec>XEP-0030</spec>
|
||||
<spec>XEP-0313</spec>
|
||||
<spec>XEP-0334</spec>
|
||||
<spec>XEP-0384</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>NOT_YET_ASSIGNED</shortname>
|
||||
<author>
|
||||
<firstname>Alexander</firstname>
|
||||
<surname>Krotov</surname>
|
||||
<email>ilabdsf@gmail.com</email>
|
||||
</author>
|
||||
&pep.;
|
||||
<revision>
|
||||
<version>0.0.2</version>
|
||||
<date>2022-04-16</date>
|
||||
<initials>pep</initials>
|
||||
<remark><p>Resubmit with some changes.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2018-04-10</date>
|
||||
<initials>psa</initials>
|
||||
<initials>ak</initials>
|
||||
<remark><p>First draft.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>Existing protocols deployed in XMPP networks offer forward secrecy both on the transport (TLS) and message (&xep0027; and &xep0384;) levels. Forward secrecy prevents recorded communications from being decrypted even if long term encryption keys are compromised by generating ephemeral keys and securely deleting them when they are no longer needed.</p>
|
||||
|
||||
<p>However, even though keys are deleted, message contents is retained both in server and client archives. While servers can be instructed with message hints (&xep0334;) not to store some messages in the archives (&xep0313;) or prevented from saving them in plain text by the use of end-to-end encryption, most XMPP clients still retain message content almost indefinitely. A device with an installed XMPP client that can be lost or stolen becomes the weakest link.</p>
|
||||
<section1 anchor="intro" topic="Introduction">
|
||||
|
||||
<p>Unlike ephemeral keys, which have specified lifetimes, message contents cannot be removed immediately after being read. Users have to decide for how long they want to retain conversation contents. Verbally agreeing on the time interval and manually removing messages from all devices is cumbersome and error-prone.</p>
|
||||
<p>Existing protocols deployed in XMPP networks offer forward secrecy both on the transport (TLS) and message (&xep0384;) levels. Forward secrecy prevents recorded communications from being decrypted even if long term encryption keys are compromised by generating ephemeral keys and securely deleting them when they are no longer needed.</p>
|
||||
|
||||
<p>This XEP defines a way to attach a timer value to messages which in order to specify for how long XMPP clients should store message contents. Besides that, it defines a way to synchronize common timer setting across all users of the conversation.</p>
|
||||
<p>However, even though keys are deleted, message contents is retained client archives. While servers generally impose time limits on archives (messages, stored files, etc.), due to privacy laws (e.g., GDPR) and/or disk-space concerns, most XMPP clients still retain message content almost indefinitely even though it may not benefit a majority of their userbase. A device with an installed XMPP client that can be lost or stolen becomes the weakest link.</p>
|
||||
|
||||
<p>The specification does not depend on any encryption scheme and does not require encryption at all. It can be used with plaintext messages as long as users trust their servers to respect &xep0334;.</p>
|
||||
<p>Unlike ephemeral keys, which have specified lifetimes, message contents cannot be removed immediately after being read. Users have to decide for how long they want to retain conversation contents. Verbally agreeing on the time interval and manually removing messages from all devices is cumbersome and error-prone.</p>
|
||||
|
||||
<p>This XEP defines a way to attach a timer value to messages which in order to specify for how long XMPP clients should store message contents. Besides that, it defines a way to synchronize common timer setting across all users of the conversation.</p>
|
||||
|
||||
<p>The specification does not depend on any encryption scheme and does not require encryption at all. Plaintext messages will still be readable by servers in between and will depend on trust placed on these server to apply their privacy policy or to respect a &xep0334; store hint.</p>
|
||||
|
||||
<p>Other IM systems, such as <link url="https://signal.org/">Signal</link>, <link url="https://wickr.com/">Wickr</link>, <link url="https://wire.com/">Wire</link> and <link url="https://telegram.org/">Telegram</link>, already offer ephemeral messages. Signal offers timer synchronization feature for user groups and Telegram offers it for secret chats, which are limited to two users.</p>
|
||||
|
||||
<p>Other IM systems, such as <link url="https://signal.org/">Signal</link>, <link url="https://wickr.com/">Wickr</link>, <link url="https://wire.com/">Wire</link> and <link url="https://telegram.org/">Telegram</link>, already offer ephemeral messages. Signal offers timer synchronization feature for user groups and Telegram offers it for secret chats, which are limited to two users.</p>
|
||||
</section1>
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<ul>
|
||||
<li>Provide a way to specify a timer value after which message contents must be deleted from user devices.</li>
|
||||
<li>Clearly define semantics of timer value for XMPP clients.</li>
|
||||
<li>Provide a way for a group of users to choose common value for ephemeral message timers and synchronize it across all devices.</li>
|
||||
<li>Ensure that legacy XMPP clients that do not respect timer values specified in a message do not display such messages (and, hopefully, do not store their contents).</li>
|
||||
<li>Ensure that for end-to-end encryption schemes where each client has its own session key (e.g., OTR and OMEMO), ephemeral messages are encrypted only for devices that explicitly indicate support for the feature.</li>
|
||||
</ul>
|
||||
<section1 anchor="reqs" topic="Requirements">
|
||||
|
||||
<p>What this specification tries to do:</p>
|
||||
<ul>
|
||||
<li>Provide a way to specify a timer value after which message contents must be deleted from user devices.</li>
|
||||
<li>Clearly define semantics of timer value for XMPP clients.</li>
|
||||
<li>Provide a way for a group of users to choose common value for ephemeral message timers and synchronize it across all devices.</li>
|
||||
<li>Allow users to vacate to other activities while still being able to keep track of chats, as before.</li>
|
||||
</ul>
|
||||
|
||||
<p>What this XEP doesn’t try to be:</p>
|
||||
<ul><li>A way to securely ensure that logs won’t be kept by parties included in chats.</li></ul>
|
||||
|
||||
</section1>
|
||||
<section1 topic='Glossary' anchor='glossary'>
|
||||
<dl>
|
||||
<di><dt>Explicit timer update</dt><dd>A message with an empty ephemeral tag, sent to update timer setting on all devices participating in a chat.</dd></di>
|
||||
<di><dt>Implicit timer update</dt><dd>A message with a non-empty ephemeral tag, treated as a timer update for the puprose of timer setting synchronization.</dd></di>
|
||||
</dl>
|
||||
|
||||
<section1 anchor="usecases" topic="Use Cases">
|
||||
<section2 anchor="disco" topic="Advertising support">
|
||||
|
||||
<p>A client implementing this specification MUST advertise the <tt>&EPHEMERAL;</tt> disco feature (as per &xep0030;). When advertising the feature, a client will honor requests to discard messages after the agreed upon delay.</p>
|
||||
|
||||
</section2>
|
||||
|
||||
<section2 anchor="sending" topic="Sending an ephemeral message">
|
||||
|
||||
<p>An ephemeral message is a <tt>&MESSAGE;</tt> including an <tt>&EPHEMERAL;</tt> tag in the <tt>&eph0;</tt> namespace, with an attribute <tt>timer</tt> (xs:unsignedInt) indicating the delay in seconds, after which a message MUST be discarded.</p>
|
||||
|
||||
<p>Ephemeral messages SHOULD be sent as usual on the bare JID of the contact, or as is specified for groupchats (e.g., MUC, MIX). If this includes sending to non-supporting clients, and they can be detected, sending clients SHOULD warn the user in some way. Clients MAY warn users anyway if non-supporting clients cannot be detected (e.g., when they don’t get a directed presence).</p>
|
||||
|
||||
<p>Sending clients MAY include a <tt><no-permanent-store/></tt> &xep0334; when not doing end-to-end encryption, even though this may break receiver clients' expectations regarding archive management, and cause even supporting devices not to see ephemeral information.</p>
|
||||
|
||||
</section2>
|
||||
<section2 anchor="negotiation" topic="Negotiating a delay">
|
||||
|
||||
<p>Sending a message with an ephemeral tag is how a delay is negotiated in a chat. A client receiving a message with an ephemeral tag MUST honor the timer for the received messages, and SHOULD include it in turn in following messages.</p>
|
||||
|
||||
<p>To change the timer for the following messages, change the value when sending a new message.</p>
|
||||
|
||||
</section2>
|
||||
|
||||
<section2 anchor="implicit-negotiation" topic="Implicit timer negociation">
|
||||
|
||||
<p>A implicit negociation can be done by sending a message with no <tt>&BODY;</tt>, that contains an <tt>&EPHEMERAL;</tt> tag and a timer attribute, specified in <link url='#sending'>Sending an ephemeral message</link>. The message MUST also contain a <tt><store></tt> hint as described in &xep0334; so that offline clients see it.</p>
|
||||
|
||||
</section2>
|
||||
<section2 anchor="opt-out" topic="Opting-out of ephemeral messages">
|
||||
|
||||
<p><strong>XXX</strong>: Help. How do I ensure the receiving client sees what I am going to send, if it’s just a single message. Same issue as with negotiating the delay. (That is, if a client doesn’t fetch all MAM, it may miss the message). Do I need to send <i-want-out/> forever?</p>
|
||||
|
||||
<p>A client that has previously been sending ephemeral messages can choose to stop sending them, and send regular messages instead, in which case it should tell the recipient:</p>
|
||||
|
||||
<code><![CDATA[<message from='vladimir@example.com/mobile' to='管野@example.com' type='chat'>
|
||||
<body>おは</body>
|
||||
<i-want-out/>
|
||||
</message>]]></code>
|
||||
|
||||
<p>When the recipients sees the (TODO) <tt><i-want-out/></tt> element, it will stop including <tt>&EPHEMERAL;</tt>. The original client seeing no ephemeral tag is being included SHOULD stop sending the opt-out element.</p>
|
||||
|
||||
<p><strong>TODO</strong>: Negociation within messages is wonky. If a client comes back online and this flag isn't in server archives anymore, it will send ephemeral messages again causing all devices to send them again. This might go on forever.</p>
|
||||
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<section2 topic='Determining Support' anchor='support'>
|
||||
<p>If an entity supports ephemeral messages, it MUST advertise that fact in its responses to &xep0030; information (<tt>disco#info</tt> requests by returning a feature of <tt>&ephemeral;</tt>.</p>
|
||||
<example caption='A disco#info Query'><![CDATA[
|
||||
<iq from='romeo@shakespeare.lit/orchard'
|
||||
id='disco1'
|
||||
to='juliet@capulet.com/balcony'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='A disco#info Response'><![CDATA[
|
||||
<iq from='juliet@capulet.com/balcony'
|
||||
id='disco1'
|
||||
to='romeo@shakespeare.lit/orchard'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
<feature var=']]>&ephemeral;<![CDATA['/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>An XMPP client SHOULD warn the user if not all recipients support ephemeral messages.</p>
|
||||
<p>To avoid downgrade attack, an XMPP client MUST allow the user to force sending of ephemeral message even if no recipient has indicated support for them.</p>
|
||||
</section2>
|
||||
<section2 topic='Sending a Plaintext Ephemeral Message' anchor='plain'>
|
||||
<p>To send an ephemeral message, an XMPP client places message contents into <tt><ephemeral></tt> tag with a <tt><timer></tt> attribute set to the number of seconds after which the message contents is to be securely deleted from the recipient device. XMPP client MUST include a <tt><no-permanent-store/></tt> hint (see &xep0334;), as any permanent storage of ephemeral message defeats its purpose.</p>
|
||||
<p>Here is an example of sending a plaintext ephemeral message with a 24 hours (86400 seconds) timer value.</p>
|
||||
<example caption='A Plaintext Ephemeral Message'><![CDATA[
|
||||
<message from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com'>
|
||||
<ephemeral xmlns=']]>&ephemeral;<![CDATA[' timer='86400'>
|
||||
<body>
|
||||
TODO insert some message text
|
||||
</body>
|
||||
</ephemeral>
|
||||
<body>
|
||||
This is an ephemeral message.
|
||||
</body>
|
||||
<no-permanent-store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Sending a Timer Setting Update' anchor='update'>
|
||||
<p>When user manually changes ephemeral message timer setting in an XMPP client, XMPP client SHOULD send an ephemeral message timer update.</p>
|
||||
<p>Timer update message SHOULD be sent immediately. An XMPP client MAY choose to postpone sending a timer update, remember the current value and ignore implicit timer updates until either the user sends a message or an explicit timer update is received. It may be useful, for example, to avoid waking up wireless connection when user device has low battery.</p>
|
||||
<p>A timer update is simply an ephemeral message without a body. However, for timer setting updates XMPP client SHOULD use <tt><store></tt> hint, to ensure that timer setting is updated properly on offline clients when they go online.</p>
|
||||
<example caption='An Ephemeral Message Timer Update'><![CDATA[
|
||||
<message from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com'>
|
||||
<ephemeral xmlns=']]>&ephemeral;<![CDATA[' timer='86400'/>
|
||||
<store xmlns="urn:xmpp:hints"/>
|
||||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Receiving Ephemeral Messages' anchor='receiving'>
|
||||
<p>An XMPP client receiving an message with an <tt><ephemeral></tt> tag SHOULD update the timer setting to the value of <tt>timer</tt> attribute. It MAY ignore implicit timer updates if it has postponed sending a timer update message, as described in <link url='#update'>Sending a Timer Setting Update</link> section.</p>
|
||||
<p>The rationale for updating the timer value upon receiving ephemeral messages with contents, in contrast to explicit ephemeral timer updates, is to make sure devices get synchronized eventually even if timer updates are lost. It may happen, for example, if some device stays offline longer than the lifetime of offline message storage (see &xep0160;).</p>
|
||||
<p>After that, client moves the contents of <tt><ephemeral></tt> into the <tt><message></tt> and ignores any elements outside the <tt><ephemeral></tt>, such as <tt><body></tt> element intended for legacy clients.</p>
|
||||
<p>The resulting message is processed as usual.</p>
|
||||
</section2>
|
||||
<section2 topic='Exchanging Ephemeral OMEMO Messages' anchor='omemo'>
|
||||
<p>OMEMO requires that messages are delivered in a sequence. If a message is missing, all the following messages cannot be decrypted and a new session has to be established. To prevent this kind of situation, additional steps are required to make sure ephemeral messages are not sent to clients that will ignore them because they do not support them.</p>
|
||||
<section3 topic='Announcing Support for Ephemeral Messages'>
|
||||
<p>An OMEMO-capable device implementing ephemeral messages MUST indicate support for ephemeral messages in its Bundle (see &xep0384;).</p>
|
||||
<example caption='Announcing Ephemeral Message Support'><![CDATA[
|
||||
<iq from='juliet@capulet.lit' type='set' id='announce'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='eu.siacs.conversations.axolotl.bundles:12345'>
|
||||
<item>
|
||||
<bundle xmlns='eu.siacs.conversations.axolotl'>
|
||||
<!-- XEP-0384 elements here ... -->
|
||||
<ephemeral xmlns=']]>&ephemeral;<![CDATA['/>
|
||||
</bundle>
|
||||
</item>
|
||||
</publish>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section3>
|
||||
<section3 topic='Sending an Ephemeral Message' anchor='omemo-send'>
|
||||
<p>When sending an ephemeral OMEMO message, XMPP client MUST NOT encrypt it for clients that did not indicate support for ephemeral messages explicitly.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic='Exchanging Encrypted Ephemeral Messages' anchor='encrypted'>
|
||||
<p>While OMEMO in its current revision allows only the body to be encrypted, some other encryption schemes, such as &xep0374; allow to encrypt the <tt><ephemeral></tt> tag itself.</p>
|
||||
<p>If such a scheme is used, an XMPP client SHOULD encrypt <tt><ephemeral></tt> tag instead of placing encrypted message into it.</p>
|
||||
|
||||
<section1 anchor="examples" topic="Example scenarios">
|
||||
<section2 anchor="example-chat" topic="Initiating chat">
|
||||
|
||||
<p>Rosa sends a regular chat message to Peter:</p>
|
||||
|
||||
<example><![CDATA[<message from='rosa@example.com/mobile' to='peter@example.com' type='chat'>
|
||||
<body>I have read the book you sent me, it was very insightful.</body>
|
||||
</message>]]></example>
|
||||
|
||||
<p>Peter had his client previously configured to send ephemeral messages, before a chat with Rosa was opened. He replies:</p>
|
||||
|
||||
<example><![CDATA[<message from='peter@example.com/desktop' to='rosa@example.com' type='chat'>
|
||||
<body>Something</body>
|
||||
<ephemeral xmlns=']]>&eph0;<![CDATA[' timer='604800' />
|
||||
</message>]]></example>
|
||||
|
||||
<p>Rosa’s client tells her from now own, messages will disappear in a week (60 * 60 * 24 * 7). Before replying she decides a week is too long and changes her settings so that they now disappear in 5 days. Her client immediately sends an implicit timer negotiation. The message she just received from Peter however will still disappear in 7 days.</p>
|
||||
|
||||
<example><![CDATA[<message from='rosa@example.com/mobile' to='peter@example.com' type='chat'>
|
||||
<ephemeral xmlns=']]>&eph0;<![CDATA[' timer='432000' />
|
||||
<store xmlns="urn:xmpp:hints" />
|
||||
</message>]]></example>
|
||||
|
||||
<p>Peter’s client tells him messages will disappear in 5 days. Peter is fine with this and doesn’t change his client settings. His client will continue including the ephemeral tag with the same timer value of 5 days.</p>
|
||||
|
||||
<example><![CDATA[<message from='peter@example.com/desktop' to='rosa@example.com' type='chat'>
|
||||
<body>I see you changed the settings slightly. It's just as good to me!</body>
|
||||
<ephemeral xmlns=']]>&eph0;<![CDATA[' timer='432000' />
|
||||
</message>]]></example>
|
||||
|
||||
</section2>
|
||||
|
||||
</section1>
|
||||
<section1 anchor="rules" topic="Business Rules">
|
||||
|
||||
<p>Timers SHOULD be started once a user has seen/read a message, to give them the possibility to read it – in case the timer was too low, and/or they were taking a holiday from messaging. <strong>XXX</strong>: Is "read" and/or "seen" defined anywhere? Should we settle on some definition?</p>
|
||||
|
||||
<p>Once it has been sent, the timer on a message cannot be changed.</p>
|
||||
|
||||
<p>Discarded messages SHOULD be noted as such in the client (e.g., "This message has disappeared"). Not just removed with no indication of the reason.</p>
|
||||
|
||||
<p>When using with encryption mechanisms that include an encrypted wrapper such as &xep0373; or &xep0420;, this element SHOULD be placed in the wrapper.</p>
|
||||
|
||||
</section1>
|
||||
|
||||
<section1 anchor="impl" topic="Implementation Notes">
|
||||
|
||||
<p>Discarded messages shall be removed from memory and disk on a best effort basis.</p>
|
||||
|
||||
<p>Timers do not have to be exactly exact, the definition of "seen" or "read" not being consistent, and clock issues might also be a thing (use NTP?). This is also a best effort basis.</p>
|
||||
|
||||
<p>Ephemeral messages can be used with end-to-end encryption mechanisms. Both mechanisms are orthogonal. Messages are decrypted on the client and stored as plaintext in most cases when using end-to-end encryption.</p>
|
||||
|
||||
</section1>
|
||||
<section1 anchor="access" topic="Accessibility Considerations">
|
||||
|
||||
<p>OPTIONAL.</p>
|
||||
|
||||
</section1>
|
||||
<section1 anchor="i18n" topic="Internationalization Considerations">
|
||||
|
||||
<p>The message that appears once a message is discarded is a suggestion and should be adapted to the environment locale of the user.</p>
|
||||
|
||||
</section1>
|
||||
<section1 anchor="security" topic="Security Considerations">
|
||||
|
||||
<p>Ephemeral messages are not to be considered "secure" in any way.</p>
|
||||
|
||||
<p>Even within well-meaning entities, requiring that messages be discarded and made impossible to retrieve, requires a lot more scrutiny in the specification and in implementations, and even then, is a really technically challenging task, to say the least.</p>
|
||||
|
||||
<p>In an adversarial context, requiring that sent messages be deleted from every devices receiving it (thus including to an attacker), requires a lot more control over the infrastructure in place and is not in scope for this specification. The author of this specification has no intention to specify DRM.</p>
|
||||
|
||||
<p>This specification doesn't prevent an attacker to read messages sent to you after they get control of your device (e.g., stolen, confiscated). In this specific case, the situation is improved nonetheless as the spec helps reduce the overall amount of messages that stay on a given device, compared to the current community standards.</p>
|
||||
|
||||
<p>Note that if a message hasn't been fetched by the client yet, using a timestamp instead of a timer doesn't necessarily protect the user entirely. An attacker obtaining access to a device after a long time would have taken an image of the original device, gain access again at time of obtention of the device, replace the client to handle these particular messages differently. To counter this, a user would have to have go through the gymnastics of getting their server not to send any archive to this device, during the interval necessary to open the device.</p>
|
||||
|
||||
</section1>
|
||||
<section1 anchor="iana" topic="IANA Considerations">
|
||||
|
||||
<p>This document requires no interaction with the &IANA;</p>
|
||||
|
||||
</section1>
|
||||
<section1 anchor="registrar" topic="XMPP Registrar Considerations">
|
||||
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
||||
<p>The ®ISTRAR; includes <tt>&eph0;</tt> in its registery of protocol namespaces (see &NAMESPACES;).</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Timer Management' anchor='timer'>
|
||||
<p>Sender device MUST start the timer immediately after sending it, if Stream Management is not used (&xep0198;) or after receiving acknowledgement for <message> stanza, if Stream Management is available. This rule prevents the message from being deleted before it is successfully delivered to the server.</p>
|
||||
|
||||
<p>Device receiving a &xep0280; carbon copy MUST start the timer immediately.</p>
|
||||
<section1 anchor="design" topic="Design Considerations">
|
||||
|
||||
<p>Messages received from other JID MUST be stored in the database along with their timer value and timer SHOULD NOT start until the user reads a message. When the message is read by the user, for example by opening a chat window, an XMPP client starts a timer and MUST securely delete message contents from the device when the timer expires. An XMPP client SHOULD NOT display message contents outside the chat window, for example in system notifications. However, if it is displayed outside the chat window, for example when the last message for the contact is displayed in the roster window, an XMPP client MAY not start a timer until user explicitly opens the chat window.</p>
|
||||
<p>From the previous ephemeral-messages protoXEP, the requirement that made it incompatible with non-implementing clients has been removed, as well as the one that made clients using e2ee only send only to supporting clients. This is explained by the fact that the goal of this specification is to change privacy defaults in the ecosystem and not to prevent users from getting their messages and break user-experience substantially.</p>
|
||||
|
||||
<section2 topic='Encrypted Ephemeral Messages' anchor='encrypted-timer'>
|
||||
<p>If <link url='#encrypted'>encrypted ephemeral messages</link> are used, timer setting may become unsynchronized for devices that can not decrypt ephemeral messages. For this reason, whenever user changes an encryption scheme, an XMPP client SHOULD send an <link url='#update'>send an explicit timer update</link>.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Internationalization Considerations' anchor='i18n'>
|
||||
<p>XMPP client MAY translate the message "This is an ephemeral message." to other languages and include multiple <tt><body></tt> elements with different <tt>xml:lang</tt> attributes for legacy clients.</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>Devices implementing this specification MUST securely delete messages. For example, if SQLite is used as a database, <tt>secure_delete</tt> pragma MUST be set to 1 explicitly.</p>
|
||||
<p>An XMPP client MUST NOT let the message contents outside the application, even to display it in a system notification. It has <link url='https://objective-see.com/blog/blog_0x2E.html'>led to privacy issues in existing IM software before</link>.</p>
|
||||
<p>Plaintext ephemeral messages should not be relied upon for privacy. Legacy clients may store messages as raw XML contents, including the <tt><ephemeral></tt> tag, in their databases. Messages may be sent to third parties accidentally, for example if one of the servers is configured to deliver message contents in push notifications (&xep0357;).</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with the Internet Assigned Numbers Authority (IANA).</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>This specification defines the following XML namespaces:</p>
|
||||
<ul>
|
||||
<li>&ephemeral;</li>
|
||||
</ul>
|
||||
<p>Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
|
||||
</section1>
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<code><![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<p>Another use-case mentioned (and alluded to in security considerations) was being able to send time-sensitive messages, or rather, messages that have no purpose after a given time and thus should disappear. This specification doesn’t exactly answer it as it might have been necessary to start the timer at the exact same time on both sender and receiver, and as such, a timestamp would have been better. This behaviour can still be observed more or less if sender and receiver are active at the same time, but of course it will differ when the receiver comes back at a later time.</p>
|
||||
|
||||
<xs:schema
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||||
targetNamespace=']]>&ephemeral;<![CDATA['
|
||||
xmlns=']]>&ephemeral;<![CDATA['
|
||||
elementFormDefault='qualified'>
|
||||
<p>A minimal timer value was originally negociable, but was removed as it complicates the protocol substancially, and can directly be solved between users.</p>
|
||||
|
||||
<xs:annotation>
|
||||
<xs:documentation>
|
||||
The protocol documented by this schema is defined in
|
||||
XEP-xxxx: http://www.xmpp.org/extensions/xep-xxxx.html
|
||||
</xs:documentation>
|
||||
</xs:annotation>
|
||||
<p><strong>XXX</strong>: Do we want to use a per-“contact” model? How? With PEP? How would a client know which node to pick (of the two in a 1:1 chat, easier in MUC). What to do about the access model? This should also not be limited to contacts but whitelist may be annoying to manage. IQ negociation? This requires simultanous online-ness and also not likely with non-contacts as it would require directed presence.</p>
|
||||
|
||||
<xs:element name='ephemeral' type='ephemeral'/>
|
||||
|
||||
<!-- TOOD: finish XML schema after the XEP leaves the 'experimental' state. -->
|
||||
</xs:schema>
|
||||
]]></code>
|
||||
</section1>
|
||||
<section1 topic='Acknowledgements' anchor='acknowledgements'>
|
||||
<p>Thanks to Paul Schaub for <link url='https://mail.jabber.org/pipermail/standards/2018-May/034930.html'>the feedback</link> incorporated into this specification.</p>
|
||||
<section1 anchor="schema" topic="XML Schema">
|
||||
|
||||
<p>REQUIRED for protocol specifications.</p>
|
||||
|
||||
</section1>
|
||||
</xep>
|
||||
</xep>
|
||||
|
|
|
|||
Loading…
Reference in New Issue