[messaging] Security arguments for read receipts
infinity0 at pwned.gg
Tue Nov 3 08:00:25 PST 2015
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
Not sure why you need a limited pool of tokens to authenticate delivery?
More information about the Messaging