[messaging] Security arguments for read receipts

[Ximin Luo]

Hi Nataneal,

It sounds like you have a specific proposal in mind, for a system that has auto-acks. It would be good if you wrote this up in a separate document.

My post was about why auto-acks are desireable in the first place. I specifically tried to ignore how one might implement this, because that is not relevant for user-level security arguments. (Even in a concrete proposal, it's good to separate out the *justification* from the implementation.) For example, I'm not seeing how parts of what you wrote, match up in reply to what I wrote.

One comment I'd like to make is regarding this:

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

Giving this much choice to the user I think is unnecessary complexity. What security benefit does it give, to justify that? In my previous post I suggested a per-conversation setting. In which real cases do you actually need more fine-grained control than that?

Other parts of your post mention things like ordering, as well as different models of communication. But I'm missing the background of what you're referring to - what ordering assumptions, what models you have in mind - so it's hard for me to concretely understand what you wrote. Also note that Git is a history of *state*, not diffs. Authentication is done over *state* (including history), and the diffs are calculated implicitly after you verify all of this.

I'd be interested in reading your blog post when you get around to it. But beware that that type of medium tends to get out-of-date pretty quickly; I'd suggest something like a github documentation repo.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git