[messaging] Security arguments for read receipts

[Jeff Burdges]

On Tue, 2015-11-03 at 12:08 +0100, Ximin Luo wrote:
> Benefits of auto-acks:
> 
> 1. As the author, your messaging program automatically verifies that 
> the message was delivered successfully (reliability).
> 
> 2. As a reader, your messaging program automatically verifies that 
> other readers also saw the messages (consistency).

As stated, there is no need for timely auto-acks to get these
properties since implicit manual acks do them just fine.

> Counterarguments:
> 
> 1. a) For cases where people message you unexpectedly (e.g. 
> strangers), this has high significance.

I donno if this matters so much, but implicit manual acks win here.

> However, the opposite scenario, where you're having a friendly co
> -operative conversation, is also common:
> 
>    - As the author, you can't be sure whether your readers received 
> your message, unless they manually reply to do so. As the reader, 
> this is such a common thing to do, the messaging layer should do it 
> automatically, instead of expecting you to manually play these
> verification games.

It's pretty normal for messaging systems to have manual acks now
specifically to save users from playing "verification games", like
facbook's like button or pond's ack button.  Afaik user are comfortable
with these "content-free reply" options.

>    c) *Automatic* acks inherently carry less creep factor, your 
> program does it automatically so it is perfectly reasonable to argue 
> to the people socially judging you that you didn't actually read the
> message yet.

Implicit manual acks are fine here too.  Just say "received" instead of
 "read".

>    d) For security purposes, one should *at least* warn authors after 
> a timeout that "maybe your message wasn't actually delivered", if the 
> program don't receive an ack (manual or automatic) within a given
> timeout. 

Is this a security issue really?  It sounds beneficial of course, but
not seeing the security implications.  At present, messengers normally
give dropped messages another color or whatever.

There are a bunch of reasons for using a limited pool of tokens to
authenticate delivery.  I'd imagine such systems might be slow to retry
dropped messages to avoid waisting the tokens, and they'd likely burn
several tokens before complaining that the message dropped, so you've
potentially hours of delay before the system colors your message as
dropped.

Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151103/0a5fa8d9/attachment.sig>