[Standards] Disappearing timers for OMEMO proposal
jonas at wielicki.name
Sat May 12 14:32:13 UTC 2018
On Samstag, 12. Mai 2018 15:31:41 CEST Alexander Krotov wrote:
> On Sat, May 12, 2018 at 10:45:49AM +0200, Florian Schmaus wrote:
> > On 12.05.2018 10:14, Alexander Krotov wrote:
> > > On Fri, May 11, 2018 at 10:24:35AM +0200, W. Martin Borgert wrote:
> > >> Quoting Alexander Krotov <ilabdsf at gmail.com>:
> > >> Therefore it is orthogonal to any encryption and it does also not
> > >> matter, whether your peer or one of your peers devices or resources
> > >> does implement the feature or not. No need to check. As sender, just
> > >> use the timers and let the problem of deleting messages to the
> > >> recipient.
> > >
> > > I want to be able to advertise to my contacts which of my devices
> > > support timers, so devices that don't support them are not able to
> > > decrypt the message.
> > What prevents ("malicious") devices from announcing the feature and not
> > deleting the message afterwards? What do you gain from coupling
> > encryption and timers?
> Nothing prevents "malicious" devices from announcing the feature
> and not implementing it correctly. "Malicious" user devices are not
> a part of my threat model. I have just explained it in detail in
> another message.
Then I don’t see a reason to *require* a *specific type* E2EE. If you are
worried about the server attacking, fine, use the <timer/> with OMEMO.
> Announcing the feature is a way to tell my contacts that if they want to
> send me an ephemeral message, they have to encrypt it only for those of
> my devices that will delete them. For example, if I use a desktop client
> that implements ephemeral messages, but still use a legacy mobile client
> that does not, my contacts will only include a key for my desktop
> client, and my mobile client will not be able to decrypt a message.
See, this is extremely horrendous User Experience. One side of the
conversation picks an encryption mode which makes messages only appear on a
subset of the devices on the other side. People are already complaining about
this with plain OMEMO, due to whatever-is-going-wrong (I’m not familiar with
OMEMO on a development level).
(Then again, if we introduce a thing where having the message only on a subset
of devices is a feature, we might use that as a diversion! /sarcasm)
> Coupling encryption and timers prevents plaintext messages from
> being stored forever on *my own* legacy clients, so I don't have
> to upgrade them all at once to make this feature works properly, and
> my contacts don't have to worry if I have already upgraded all my
> devices or not.
Why would your contacts worry? In your other message, you explained:
> In the part of my message that you quote, though, I was not even
> talking about making sure message is deleted on a device that I
> don't own, which is a matter of trust. I was talking about not being
> able to decrypt the message on *my* devices by advertising that I
> only want to receive ephemeral messages on some subset of my devices.
So what is it now? Is this about data hygiene on your own devices (in which
case we don’t even need wire format at all, just add a "delete last N hours"
button, or if you want to default to deletion, add a "do not delete last N
hours" button; actually, probably not the worst idea), is it about data
hygiene on other peoples devices and servers (E2EE not required at all to make
this work, since it’s a matter of "trust" anyways; and I think this might
actually be a useful feature sometimes), or is it about security and actually
safely deleting timed messages (not possible, as you know)? I feel that you’re
shifting goalposts all the time.
> Even if backwards compatibility was not a problem, some client
> developers may not implement this feature at all, for various reasons.
> They may not be convinced that this feature is useful; they develop for
> a platform that can't offer strong enough security guarantees (for
> example, Web) and securely delete a message;
Great, so now we have a subset of clients not able to receive messages from a
subset of users who think that enabling timers by default is a good idea. And
since your messages don’t arrive, you won’t know.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards