On 12/12/14 15:57, [email protected] wrote: > My original point was that the practical usefulness of this could be > increased by surfacing it in the UI and allowing users to actually > create false records. After the (lack of) examples brought forward in > this thread of how this would actually create a significantly increased > beneficial outcome in practice, compared to the complexities and > confusion it likely introduces for the user, I'm no longer sure this is > a good idea.
Indeed. Now, I'm all for obscure safety properties being added to things on the offchance that they might make life slightly harder for a very specific kind of attacker - *if they're free*. So what's the cost of "deniability"? Added complexity in the protocols and their implementations? Increased message sizes, more delays in communication? More things that can break? Any weakening of other security properties? Adding burdens to users? Confusing users? If there's no/negligible cost to it, then sure, why not! But if two products to do the same thing, one with deniability and one without, sit side by side, are there situations where you'd prefer to use the non-deniable product? I think Eleanor is raising a good point that the users need to be thought about more centrally, however. Imagine a non-technical user with a goal we might be able to help with. Such as, "Talking securely to my friend Bob who I occasionally meet in the flesh but want to communicate with electronically for convenience, without anybody being able to intercept or tamper with or forge our communications without spending at least ten thousand dollars". Or "Sending a tip to a widely-known journalist such that I can make sure that they, and only they, get my message, and it's hard for them or eavesdroppers to trace back to me, and only they can see the message; and they don't know me, but I know them through reading their column". Perhaps we need to write up such "use cases" and see what would help in each of them... The latter, for instance, raises issues of how to make sure only that journalist gets our message; clearly, we'll need to get some sort of public key or fingerprint thereof, either published by the journalist in some way that's hard to intercept, or through a directory we can somehow trust; but it's a different problem to talking to my friend Bob. Designing mathematical techniques and exploring what they can do is, of course, a vital activity, but I do suspect there's value in balancing it with more analysis from the user's perspective, to produce requirements we can use to drive our search for algorithms! ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
