Virtual Presence Technical Note 4 2008.04.25 XMPP About this Note Number 4 Version 1 Date 2008.04.29 Category Informational Status Draft Short Name XMPP Document VPTN-4.txt Authors Heiner Wolf, hw, wolf.heiner@gmail.com Working Group - Dependencies - Supersedes - Superseded By - Abstract This document describes how virtual presence (VP) uses XMPP [1][2] as a VP transport protocol. It describes extensions to XMPP multi user chat [3] (MUC). Basically, VP uses plain XMPP and MUC plus few extensions to MUC. The extensions augment the user representation with additional user information like avatars, avatar positions and states. Table of Contents 1. Introduction.......................................................1 2. MUC Room...........................................................2 3. Appearance.........................................................2 4. State..............................................................2 4.1 Position.......................................................3 4.2 Condition......................................................3 5. Control............................................................3 5.1 Room Commands..................................................3 5.1.1 URL Limitation (require urlmask)...........................4 6. Security Considerations............................................4 6.1 Prevent Profiling..............................................4 6.2 Protect Public Room Lists......................................5 6.3 Reverse Mapping................................................5 7. References.........................................................5 8. Revisions..........................................................5 1. Introduction A XMPP chat room can turn a web page into a small virtual space. Participants are represented by avatars and these avatars can move around on the web page. Since the baseline XMPP MUC chat room has no provisions for avatars and avatar positions, there are some extensions required. XMPP 1 Virtual Presence Technical Note 4 2008.04.25 2. MUC Room A Jabber/XMMP chat room is a virtual presence location. A VP client joins a XMPP chat room to be present on a web page. The client maps the web page URL to a chat room JID as described in VPTN-2 [4]. Then the client sends a presence-stanza to the room. All rules of MUC [3] apply. Example: ...other nodes... 3. Appearance The identity data as described in VPTN-3 [5] uses 3 pieces of information for each participant in a MUC room: - identity URL - identity digest - identity ID All 3 parts are text strings. They are added to the XMPP room presence stanza by means of an extension node. Example: ...other nodes... The identity-node should be included in all presence-stanzas to a MUC room so, that new participants get the latest data when they enter: 4. State Avatars may move around on the web page. They may also appear in a certain state. The state-node carries information about the state of the avatar in the virtual space, e.g.: - position relative to the web page in coordinates - condition like sleeping when offline, sitting, open, etc. Example: XMPP 2 Virtual Presence Technical Note 4 2008.04.25 ...other nodes... This information is included in all presence-stanzas to a MUC room so, that new participants get the latest data. 4.1 Position The position-node contains coordinates of avatar relative to the lower left corner of the web page content in pixels. The position may be 1- (x), 2- (x,y) or 3- (x,y,z) dimensional. The x coordinate extends from the left border of the web page to the right. The y-coordinate from the lower border up. The z-coordinate from the "plane" of the web page to the front. Positive z- coordinates make avatars appear closer to the viewer, if the dimension is supported by the VP display. Examples: 4.2 Condition The condition-node indicates a status. As an example, the avatar may be in a "sleeping" status and show an appropriate image. New participants who arrive after a status change will be able to show the correct status, because the condition-node as part of the state-extension is included in every presence-stanza. Examples: Note: a client may use the status string to select an image or an animation from the identity data. Note: a treasure chest might be status="open" and the client may display different ways of interaction for the status (think of "inspect", "loot"). The status defaults to "idle", which means the default picture, the default animation, maybe even with random idle moves. 5. Control 5.1 Room Commands The room may send commands to the client. The room uses a /-command XMPP 3 Virtual Presence Technical Note 4 2008.04.25 syntax. Virtual presence related commands are prefixed by "/vp". The only command currently defined is: - require The room sends commands as chat messages. A command starts with "/vp" and ends with "#". Text after the "#" is a human readable comment. 5.1.1 URL Limitation (require urlmask) A room can tell the client, that it serves as a location for certain URLs only. This is usually the case anyway since the URL mapping maps only a limited set of URLs to a room. But malicious web site operators may choose to point to a "foreign" chat room which is populated by another web site. This is a way to simulate high VP traffic on a sparsely populated web site. Visitors of the sparsely populated site join visitors of another more frequented site. If the topics match then users might not notice that they are in the same room although they are on unrelated web sites. This might be a bad situation for the operator of the more frequented site. To prevent this kind of "location hijacking" the chat room can instruct the client to serve only for certain URLs. Using the "urlmask" parameter, the room sends a regular expression to the client. The client checks if the document URL matches the regular expression. If the URL does not match, then the client should leave the room immediately. Example: /vp require urlmask ^http://.*mydomain\. # Need mydomain 6. Security Considerations 6.1 Prevent Profiling Large chat servers which host multiple VP locations may get traffic of users on different web pages. They may associate identity IDs, JIDs or identity URLs in order to record a profile for individual users. In short: they should not do so even though it is possible. Analyzing traffic for profiling purposes is indecent. The possibility of chat servers to do profiling is greatly reduced, if the traffic is distributed over many independent chat servers. Hence, web site operators should choose different chat servers [4] or operate their own XMPP chat server. If there are as many XMPP chat servers as there are HTTP servers, then profiling beyond already existing HTTP server logs is impossible. XMPP 4 Virtual Presence Technical Note 4 2008.04.25 6.2 Protect Public Room Lists Some XMPP servers expose room or participant lists to the public. The information can be accessed by any XMPP client using browse or disco protocols. XMPP servers which host VP locations should not expose room or participant lists to the public. The access should be restricted to administrative uses or to trusted services. 6.3 Reverse Mapping An important feature of the URL mapping process is to protect the user's click stream. URLs will usually be hashed and not sent over the network unless specified otherwise by the web site operator. This protection can be invalidated with significant effort by calculating and storing the reverse mapping for many URLs. If room and participant lists are public and if such a reverse mapping is available, then it is possible to reconstruct partial click streams of users over different web sites. Such a "reverse mapping" attack on user privacy is only possible under the conditions discussed above. But even in this case, web site operators can counter potential reverse mapping attacks by frequently changing the URL mapping to different rooms (e.g. each day). If many web sites add a "salt" to their mapping rules, then profiling by reverse mapping does not work. 7. References [1] RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core, http://www.ietf.org/rfc/rfc3920.txt [2] RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence, http://www.ietf.org/rfc/rfc3921.txt [3] XEP-0045: Multi-User Chat, www.xmpp.org/extensions/xep- 0045.html [4] VPTN-2: Location Mapping, Virtual Presence Technical Note, http://www.virtual-presence.org/notes/VPTN-2.txt [5] VPTN-3: User Data, Virtual Presence Technical Note, http://www.virtual-presence.org/notes/VPTN-3.txt 8. Revisions 1 hw 2007.11.11 Created 2 hw 2008.04.25 First release XMPP 5