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

[Michael Rogers]

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

On 18/04/14 22:11, Daniel Kahn Gillmor wrote:
> 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.

Good point - the cost of contention is definitely worth taking into
account, but bear in mind that contention per se doesn't cause any
extra transmissions - only ties cause extra transmissions. A round
with collisions that doesn't end in a tie costs the same as a round
with no collisions.

Come to think of it, we can reduce the number of ties by lowering the
threshold for a message to win from a majority of votes to more votes
than any other message.

Unfortunately it's hard to make any general predictions about the
number of ties, because it depends not only on the group size, the
rate of message creation and the latency of links, but also on the
distribution of latency - for example, if there are clusters of
members with low intra-cluster latency and high inter-cluster latency,
there will be more ties than if all links have equal latency.

I should say, by the way, that I generally dislike synchronous
fixed-membership protocols like the one I've sketched - I'm sort of
playing devil's advocate here, because Ximin's DAG approach, which is
much more to my usual taste, doesn't seem to be compatible with a
simple linear UI.

Emphasis on simple. ;-)

> 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?

That's what I'm aiming for, yes - can't speak for anyone else.

> 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?

Right. Depending on the protocol, that may mean that in the strong
form, the attacker can insert messages arbitrarily far back in the
conversation.

> 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?

It could work in a variety of ways, depending on what the protocol
permits. Maybe Mallory can scroll back through the transcript, find a
message that's vulnerable to being re-contextualised and insert a
message before it to change its meaning. Or maybe Mallory's UI has a
'snipe' button that allows her to trigger a collision, see the next
message submitted by another member, and quickly write a message to be
inserted before that message. Etc.

> 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?

People's responses are sometimes predictable, sure, but in general I
think it's fair to say that knowing exactly what someone said is more
powerful than guessing what they're about to say.

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

iQEcBAEBCAAGBQJTU+qWAAoJEBEET9GfxSfM88UH/jbpq3RTZxC6zm3c3xWl14XL
nmWN8FriRt1d5wbmZ24lyb7KpzeBJwyGa+0PyrEPAXc3DO2dR/fPUcyD1I3ODBxc
K7BAjF4JmZaEnd5SscOjjsySHSzsy1I0MfhKXYyearbq9SCuC/HQ8wXfmkr5youI
eawxiT9+ilDQ+8txxkAWWIYZUzTwd5NPhQuPYLbdgEzO4qyw1HQzkBmEpsPH+D/x
f5C3RT7DIHs+vxXi74PACQRtqbzvBhGIJkB9SrZ9wZDsBrllylbcq8/f0kEuY4T0
hzNGmLwdTvAC7LUXSjnJ+qcgCwcfE2xl69ZZxg3QiI0/31HpVBn0Q91NVxk64D4=
=OlQR
-----END PGP SIGNATURE-----