Hi, On Tue, 22 Sep 2009 13:38:00 +0300, Peter Petrov <[email protected]> wrote: > On Tue, Sep 22, 2009 at 10:40 AM, Jehan <[email protected]> wrote: > >> >> To come back to the specific issue of temporary pubsub subscription with >> SASL ANONYMOUS. The problem is that a pubsub server does not "know" when >> you are using a transient JID (as one can read on XEP-0175, a randomly >> generated JID has nothing particular to identify it as being transient). >> So should it be the responsability of the user's client to make the >> subscription "temporary" automatically (without user's action) when the >> user subscribes while anonymously connected? >> > > This is not enough, the node owner (or service owner, but the former is > preferable) should be able to force it. Imagine that you have a service > where 100% of the clients have temporary JIDs (this is not just > hypothetical, I happen to be involved with one such service). In this case, > allowing non-temporary subscriptions would allow a malicious client to > easily and quickly create tons of subscriptions on a busy node, leading to > an overload. Enforcing temporary subscriptions makes such an attack > impossible (or at least much harder), as the attacker would have to keep an > open connection for each subscription. >
Ok. So case 1 is not good (client deals with it), I agree. Case 3 is not feasible (the JID is recognizable as a temporary one), unless you create a new syntax for identifying a temporary JID from a permanent one. But I guess this is not a good thing. Case 2 (your server modifies a subscription query to make your subscription temporary) is not that good, in my opinion, because it means the server has to process every query to check it is not a subscription and if it has set the right "temporary" option, then add it if absent. And if you imagine this must be done as well for other kind of interaction. For instance if the temporary JID is added into someone's roster, should it the server's job to send an unsubscription query once the temp JID has disconnected? And so on. A lot of burden and every case must be thought (which is obviously not possible, at least for one thing: when a feature is not known by your server, maybe because it is program specific for instance, then it does not know its semantic and cannot change it). But I have thought of a case 2bis: the user's server just add a "flag" on every stanza which comes from a temporary JID. This flag would be typically some attribute on the stanza, probably with an appropriate namespace (the one of xmpp-sasl for instance?) telling "eh this stanza comes from an anonymous connection". This way, on the server, there is not too much additional processing (just an added attribute), and you deal with any cases (even with stanzas whose content the server does not understand). Then the service server detects this flag and acts accordingly. For instance a pubsub server receiving a subscription stanza with such a flag would allow only temporary subscription based on presence. I think this deals well with this problematic. > Correct, but in some situations full JID subscriptions are preferable to > bare JID ones. E.g. when a user logs in on several machines, but each > instance is only interested in the nodes it has explicitly open. In this > case bare JID subscriptions would only result in useless traffic (if they > work correctly at all, because AFAIK it's not precisely specified to which > resources notifications will be delivered). Such cases are difficult because a resource easily "forgotten" (I don't even know my resources. I always keep the default resource name of any client I use). A resource is clearly not as time-stable than, nor remembered as, the bare JID. So it is very easy to make many subscriptions which would therefore become ghost subscriptions later on, when you change your client/computer/resource (even without any malice from you). What could be done is that when subscribing with a full JID, then the subscription should be by default temporary, whereas for bare JID the subscription default is permanent (can be considered into a "Good practice" XEP for PubSub servers default options). Of course this could be changed by the user if he wants to make a full JID subscription permanent (he perfectly knows his resource, won't forget it, etc. In other words: he knows what he is doing). As it is already some advanced usage of pubsub (no?), I think it is good that way. Bye. Jehan -- Que la Sainte Marmotte soit avec moi! Pour me contacter: IM: [email protected] email: [email protected] http://jehan.zemarmot.net
