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

[Michael Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/04/14 22:03, Daniel Kahn Gillmor wrote:
> If the linearizing protocol requires clients to wait and retry to
> claim the next sequence number during periods of message
> contention, the obvious way to do this is automated re-tries,
> rather than hassling the user each time their message gets bumped.

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.

> however, automatic re-tries pollute the meaning of the ordering
> that linearization tries to produce.  In particular, if the user
> isn't able to indicate to the UI which messages they read before
> writing the message (which ones are the "parents" of a given
> message), then they become vulnerable to the "ice cream" attack
> just by virtue of message timing and automatic retries.

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.

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

> But i think any sort of forced linearization presents a different
> set of UI difficulties on message creation and sending that seem
> likely to be worse.  Do any of the advocates of strict
> linearization have a proposed solution to this UI issue?  How do
> you avoid hassling the user about sending any given message
> multiple times when the conversation is flowing quickly, and still
> enforce a semantically meaningful total ordering that isn't just a
> crapshoot for each user that might misrepresent what they're
> replying to?

I think the only way to answer the question of which UI is better is
to build some prototypes.

As for design goals, maybe we should ask whether the weak form of the
attack really needs to be prevented, given that existing centralised
systems don't prevent it.

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJTUUq/AAoJEBEET9GfxSfM3AkIAJuw97CWYr4d+I05Q+DlJImI
ub6CkQqzn6EF4Ng8gBBoWz2ka8TyopYvYlxvBjp4i0bvHDC9Kqa0ZuP9bwR+eAev
sNciRkJXreITdsNrZNcLFuTcLaXKMcBLoMv8VcNdnV43hYWtcxKdyHACD/oEIX5q
ApwpH3nu8sL2K8it4iuV+kMnxCFNPRDRWVkX6wINx40aukMMNqDwuXyvLz+f/Wva
ubjMoNmuPxPaKCtbAj2VzFpkjTe67aXNYKZ0RjhXPzs6EpEl9/MB/6GGxmGpEY86
1olEWyvv8HlAklpPqbiqjSbC6Z2Kn2x55rU6Fw4JIudEBMeaGfcUqGwn/EOs3p8=
=VM8H
-----END PGP SIGNATURE-----