[Standards] Using XMPP In A Mobile Environment
binary at jrudevels.org
Tue Feb 10 08:11:42 UTC 2015
Hi Florian and folks,
On 02/10/2015 01:57 AM, Florian Schmaus wrote:
> XEP-352: Client State Indication (CSI) is a big step towards reducing
> XMPP battery usage which is crucial in a mobile environment.
> But IMHO there is one piece missing. If we assume that the outbound
> traffic of a mobile device is not causing any unwanted battery drain,
> that is because if the device sends something it usually has a pretty
> good reason to do so, it becomes obvious that we need to focus on
> inbound traffic.
I'd say it another way: we can move the responsibility to client as it
tightly depends on client's UI and approaches so they need to decide,
this will be a way of competing among clients :)
> Let's start by classifying inbound stanzas into three types. There are
> stanza that…
> 1. require immediate delivery
Even those stanzas can be slightly deferred and be bundled, I believe.
Just the interval will be much thicker, and still it can reduce number
of necessary wakes up.
> 2. can be delayed
> 3. should not be delivered at all
> The appealing simplicity of CSI is that it categorizes presences
> stanzas as type 2., and simply delays them until the client reports
> that it is active.
I think that we also should remove presences from sending queue when new
presence from the same full JID has came, as old ones are not needed
> I pointed out a possible attack scenario at my lightning talk ,
> where a malicious entity drains the victims battery by repeatedly
> sending XMPP stanzas to the victims mobile. The stanzas originating by
> the malicious entity obviously are of type 3.
I think that this is a completely different problems actually because
this can happen also with subscribed contacts, so it's unnecessary to
focus on this problem in as part of CSI. Instead, some new security
protocols should be invented including spam protection. (They are too
complicated to discuss them here, I think?)
> A possible countermeasure would be using Privacy Lists (XEP-16) to
> block all incoming stanzas from entities not in the user's
> roster. When I told Chris Deering about that, his response was that
> this would yield a bad UX. And he is of course right. There is no way to
> reliable know if a stanza is of type 3. But do we really need that?
Probably, those security protocols should be extensions to Privacy Lists...
> The missing piece I was talking about at the beginning, is a mechanism
> to *bundle and defer* stanzas (usually messages): Particular stanzas are
> bundled and their delivery to the (mobile) user is deferred, so that the
> stanzas are send in bulk, giving the mobile device the possibility to
> enter sleep mode while the stanzas are deferred. This could (typically)
> apply to stanzas send from entities which don't have a subscription to
> the users presence.
ALSO, if client supports such a feature, we could actually hide the
message content (if it exceeds certain size) and offer to fetch it with
MAM later if needed. (just as PubSub does when content delivery in
events is switched off in node configuration).
> So the basic idea is clear, but I'm undecided how to specify such an
> mechanism. For example:
> - Should the stanzas which are bundled and deferred be matched by
> - Privacy Lists
> - SIFT. But SIFT has no way to filter on roster status (e.g. "If sender is
> not subscribed to my presence, defer and bundle the stanza he
> wants to send to me" :-( )
> - Delay Time? I'm thinking about recommending 15-30 minutes, while
> warning that it should be not less then 15 minutes (a typical SMTP
> greylisting timeout).
But it can be less than 15 minutes if device wakes up earlier, right?
> - Should the server send a "your message has been queued for later
> delivery" message back to the sender?
Yes, I believe it is must have. Just like the notifying that the message
has been stored in the offline storage.
> I'd love to hear some feedback, and if someone is willing to
> collaborate working on a specification it would be welcomed too.
Not sure that I really can be helpful here but I'd love to discuss and
give feedbacks on the things I'm smart enough to comment on :)
> - Florian
With best regards,
XMPP Developer and JRuDevels.org founder.
More information about the Standards