[Standards] Current OTR Info

Chris Ballinger chris at chatsecure.org
Tue May 10 05:23:09 UTC 2016


Aye same here, as of v3.2.2 we don't send receipt on decryption failure. It
seems XEP-0184 leaves it open to not send a receipt for any reason, as long
as the other side must never rely on the receipt / lack of receipt for..
anything.

We don't yet send an error response, but I'll take a look at what you've
done. Ideally the sender should recognize the error message and
automatically resend.



On Mon, May 9, 2016 at 3:13 PM, Daniel Gultsch <daniel at gultsch.de> wrote:

> FWIW Conversations does exactly this: Not send the delivery receipt and
> send and error message if the message is unreadable. (But otherwise
> correctly addressed to our full jid)
>
> 2016-05-10 0:09 GMT+02:00 Dave Cridland <dave at cridland.net>:
>
>>
>>
>> On 9 May 2016 at 22:49, Brian Cully <bcully at gmail.com> wrote:
>>
>>>
>>> > On 9-May-2016, at 03:48, Dave Cridland <dave at cridland.net> wrote:
>>> > Lack of a delivery receipt isn't perfect, but it's a
>>> backwards-compatible solution that will match the overall semantic of "this
>>> message stands no chance of being read". Over-analysis would push us into a
>>> horrible place where we're trying to gauge the user's linguistic ability or
>>> contextual knowledge, and that's not actually going to be a useful solution.
>>> >
>>> > Sending errors to allow some technical problem to be remediated is
>>> useful - but it's a secondary concern to ensuring the user is aware there's
>>> *some* kind of communications problem.
>>> >
>>> > This thinking is why I've ended up preferring loose behaviours in
>>> specifications - there's no interoperability concern in having receipts not
>>> sent for (say) bad crypto, or even not sending a receipt for message half
>>> in cyrillic selling pwned computers - but the semantic indicated is a
>>> better match than following the "pure delivery" semantic slavishly.
>>>
>>>         I’d say there’s already a generic way to handle this by sending
>>> message of type ‘error’ back with some condition describing it. Clients
>>> already process those stanzas, and in cases where an ‘id’ is present on the
>>> initiating message (such as every message requesting delivery receipts),
>>> can even tie the error to the specific stanza that caused it.
>>>
>>>         Why do we need to add behavior to delivery receipts when there’s
>>> already a generic mechanism for handling errors on received messages?
>>>
>>
>> Fair comment. Either (or both) is good. The questions are:
>>
>> a) Does the proposal cause an interoperability issue, and
>> b) Does the proposal cause any security concerns, and
>> c) Will it result in a better experience for the user.
>>
>> As long as it's "No", "No", and "Yes" respectively anything else is
>> getting alarmingly close to a bikeshed - either approach (or indeed both)
>> satisfies the concern that the user can be made aware that something is
>> wrong and the messages aren't getting through.
>>
>> So I'd be happy to have the spec allow (and maybe encourage) clients to
>> not return delivery receipts for message stanzas they cannot process, and
>> by all means send errors as long as they don't provide any oracles etc.
>>
>> Dave.
>>
>>
>>> -bjc
>>>
>>> _______________________________________________
>>> Standards mailing list
>>> Info: http://mail.jabber.org/mailman/listinfo/standards
>>> Unsubscribe: Standards-unsubscribe at xmpp.org
>>> _______________________________________________
>>>
>>
>>
>> _______________________________________________
>> Standards mailing list
>> Info: http://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
>> _______________________________________________
>>
>>
>
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160509/8cb0ea0a/attachment-0001.html>


More information about the Standards mailing list