Den 3 nov 2015 12:08 skrev "Ximin Luo" <<a href="mailto:infinity0@pwned.gg">infinity0@pwned.gg</a>>: > > 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.