Web Client

The web client (more interesting name pending) is the Volity team's project to create a full-featured client that will run in any modern browser. The UI files that it will support include JavaScript-driven HTML/CSS applications as well as Flash or Java applets - really, anything capable of using ECMAScript to pass messages to and from its container page.

The web project is led by Jason McIntosh, and its development is one of the chief current concerns of the whole Volity project, with the goal of having a stable beta release across the volity.net website by the end of 2007.

Status and Availability

The web client's public code is in Volity's Subversion repository, under /trunk/web-client. You can also find release snapshots in /tags/web-client.

Currently, Testbench has been ported to HTML, and includes demonstrations of both pure-HTML and Flash-based UI files.

• [Pure HTML demonstration]
• [Flash demonstration]

The existence of a web-targeting Testbench effectively means that particularly forward-thinking Volity hackers can start creating UI files for the web client right away; even though the Testbench software itself is alpha, the Volity protocol it implements has been in stable beta for a long time.

The Testbench application (as well as source for the above examples) is available within the web client's Subversion directory.

Work on the actual client application is well underway - much of the code written for Testbench will actually end up being shared by it.

Security Concerns

We are very concerned with security, and want to make sure that, like all good web applications, the Volity web client is locked down tight against malware. Since Volity includes a payment protocol, we must also guard against any way an attacker could spend or redeem another user's gameplay tokens, or obtain tokens in any shady way.

As the client's own design develops, we will update this section with a summary of how we're keeping it safe.

Angles of concern:

• Malicious UI code. A Volity UI is user-contributed web content, served by a Volity project web server. That gives people an opportunity to hang dirty laundry on our line. (This problem exists already, with Gamut loading SVG UIs. But Gamut is much more sandboxed and less flexible than everybody's web browser.)

• Cross-site scripting. Same problem as above, except in a fancy way that I don't really understand. (Mitigation: the web client will not see these UIs at volity.net, or even volity.org. They'll be browsing a domain dedicated to that purpose. The dedicated game domain will not have any route for user login or preferences editing.)

• Eavesdropping and man-in-middle attacks. We're used to all Volity traffic running over XMPP, which uses socket-level encryption by default (TLS). The web client adds another communication link before the XMPP connection. For alpha development, this runs over unencrypted HTTP. Before we go beta, we plan to get HTTPS working. The final system may use HTTPS by default.