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