[jdev] The future of Jabber/XMPP?

[Evgeniy Khramtsov]

27.08.2010 19:54, Dave Cridland wrote:
> On Fri Aug 27 10:00:07 2010, Evgeniy Khramtsov wrote:
>> There is also a possibility where a malicious user can generate 
>> thousands of fake resources with different caps/features which you 
>> should also track. A server should also have a protection against 
>> this, especially if it is a small server.
>>
>>
> There are always attacks like this. A malicious user can generate 
> thousands of fake resources without PEP, and you still need to track 
> them in order to do presence optimization.

I'm not surprised if it is indeed possible in other places.

> So you're snooping all messages even from remote sources to guess if 
> they're PEP events intended to be filtered? How would you know? If I 
> (or my client) explicitly subscribes to a particular node on 
> PEP/PubSub-onna-jid service, you'd filter it out anyway.

If you have caps and valid disco#info then there will not be such 
problem. So it works in practice.

> I'm struggling to understand how that does not violate the XEP?
>
> auto-subscribe is defined as a depth=all items subscription to the 
> root node from the bare_jid, and filtered-notifications then only 
> sends the notifications to those full jids that have requested them. 
> Both are required for PEP. I don't see how you can claim to be 
> conformant to PEP without doing both.

Yes, but http://xmpp.org/extensions/xep-0163.html#notify-addressing para 
4 says:
"... if the PEP service does not have presence information about a 
subscriber, it MUST address the notification to the subscriber's bare 
JID (<localpart at domain.tld> or <domain.tld>)."

> So because you filter on the subscriber's end, you restrict 
> PubSub-onna-jid to the PEP subset, and because you don't filter on the 
> service end, you break even that if the subscriber isn't on ejabberd.

Well, strictly speaking yes. However such situation is uncommon it 
practice: all popular clients provide caps and disco#info.

> I don't see why you think this is a good thing.

I've said it before: it is easier to implement and doesn't require 
blowing up the memory with foreign crap.

-- 
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram at jabber.ru.