[Standards] PubSub Security considerations

Alexey Melnikov alexey.melnikov at isode.com
Fri Jun 12 09:53:45 UTC 2009

Ralph Meijer wrote:

>On Thu, 2009-06-11 at 19:20 -0400, Brian Cully wrote:
>>On Jun 11, 2009, at 11:31, Nicolas Vérité <nicolas.verite at process-one.n 
>>et> wrote:
>>>Dear all,
>>>In the "Security considerations" section of the PubSub spec, shouldn't
>>>we warn of the possible presence leaks, since subscribers (possibly
>>>not in the user's roster) are instantly notified of a user's
>>Agreed. This is a subtle condition and should probably be called out.
>I think it is a lot more subtle than summarized here.
>First off, the basic model of XEP-0060 is that there are nodes at some
>service and items get published to it by publishers. Subscribers to
>nodes get notifications on every publish, and the notifications do not
>expose which entity published that item. Basically, this means that a
>notification does not definitively expose an entity's availability, and
>not even their existence.
>Going further, notifications do not even imply explicit publish actions,
>but items could merely start to exist from within a system or by some
>out-of-band protocol, and cause a notification to be sent out.
>Second, XEP-0060 does not depend on XMPP IM, so entities do not
>necessarily represent people.
>Third, we explicitly started developing a publish-subscribe protocol
>because we consider information like the music somebody is playing on
>their desktop, or an entity's location are orthogonal to availability.
>Fourth, nodes themselves are not necessarily tied to a particular
>entity. In Personal Eventing (XEP-0163), of course, this is a bit
>different, because nodes are then tied to a entity's (person's?) user
>account. So here the existence of a user is exposed. I suppose this is a
>moot point because to discover such nodes, the existence of that user
>would already need to be exposed via some other means.
>But even then, a notification does not necessarily expose an entity's
>availability. The actual publisher could still be another entity (e.g.
>FireEagle publishing a location to your own XEP-0080 node).
>And finally, whether a particular notification exposes someone's
>availability highly depends on the semantics of the node and/or payload
>of the item being published.
>I think the only summary for a security consideration that covers all
>the above is 'use your common sense'. Since this in general is a good
>advice, I propose we don't add that to this specification, or any other
>for that matter.
I think you explanation is very good and I actually suggest it is added 
to the security consideration.

More information about the Standards mailing list