Re: [xmpp] 3921bis: probe + unavailable

[Ben Schumacher <[e-mail]>]

On 01/28/2010 02:40 PM, Dave Cridland wrote:
>> b. Someone poked me offlist about a potential security issue here: what
>> if the probing user was blocked from receiving the contact's presence at
>> that time (e.g. via privacy lists)?
>
> Right.
>
>>    2.  Else, if the contact has no available resources, then the server
>>        MUST reply to the presence probe by sending to the user a
>>        presence stanza of type "unavailable"; this presence stanza
>>        SHOULD be empty but (subject to local security policies) MAY
>>        include the full XML of the last unavailable presence stanza that
>>        the server received from the contact.
>
> Replace SHOULD with "will typically be". You can't have SHOULD but 
> MAY, I think, and it's not an interop requirement.
>
> Also, you might stamp it with a delay, in which case it's not empty...
>
> Dave.

As the person responsible for the offlist poking, I feel I should step 
up and point out that stamping delay constitutes a presence leak. If I 
had a privacy list that blocked you, Dave, from receiving my presence 
while I'm online then I got offline and the server then decides to 
respond to probes that indicate when I was last online, you now know 
that I was online and trying to hide that fact from you.

An empty presence type="unavailable" is the only way to ensure (without 
some really complex heavy lifting on the server) that you're properly 
indicating that the user isn't here right now, and that's all. I would 
further recommend that this unavailable presence MUST be from the bare 
JID (user@host) as the server should be indicating that this Presence 
Entity is unavailable, rather than a session (if you're going to send 
the last unavailable, then the server ought to rewrite the from to this 
effect).

Finally, (and this isn't RFC related) the privacy list XEP(s?) should be 
updated to indicate that the same behavior should be followed.

Cheers,
Ben