[jdev] The future of Jabber/XMPP?
xramtsov at gmail.com
Fri Aug 27 05:23:09 CDT 2010
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
"... 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.
Evgeniy Khramtsov, ProcessOne.
xmpp:xram at jabber.ru.
More information about the JDev