The Tools Series is a series of Baltan Sessions that examines the complex and changing relationships artists and designers have with the technologies and tools they develop, modify or use to create, with an aim to explore social awareness around the tool choices they make as well as the (aesthetic) influences of these choices on the work they create.

During the Naked on Pluto project one of the key ways to confront the problems of centralised social networks turned out to be to encourage a deeper understanding of the processes and protocols of these sites.

So, like the previous workshop at CCCB, we centred this around a web application called FaceSponge, which we developed as a social programming interface giving quick access to the Facebook API and allowing participants to try out each other’s scripts. The other key issue was to find out people’s opinions, and so we collected answers on post-it’s to three questions for each area, which the participants later sorted for presentation to the public.

Social advertising

This workshop was perfectly timed with Facebook’s IPO, and as 82% of it’s revenue comes from advertising we started off by working on a simple spoof advert. We took one friend, and picked something they have ‘liked’ and wrote some code to promote it. This is what happens on social networks where a brand gets advertised to you because one of your friends follows or likes it. Being able to put a friend’s name in an advert is seen as an exciting future of advertising (or perhaps less so as the share price continues to drop).

function runme() {
    FB.api("/me/friends", function(friends) {
        var friend=friends.data[0];
        FB.api("/"+friend.id+"/likes", function(likes) {
            var like=likes.data[0];
            display(friend.name+" endorses "+like.name+" BUY SEVERAL TODAY!");
            FB.api("/"+like.id+"/picture?type=large", function(picture) {
                display_image(picture);
            });
        });
    });
}

Privacy

There are vast amounts of pictures available on facebook, and it was fun to write a script that presented them all back at in a chaotic manner without any other information. This also gave us a chance to show how the privacy on Facebook is imaginary, as the URL’s FB gives you for your friend’s pictures are public – regardless of anyone’s privacy settings.

// showing the holes in the walls                                               
// you think your photos are private?                                           
// these images are accessible without a login                                  
function runme() {
    FB.api('/me/friends', function(friends) {
        friends.data.forEach(function(friend) {
            FB.api('/'+friend.id+'/photos', function(f) {
                 if (f.data.length>0) {
                     var gallery=f.data[0];
                     // show the public url                                     
                     display(gallery.images[0].source);
                     // show the image                                          
                     display_image(gallery.images[0].source);
                 }
            });
        });
    });
}

Social pressures

The third area we were interested in exploring was the more subtle ways that social media are affecting communication methods. We came up with this strange script that collects the last things posted by your friends and puts them together without information on who posted them, or who they are for:

function runme() {
    FB.api('/me/friends', function(friends) {
        friends.data.forEach(function(friend) {
            FB.api('/'+friend.id+'/feed', function(feed) {
                if (feed.data && feed.data.length>0
                    && feed.data[0].message) {
                    display(feed.data[0].message);
                }
            });
        });
    });
}

We continued to play with and adapt these scripts in order to show more information. The mood was interesting as it flipped from serious to hilarity and then slight awkwardness at what we were dredging up. We followed each of these practical sessions by collecting feedback on thoughts and emotions for each section. Although this was a very demanding workshop (changing between coding, politics, funny juxtapositions of friend’s personal data and having to think about how it felt) we recorded a wide range of thoughts – from the dismissive, “doesn’t matter” to the outright enraged. Perhaps one of the most important aspects of this workshop was being able to expose these mechanisms to groups of people normally considered ‘users’.

Session organised in collaboration with Fundación Telefónica.

WORKSHOP: Facesponge with Aymeric Mansoux and Gerald Kogler. 10h-14h

Have you ever wondered what is going on “behind the scenes” on social networks like Facebook? In this workshop we will explore our so-called social data and get a glimpse at how it is viewed by the company and third parties who access it. In order to break several myths about Facebook applications, you will be invited to take part in designing small programs that extracts and manipulate you and your friend’s online information. Nothing will be written back to Facebook at any time, we will only be reading existing data. No data will be collected or viewable by anyone else.

No programming experience is required. Basic knowledge of javascript can be useful to explore more advanced possibilities of the Facesponge sandbox.

This workshop is part of the Naked on Pluto project, a critical text adventure Facebook game concerned with issues of online privacy and control within centralized commercial social networks, designed and written by Marloes de Valk, Aymeric Mansoux and Dave Griffiths.

Facesponge is developed in collaboration with Baltan Laboratories.
All Naked on Pluto software is released under free culture licenses.

Schedule:

* Naked on Pluto presentation
* Gameplay session
* Anatomy of an FB app
* Introduction to Facesponge
* Breaking FB apps myths
* Group discussion

Practical information:

* The workshop will be taught in English.
* You will need to bring your own laptop.
* Places are limited.

DEBATE: Identity and simulation. Artificial life on the networks. With Jussi Parikka, Pau Waelder, Aymeric Mansoux and Mónica Bello. 19h-21h

Internet is changing our way of understanding the public space. The Web has become a dominant structure that covers all aspects of contemporary society. The proliferation of virtual agents, designed to stimulate non-fortuitous reactions and meetings, reconfigures the profile of individuals in dynamics that are innovative but also invasive, and generates new forms of control. In this brand new context, identity and simulation become decisive themes of behaviour on the Web.

REGISTRATION:

Workshop + Debate: 6€
Please send an email explaining the reasons for your interest to cursos@cccb.org
Limited capacity!

Debate: 3€
Tel-entrada (tel. 902 101 212 / www.telentrada.com)
CCCB page for the event

