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 at 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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.