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.
Let's start by classifying inbound stanzas into three types. There are
stanza that…
1. require immediate delivery
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 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.
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?
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.
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).
- Should the server send a "your message has been queued for later
delivery" message back to the sender?
I'd love to hear some feedback, and if someone is willing to
collaborate working on a specification it would be welcomed too.
- Florian
signature.asc
Description: OpenPGP digital signature