I had to start with the complete and utter basics (as a recovering computer graphics guy) and to start with these games are split between a client and a server. The clients I’m interested in run in players browsers, and the server needs to be on a machine which is running all the time to provide the persistent world, and record the changes people make.

In terms of languages, when considering the client you are quite restricted as to what you can use. Every browser has a Javascript interpreter, and most people have flash – sidestepping the hot potato I’ve already written a bit about. Luckily for flash there is also haxe.

On the server it’s completely up to you what you use, as you can run pretty much anything in a webserver. I’m using a racket servlet so I can use Scheme.

Sending requests from the client to the server

In a game the client needs to issue requests to the server while the game is running, in order to get realtime feedback on what is going on. As far as a browser is concerned, it does this first to get the page, but as we also need a way to do this after the page has loaded. This technique is usually called AJAX, or “Asynchronous JavaScript and XML” and was a hot topic a few years ago due to the rise of Google maps and other websites that make heavy use of it. All it really means is that you can send a http request from a script running on a page, and get a result from the server. I’m skipping the XML part, but I think it’s the same idea.

In JavaScript you can do this with the popular jquery library, where a request looks something like this:

$.get("page.html", {argument1: 302, argument2: "hello"}, 
function(data) { do_something_with(data); } );

The page and arguments will result in a call to a url like this:

http://your-site.com/page.html?argument1=302&argument2=hello

When it’s returned, the result data will be passed to the function you pass in as the third argument. Notice that this function will be called “at some time in the future” – as it’s asynchronous. This means your script can do other things while it’s waiting for the data.

In Haxe you need to use a combination of things to do the same work:

// setup the loader
var Loader:URLLoader = new URLLoader();
Loader.addEventListener(Event.COMPLETE, CompleteHandler);
...
// define the callback for when the request has finished
function CompleteHandler(event:Event)
{
    DoSomethingWith(Loader.data);   
}
...
// set off the request
var request:URLRequest = new URLRequest("page.html?argument1=302&argument2=hello");
Loader.load(request);

Although I’m stuffing the parameters on the the url string myself, there is a URLVariables object which is supposed to do this cleanly – but I couldn’t get it to work.

Security issues

One thing you might notice is that we don’t specify the root of the url anywhere in the code, and this is for a very specific reason. The client code is restricted to only sending requests to the server which has served the page itself. This makes it hard to run a client from a location not controlled by the same people as the server – if this were possible, for example, a third party would be able to write a client that acted like the real one, but used your identity to do whatever it wanted. This is called the same origin policy.

A related issue crops up if it is possible for people to enter text which gets shown in the webpage of the game on other people’s computers. The problem here is that it may be possible for a third party to inject some code that gets executed into the website that gets sent to a player. This could result in all sorts of mayhem, for example inserting dialogs that look like they come from your website to extract personal information. This is called cross-site scripting (shortened to xss). There is no utterly foolproof way of preventing this, but a simple approach is to filter out special characters (such as angle brackets) from the input from your game as they come in to the server.

A third issue for security is to be careful of what you do with the requests you get – as while the users are protected from being tricked into running an altered client that looks like it comes from you, your server can still have requests sent to it from anyone.

For instance, it would be the easiest thing in the world to design an elegant and simple interface that directly ran code being sent to a server – eg a request such as:

http://mysite.com/myserver?func=display&param=hello

Could easily, even indirectly be run by some code like this:

(apply func (list param))

Which immediately opens your server up to people sending it calls such as

http://mysite.com/myserver?func=delete-file&param=server.scm

And presumably much worse.

So it’s important to use some indirection to verify that the commands you are being sent make sense, and come from a limited range of options controlled by you. Related to this, if you have command that create new objects somehow – it’s a good idea to have some limits imposed, to prevent some troublemaker writing a script that fills up the memory on your server.

Sending data from the server to the client

The data you send back as a result of requests can be of any form, but there are some useful standards here. I’ve chosen to use JSON which is another web programming four letter acronym that stands for JavaScript Object Notation. We saw a Javascript object earlier on, as part of the request being sent out, but they are just associative arrays. Here is another example that might come back from the server:

{
    player-id: 43,
    text: "destroy all humans",
    numbers: [3, 42, 32, 4, 1]
}

This can then be evaluated by the client and turned into an object that can be inspected by the game.

There is a risk from directly running eval on the text that comes from the server – as potentially this too could somehow be subverted to contain some executable data, although this is quite unlikely, it’s best to filter the text. Luckily there are lots of libraries to do this – I’ve used json2 before discovering that jquery has a getJSON call that does this for you.

After Dave’s early test to write a simple application that would dump all your data and some from your friends, I started to use the same technique but this time to do something with bits of this information. Namely, get some of your friends’ names and insert that into a partly predetermined chunk of text.

Even though this is all quite trivial, we think it’s a rather nice demonstration on how easy identity spoofing can be achieved by third-party applications. When you allow a Facebook application to have access to your profile, you let an unknown piece of code, written by who knows who, access to a lot of your data, and even though you are always warned about this, it is highly questionable that you actually realize what it implies. Similarly we have been agreeing for more than a decade to all kind of abusive software EULA without reading and understanding their consequences.

In terms of spoofing, based on the information pulled from your profile, it would be relatively easy to write a malicious chatterbot or come up with a design trick that could partly impersonate someone you know, pretend to be in your network of friends or a trustworthy known entity in order to pull more sensitive information from you.

More on that and the “Eliza effect” when we will start working on some bots for the game… Meanwhile you can check the simple pseudo spoof code here.