On 26 Aug 2014 16:42, "Kurt Zeilenga" <[email protected]> wrote: > > > On Aug 26, 2014, at 7:55 AM, Simon McVittie < [email protected]> wrote: > > > On 26/08/14 15:10, Kevin Smith wrote: > >> 30 says not to reply with disco to entities not authorised for your presence. > > > > Should the server follow this pseudocode for a disco instead? > > > > if target JID is bare: > > # any IQ to user@host is expected to be replied to by the server > > reply to it on the user's behalf, describing features of the > > server and the account (but nothing about the logged-in > > resources on that account, if any) > > JID existence leak. >
Certainly is. But if we're to block all possible jid existence leaks, everything breaks anyway. Consider: If I send [email protected] a subscription request, it will behave differently to sending one to [email protected] (here I'm assuming your email address is the same as your jid of course). Sending you a message versus sending a non-existent jid a message will also typically behave differently. These are, in general, desirable effects from a UX standpoint. The downside is that one can use them to harvest real jids for abuse and other nefarious purposes. However, it's not specific to Disco, and we should be careful of being distinctly uneven in our protection here. As such, my gut feeling is that this one case of jid existence leaking isn't worth worrying ourselves over. > > > > else if peer is authorized to see user's presence: > > # any IQ to user@host/resource is expected to be replied to > > # by that resource > > forward message to the named resource so it can respond > > > > else: > > <service-unavailable/> > > > > Regards, > > S > > >
