Spark invisibility bug?

I have long been interested in xmpp as an IM solution but have always wanted the Invisibility feature of old school Instant Messengers (such as ICQ and MSN) but no implementation ever seemed to exist very well for it. I have tested a few things over the years and in recent times with the privacy lists/presences and the fact that a default openfire/spark combo does include a form of invisibility I’ve found there to be a slight oddity with which a person can easily determine whether or not someone is in fact online regardless of them being invisible or not. If you install a base openfire/spark setup you can add a friend, have them appear as invisible and use the “last activity” right click function to basically tell that they are in fact there despite them being invisible. Even if that person logs on as invisible, thus completely defeats the purpose. I’m not sure if this is a buggy implementation of the privacy lists or not, considering I tried the official ejabberd and another client… can’t recall which but it had a similar function to view idle time and it had the exact same problem.

So the question is, is this an implementation issue, or a bug or an unintended issue with regards to how the privacy lists/invisibility is handled? Even when it is all setup properly invisibility vs a party doesn’t work at all if that person uses the last activity/idle check because it will always say <1 minute when you are logged on as invisible. But if you aren’t logged in at all… it starts adding up as per normal.

One of the problem is that the XMPP specification is not very clear on how to handle invisibility.

There are three specifications (different approaches), one of them is rejected (XEP-0018: Invisible Presence), the other one is only experimental and doesn’t move forward (XEP-0186: Invisible Command) and the last one (XEP-0126: Invisibility) builds on top of Privacy Lists and feels a little bit like an intermediate solution.

Spark/Openfire uses Privacy Lists and Spark likely follows the recommendation in XEP-0126 to achieve that. However, only Presence is blocked with this approach, but not IQ stanzas. Therefore, Last Activity queries are still routed to the client and reveals information. Maybe it’s a good idea to block IQs as well to prevent this.

So it could be either an Openfire “bug”, because of this in XEP-0012:

A server MUST NOT allow an unauthorized entity to learn a user’s network availability by sending a Last Activity request to a JID of the form localpart@domain.tld or <localpart@domain.tld/resource>, since doing so would constitute a “presence leak” as described in RFC 6120. That is, Last Activity information MAY be divulged only to those entities that have permission to view the user’s presence via a presence subscription (potentially as restricted by Privacy Lists (XEP-0016) [5] or Blocking Command (XEP-0191) [6]).

or a Spark bug, because it could setup the Privacy Lists more restrictive (restriciting IQs as well).

Given that, IQ’s are used for many other uses cases, which would reveal presence (e.g. File Transfer or querying for Entity Time), restricting IQs are probably the better option.

In general, Invisibility is not easy to implement correctly, because of the many approaches and side effects like your example.

There is another issue which is more obvious for users to notice [SPARK-1593] Spark shouldn’t add Offline status when a user goes invisible - Jive Software Open Source

I don’t think this is a bug in itself. Just an isolated implementation. Invisible option in Spark just deals with the visual part (sets offline status). I don’t see any changes in the privacy list settings while turning visibility on and off, and i don’t see something going on with the privacy lists in the code. But Spark’s connection to the server is still alive and server is still logging its activity, so the check for Last activity returns what’s on the server.

Spark’s implementation of Invisibility is simplistic and not based on XEP-0126: Invisibility Which considers situation you’ve described:

  1. Security Considerations

For security concerns related to privacy lists, refer to RFC 3921. Care must be taken regarding privacy lists, especially so that visibility/invisibility rules do not overwrite existing rules the user has set for the sake of security and privacy; for details, see the Implementation Notes section of this document.

It is important to recognize that invisibility can be defeated without more advanced privacy lists than those defined above and an awareness of context on the part of a client. For example, if a user usually logs in as the same resource (e.g., “Home”), a contact can send an IQ request to that resource’s full JID using Last Activity (XEP-0012) [3], Service Discovery (XEP-0030) [4], Legacy Entity Time (XEP-0090) [5], or Software Version (XEP-0092) [6] and receive a reply, thus providing information that reveals the user’s availability. In addition, Last Activity requests sent by a subscribed contact to the user’s bare JID will normally reveal the user’s availability as well. To help ensure that the user’s invisibility cannot be defeated in this way, the user’s client SHOULD add IQ blocking to the relevant privacy list. Finally, the user’s client SHOULD NOT return “is-composing” events as defined in Message Events (XEP-0022) [7] or Chat State Notifications (XEP-0085) [8].

All i can do is file a ticket to fully implement XEP-0126 in Spark (replacing current option). But Spark doesn’t have good java developers for a long time, so it won’t be added anytime soon.

[SPARK-1630] Replace current Invisibility implementation with XEP-0126 compliant - Jive Software Open Source

Beat me again on a reply I’m not good with code, but i didn’t find any evidence of privacy lists being used in Spark’s Invisibility implementation. If it does use them, then it could be easier to do by adding IQ blocking.

Thanks for the replies, I was wondering if it was an issue that had come up before. Guess that answers the question. I know the xmpp protocol in general has had very little consensus on the whole Invisibility functionality and everything but the Privacy list option has either been in limbo or flat out rejected, so very few implementations actually have an appropriate system to deal with it at all. I was surprised when I saw Spark had anything relating to it. Does Spark give the user any option to manage/block IQ requests though I wonder. I’ll play with it later today and see if I can find a way around the situation.

I love the idea of self-hosted IM, but only if that implementation does provide some form of invisibility. Having used IM systems with and without, I actually find myself not logging into the ones that don’t or in the case of some mobile IM implementations I block them with my firewall when I don’t want to be disturbed or don’t want people to know I’m “around”. Though that doesn’t really work as well given that people just assume you’re out of coverage area or have your phone turned off.

Thanks for informing me though that the Spark team doesn’t have the skillset in current devs. I did get the impression by going onto the Freenode IRC channel that development has been sporadic lately.

Spark’s implementation of Invisibility is simplistic and not based on XEP-0126: Invisibility
Oh, honestly, I don’t know the exact implementation, but it was the only reasonable option for me, because Openfire doesn’t support the other two and I saw Privacy LIsts in Spark already.

It is possible to block IQ (info) requests in Spark’s privacy lists options. But after thinking more about it, i think it won’t help. As Last activity request is send to a server (i think). You can block IQ requests on your end, but the server will still reply with “idle <1 minute”. And even if you somehow block this, it will give an error, which will inform a user, that you are invisible. A server should “think” that you are offline to increase the idle time value. XEP explanation on this regard seems vague now.