[standards-jig] Serious Issues with JEP 0024

Adam Theo theo at theoretic.com
Fri Jul 19 04:28:58 UTC 2002


DJ Adams wrote:
> On Wed, Jul 10, 2002 at 10:27:52PM -0400, Adam Theo wrote:
> 
>>Well, I can accept this, although your JEP does cover order of
>>processing after Example 11: "In the case where multiple <subscribe/>s
>>or <unsubscribe/>s appear in an action, each element will be processed
>>in turn, as they appear in the payload.". Unless this means that the
>>order in which they come in may not be the same order as they are sent
>>by the subscriber due to mid-transport jumbling?
> 
> 
> Well, I guess it's down to belt-n-braces, that's all. It's not a big point,
> and if we could dictate the processing order then there shouldn't be any
> problems (famous last words). I just prefer simplicity over complexity[*].
> We could strengthen the wording around the implementation requirement, and
> perhaps relax the restriction. I'm ambivalent, if push comes to shove.

Pretty much ditto here, too. Being able to put <subscribe>s and 
<unsubscribe>s in the same <query> by processing them in order is not a 
big deal, and I'll drop it until the other issues are dealt with, 
especially since I'm now just fine having it as you have it in the spec.

>>Well, this issue I'm still pretty concerned about. I don't think the
>>issue becomes moot eventually simply because there is existing
>>infrastructure that makes heavy, and proper, use of the <message>
>>packets. Without support for <message>, you cannot publish email-like
>>[...]
>>I'm not asking to support <message> instead of <iq>, but support *both*.
>>Possibly by by specifying what type of element (iq or message) to use as
>>well as type of message/iq (normal, chat, headline...).
> 
> Well, as it happens, I am already experimenting with this - see 
> http://www.pipetree.com/qmacro/2002/Jul/3#weblogspubsub for details. 
> But while I agree that supporting both is a possibility (and forgoing
> IQs because "it's too complex"/"no existing client supports it" is a
> difficult one to debate :-), the problem is how to come up with a generic
> definition of what format the content of the <message/> elements should
> be. Let alone the negotiation of what the client wants. In my weblogs-
> pubsub mechanism mentioned, I, as the author of the component, was able
> to decide what the clients would receive. But how do you decide what to
> put in a <message/>? 

Well, I'm not sure what you mean here. The content of messages would be 
chat/normal-like messages, mostly for purposes of easy creation of chat 
rooms (like jdev at conference.jabber.org) or mailing lists (like this 
standards-jig at jabber.org).

>>> It's worth pointing out too that some (not necessarily all) of
>>> the
>> concerns
>>> regarding authorization could be addressed by having pubsub
>> components for
>>> specific areas of publishing, and auth-proxying those components
>>> in
>> conjunction
>>> with advertising. (Auth-proxying in the sense shown in 
>>> Jabber::Component::Proxy).
>>
>>Not sure what you mean here. I can't follow the perl module (I'm not a
>>programmer). Would you or someone else mind explaining this to me?
>
> There's some docu here: http://www.pipetree.com/jabber/jabbercomponentproxy/
> I've written an article on it too, it should be coming out soon... :-/

