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