[Standards] Using XMPP In A Mobile Environment

Florian Schmaus flo at geekplace.eu
Tue Feb 10 18:12:06 UTC 2015

Hi Sergey, thanks for you reply. :)

On 10.02.2015 09:11, Sergey Dobrov wrote:
> On 02/10/2015 01:57 AM, Florian Schmaus wrote:
>> 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 :)

Yep, but not all XMPP clients have an UI. It basically comes down to
"The XMPP client is responsible to avoid sending data where possible,
and if it does send data it should send as less data as possible, e.g.
by omitting the 'from' stanza attribute".

>> 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.

I'm not sure about that, Even if you defer all messages for only 30
seconds, realtime (chat) communication would become a pain. And there is
also little gain in that. I guess that only if your defer interval is
something > 15 minutes you will see a measurable positive effect on the
battery consumption.

>> 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
> anymore anyway.

IIRC that is what most CSI implementations already do.

>> I pointed out a possible attack scenario at my lightning talk [1],
>> 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?)

Please note that I'm not describing an extension of CSI. Bundling and
Deferring is a concept unrelated to CSI, their only relation is that
both come in handy in a mobile environment and that they are useless in
an environment where traffic volume and battery consumption doesn't count.

Also this is not meant as SPAM protection measure. That's not the scope
of the bundle and defer mechanism.

>> 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...

Yeah, but I guess exploring how this could be used together with SIFT
too. If it only had a roster/subscription state based filtering mechanism.

>> 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).

Not sure about the hiding of message content if the message already was
deferred. It seems to add just extra complexity without no big advantage.

>> 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?

Well we could say that if the client becomes active (by means of CSI),
all bundled and deferred stanzas are flushed (just like the presences
are). I would maybe mention this optimization in the spec but make it
optional, while noting that bundling and deferring should still happen
if the client is in active (CSI) state, because otherwise you circumvent
the protection.

>> - 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.

Are those notifications if a message got stored offline mandatory? I
think they are optional.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 668 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150210/dc2e407f/attachment.sig>

More information about the Standards mailing list