OK, I understand now, thanks. I'm not particularly fond of this access 
controlo solution, but will bother bringing this up later, both when 
other issues are resolved and when I get time to start working on a 
Permissions & Access Control Core Tool Protocol 
[http://www.theoretic.com/?Jabber_Environments] JEP to work with pubsub 
and disco (and other Core Tool Protocols).

>>Sorry, I should have used "subscribe to everyone" instead of adding
>>"everything" in there, too. I am not concerned with the everything part,
>>but I am with the everyone. Just mass-requesting a presence subscription 
>>from everyone on the component is what I'm talking about, really. This
>>would allow spammers to see what accounts likely have humans behind them
>>and put them on spam lists.
> 
> I'm not sure how you see this happening...why would a subscription request
> to receive any publications from a particular publisher turn into a mass-
> request of presence "from everyone on the component"? (I may have 
> misunderstood what you mean). In any case, presence subscription is only
> reciprocated by the component, not initiated, and certainly not done
> en masse.

Hmm... /me rereads DJ's spec to make sure he understands, too...

OK, I'll go into some length here since this is a big issue for me.

Your subscription protocol uses a <subscribe> tag inside a <query> tag 
to allow anyone to subscribe to a particular namespace/topicID under a 
particular publisher JID. Example:

SEND: <iq type='set' to='pubsub.localhost'
              from='subscriber at localhost/resource' id='s1'>
         <query xmlns='jabber:iq:pubsub'>
           <subscribe to='publisher'>
             <ns>namespace:1</ns>
             <ns>namespace:2</ns>
           </subscribe>
         </query>
       </iq>

Your spec also allows for subscribing to all specific namespaces by any 
and all publishers on the component. Say "presence" is the typical 
namespace/topicID for broadcasting presence, someone can request *all* 
"presence" topics from *all* publishers on the server. Example (note 
missing 'to' attribute in <subscribe>):

SEND: <iq type='set' to='pubsub.localhost'
              from='subscriber at localhost/resource' id='s1'>
         <query xmlns='jabber:iq:pubsub'>
           <subscribe>
             <ns>namespace:1</ns>
             <ns>namespace:2</ns>
           </subscribe>
         </query>
       </iq>

By allowing this you allow a spammer to get a list of JIDs that very 
likely have humans behind them one way or another. The spammer simply 
needs to request publisher-agnostic subscriptions to a specific 
namespace/topicID. The subscription request made is not to a particular 
publisher, it is to all of them.

If there is a access control mechanism in place, then all publishers get 
a request. Those that agree are likely then automatically put on the 
spammer's whitelist of addresses with "real" people behind them. If they 
do not have an access control mechanism in place, then they are not even 
requested, and even more publishers are put on the spammer's whitelist 
(all of them, in fact). It would be a spammer's heaven.

This is a Bad Thing(tm).

>> > How will that work? Presumably the spamming publishers will have 
>>something
>> > juicy to tempt people to subscribe to?
>>
>>Well, yes, of course. Publishers that have a subscriber base and have
>>the intention of farming then selling the addresses of that base will
>>likely just run their own pubsub component that people must subscribe
>>to. Then they will fetch the addresses from that. Keeping subscribers
>>anonymous in any way from the publisher but not the component won't
> 
> I must admit, I've never managed to get too concerned about this sort of
> spam. On the one hand, there's a concern about presence subscriptions 
> (which I can't quite see the reasoning behind), presumably to protect
> the identity of the subscriber JIDs, but on the other hand this addition
> goes in the other direction (i.e. a publisher can "harvest" the JIDs
> by requesting who has subscribed).

I've had a bit of a revelation that allows subscribers to stay 
relatively annonymous while giving publishers enough information about 
their subscriber base to feel happy. I'll post about it in another 
message after this.

>>So, how is this for a query protocol for publishers to use?
>>
>><iq type='get' to='pubsub.localhost'
>>              from='subscriber at localhost/resource' id='s1'>
>>         <query xmlns='jabber:iq:pubsub'>
>>           <subscribers/>
>>         </query>
>>       </iq>
>>
>>Note the <subscribers> instead of <subscribe>. This probably is not the 
>>best solution, but it's a start, in an attempt to get the ball rolling.
> 
> Well, I would say the tagnames themselves are secondary. Do we assume 
> from the discussion so far, though, that subscribers don't have a choice
> about anonymity? Does it matter? And what worth is knowing a subscriber 
> list when the subscribers are just pubsub repeaters in a hierarchical 
> fan-out?

If you are referring to your spec's proxy subscriber idea, then yes, I 
see your point. What I've decided to aim for now is a system where the 
publisher can control who subscribes via a seperate permissions and 
access control mechanism/protocol, and subscribers remain anonymous if 
they want to, even if they are behind a proxy. This will be in the later 
post, mentioned above.

-- 
     /\  Adam Theo, Age 23, Tallahassee FL USA
    //\\   Email & Jabber: theo at theoretic.com
   //  \\  (Boycotting AOL, therefore no AIM or ICQ)
=//====\\=
//  ||  \\  Theoretic Solutions: http://www.theoretic.com
     ||         "Building Ideas by Bringing them Together"
     ||      Jabber Protocol: http://www.jabber.org
     ||         "The Next Generation Communications Protocol"
     ||  "A Free-Market Socialist Patriotic American Buddhist"




More information about the Standards mailing list