[messaging] Security arguments for read receipts

[Natanael]

Den 3 nov 2015 12:08 skrev "Ximin Luo" <infinity0 at pwned.gg>:
>
> I hear that OpenWhisperSystems don't want to implement "read receipts"
because
> they consider this to be a security issue, and have closed several user
tickets
> requesting this feature as "wont fix". I don't think it's a security
issue, at
> least not in a significant sense, and in fact I think *not* having read
> receipts is a worse security issue.
>
> Firsty, let's clear up some definitions: [...]

My comments below are partly based on what has been discussed previously on
multiparty communication.

Summary: users should be able to request acks for specific messages and
flag for when ordering (consistency) matters and needs to be confirmed by
the recipients. To be scalable, your device ignores consistency
requirements for participants you don't consider important.

My approach to doing this is through per-user hash chains of received
messages, and coloring/icons in the UX to show how many of the recipients
you declared you need confirmation from that has made confirmations, and
for when you're expected by others to make a confirmation. This can include
your program reordering all messages temporarily to let you see the view as
how the person making the request has seen it.

When all messages already are shown in the expected order, you get a
checkmark. When manual ack is requested, there can be an icon like
diagonally aligned numbers 1-2-3 in green, with a yellow exclamation mark
sign. Clicking it let you confirm it.

When they aren't in order, you could get an icon like diagonally aligned
numbers 1-2-3 in red, with a flag if an ack is manually requested. Tapping
it allows you to choose to see it in the expected order, and then to
confirm if requested.

> Benefits of auto-acks:
>
> 1. As the author, your messaging program automatically verifies that the
>    message was delivered successfully (reliability).
>
> 2. As a reader, your messaging program automatically verifies that other
>    readers also saw the messages (consistency).
>
> Specifically, you defend against (certain classes of) transport-level drop
> attacks and all attacks that depend on these, such as consistency attacks.

My approach above gives auto-acks for reliability, as well as chaining +
requests to show another's order for consistency.

You may chose to more rarely ack others messages and instead doing it in
batches, and only ack them sorted by hash value, not time, to not reveal
your order of receipt. You'd still have the above mentioned options to
manually request confirmation of order and to confirm such requests.

> Benefits of no auto-acks:
>
> 1. (reasonable argument) To avoid some notion of "creep factor" which some
>    people think is important. You don't want an author to know that you've
>    already received the message, because it would be socially awkward to
not
>    reply quickly, or something like that. You want to be in control of
when the
>    author gains that knowledge.
>
> 2. (fallacious argument) You leak timing information to an outside
attacker,
>    that might then use this information to deanonymise members of the
group.
>
> 3. (fallacious argument) Normal postal conversations don't have read
receipts,
>    so we shouldn't do this either. (Analogous to deniability argument in
OTR.)

To match multiple conflicting default mental models (in which all mental
models are understandable by everybody), my idea is to have multichannel
communication matching the different models, forcing everybody to
explicitly pick the channel that does what they want.

To do this, I'm imagining a Google Wave / Docs approach with IM and
annotation, where the document is persistent and have a signed history of
diffs (Git style), where annotations can be made deniable, and where the IM
is simply deniable (comments made to be shared are put in annotations).
Your program would have separate views for these, depending on your device
they could be shown in parallel. There could for example be a timeline view
showing everybody's perception of the order of messages and edits. I'll
make a blog post on this later.

(There can be a separate view gathering pending requests for confirmation
of view order, some kind of notification view.)

I also have a document model in mind, based on a database + defined views
(the closest practical analogy to what I imagine is TiddlyWiki + a database
in a single file, with separate CSS rules per screen type, including
print).

>    Non-repudiability is indeed specifically wanted in some cases. But
this is
>    such a small minority of use cases of OTR, that it's reasonable to say
"just
>    sign your messages using some other program". If it was wanted more, it
>    would be responsible to add this option to the protocol.

See above. Matching different expectations is best done by providing
different means of communication that match each set of expectations.

>    OTOH, read receipts are wanted in a much greater proportion of cases.
Yes,
>    they are relevant in asynchronous messaging. In practise, I definitely
worry
>    that my emails haven't been received, more than I worry about being
judged
>    at not replying quickly enough. Yes, a user study about this would be
nice.
>    But please don't make fallacies like 1(e) in those studies.
>
> Another proposal:
>
> The UI could let readers specifically manually ack a message (or multiple
at
> once), and warn *them* if they don't do this after a timeout - the same
timeout
> as the "message maybe not delivered" warning on the author's side, that
OWS
> probably won't implement. The reader-side warning could read "Your peer
isn't
> sure if you've received the message, don't leave them hanging!" or
something
> like that. When the author receives the ack, instead of displaying it as a
> whole new message (like how manual "I got this" acks would be displayed),
just
> mark a tick next to the appropriate acked messages.

See my UX comments above.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151103/5ebbaf79/attachment.html>