[messaging] UI problems with forced total ordering [was: Re: Minimal requirements for group chat]

[Daniel Kahn Gillmor]

On 04/18/2014 11:54 AM, Michael Rogers wrote:
> That's one possibility - another possibility is to choose between the
> colliding messages automatically, add the winning message to the
> conversation, and leave the losing message in the composition area,
> perhaps flashing the winning message or something to indicate a
> collision, so the user can decide whether to edit the message before
> hitting send again.

I'm trying to imagine this UI in a rapid conversation involving 4 or 5
active participants, and i think it sounds really frustrating.  But
you're right that having prototypes would be useful to see whether my
imagination is just worrying over something that wouldn't really happen
in practice.

I also wonder whether under contention what the average number of
pairwise messages would need to be per message delivery.  I think it
would grow rapidly from the 2n(n-1) transmissions per round when there
is contention.

> I think we can design the protocol to avoid that. Let's distinguish
> between two kinds of ice cream attack. In the weak ice cream attack,
> Alice sends "Who wants to get ice cream", sees that Bob's responding
> but not what he's saying, and sends "...and kill the president?" to
> collide with Bob's unknown response. If the system sorts Alice's
> second message before Bob's then the attack succeeds. This weak form
> of the attack is possible in existing centralised chat systems, and as
> Joseph has pointed out, people seem to cope with it.

so thinking about this further, it occurs to me that there are two
possible problems with either the weak or strong "ice cream attack" that
we could try to defend against, and they're slightly different:

 0) viewers might have different views of the order of a conversation
from each other.

 1) viewers all have the same view of the order of a conversation, but
that order might be manipulable by one of the participants.

i'm assuming that we're trying to resolve (1) here, with the assumption
that we will always try to solve (0).  is that right?

> In the strong ice cream attack, Alice sends "Who wants to get ice
> cream", sees Bob's response, and sends "...and kill the president?" to
> collide with Bob's response. If the system sorts Alice's second
> message before Bob's then the attack succeeds. This strong form of the
> attack is not possible in centralised systems. This is the attack I'm
> worried about, because I feel like there's a bigger opportunity for
> creating deliberate confusion if the attacker can see the victim's
> message.
> 
> I believe the protocol I posted earlier today prevents the strong form
> of the attack, because only the winning message is sent. If used with
> a UI that 'bounces' losing messages rather than automatically
> resending them, it would prevent the weak form of the attack too: if
> Alice's second message won, Bob would get the chance to edit his
> message, whereas if Bob's message won, Alice's second message would
> appear after Bob's message (if Alice chose to resend it).

So the only difference between the weak form and the strong form is that
the attacker gets to see the other participant's response before
crafting their injection message, right?  How would this attack work
programmatically? it prepares a nasty context for a particular sort of
response that a given participant is known to emit, waits for them to
say it, and then does injects its nasty context ahead of that response?

This is a strange form of attack, and i wonder how far removed it is
from a "weak" attack, given the predictable patterns of human
conversation.  would an attacker who can parse and interpret human
responses to mount an effective strong attack be particularly far
removed from an attacker who had a decent chance at predicting the
response *before* receiving it based on some NLP trickery?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140418/69bd869e/attachment.sig>