[messaging] Security arguments for read receipts

[Ximin Luo]

On 03/11/15 16:49, Jeff Burdges wrote:
> As stated, there is no need for timely auto-acks to get these
> properties since implicit manual acks do them just fine.
> 
> [..]
> 
> 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.
> 

The security issue arises when:

- It is not made clear to the user that lack of an ack (e.g implicit manual ack) means "your message might not have been delivered".

- Other extra UI indicators further confuse the issue, and lead the user to believe incorrect things. For example:

  - Delivery receipts can be misinterpreted by users, who might think that it provides the same guarantees as "implicit manual ack".

  - Even the existince of a "drop notification" feature is misleading to users, who might interpret the lack of a "drop notification" as "your message was delivered successfully".

The "automatic" part is just to make the security usable, so one does not have to manually click ack all the time.

> 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.
> 

Not sure why you need a limited pool of tokens to authenticate delivery?

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git