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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
