I have been studying and working with web standards (XHTML, RDF, ATOM, RSS) for well over 4 years now, something I am glad of,  because recently something struck me. Conventions are arising, for example DOAP, SKOS and others, that are built on top of the Resource Description Framework otherwise known as RDF, if they aren’t, they are usually built on something very similar or related.

In this blog post I am going to be using the FOAF standard as an example and base for my proposal. First of all, the Friend Of A Friend standard (FOAF) is a project aimed at creating machine readable pages that describe people. It covers all basis of human interactions and behaviours. From basic profile information - name, mailbox, title, homepage, img, depiction, surname, given name, family name, firstname - to more detailed information as such as web blog, based near, geekcode, publications, etc.  As you can see on their standard description page, it also covers the following personal aspects: Online Account / IM, Projects / Groups and Documents and Images.

For instance, if a web application was to describe me using FOAF it could look something like this:

1
2
3
4
5

<foaf:Person rdf:about="#davidc" xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <foaf:name>David Coallier</foaf:name>
  <foaf:homepage rdf:resource="http://echolibre.com" />
  <foaf:img rdf:resource="/images/david.jpg" />
</foaf:Person>

The Problem

Whilst such a standard is clearly easy for a computer to read and does seem a logical fit, it’s not the easiest for a developer to read. These days, web users are looking for performance, simplicity, ease of use, and so are the developers creating web applications. Considering that XML is heavy to parse using current technologies (Javascript mostly), it makes very little sense for developers to make web applications that are going to be slower due to parsing complex XML nodes. However, JSON (JavaScript Object Notation) is a lightweight data-interchange format made to carry data over networks with a very small footprint. It has seen massive adoption across the web and is used in widget apps, web apps and various other systems.

As I was talking at OSS Bar Camp, something struck me. Developers need a standard. Fact. We need standards for the same reason the industrial revolution had need of machine part standards: to reduce the amount of different solutions to learn in order to achieve the same goal by having everyone do what they do in a standard way. Some may see standards as a way to prevent innovation, I see them as a way to innovate. See “why are web standards important” by the W3C, a good read.

So, developers need standards. Great, now what currently exists? Development standards (IDE, Documentation, tools, design patterns, unit testing, etc.), Output standards (XHTML, CSS, etc), XML based standards (Namespaces, Schemas, XPath, XQuery, XSLT, DOM, XML Base, RDF(s), etc.), usual web architectural principles, and many more. One thing that is missing though is the standards that allow developers to easily and rapidly work with each other’s web application.

If “Web 2.0″ was characterised by the democratisation of content, we feel strongly that the next stage of web evolution, “Web 3.0″ for want of a better word, will be characterised by the democratisation of data and applications.

The Solution

A standard would make that democratisation a little easier. I’ve decided that I am going to be working on this over the next few months with the help of a few others as such as Ed Finkler from the CERIAS (Also the creator of Spaz and all round awesome guy).

So, today I’m putting forward the need for PJFS - The Practical JSON Format Standard. It will strive to make heavy XML based standards more developer friendly and lighter by creating new, fresh and adapted Practical JSON Formatted Standardized outputs.

For instance, the FOAF example I drew above, is a great example of the need for PJFS. Consider the following from a developers perspective:

1
2
3
4
5
6
7

{
    "Person": {
        "name":"David Coallier",
        "homepage":"http:\/\/echolibre.com",
        "img":"http:\/\/echolibre.com\/images\/david.jpg"
    }
}

It’s easy to read but also easy to parse. It’s fast and reliable. I am well aware of the implications of this post and I do not underestimate the complexity of existing standards. I think each one of them, as complex as they can be, are needed and are something we should all aim to use. However, computers are not completely independent ( just yet!) and the middlemen (developers and users) should not be forgotten.

The implications of JSON formatting standards mean that it’s adoption will make things easier for developers by reducing the amount of work they have to do, and remove the learning curve on new object structures for every web service the want to use.

The first task I will start working on is a PJFS for micro-blogging web services. The likes of identi.ca have already started in the general direction by “copying” the behaviours of the Twitter API, however many other micro-blogging platforms are still very independent and a unified standard could help the tools developers creating more flexible tools that would cover more networks.

So, remember where you heard about PJFS first It’s there to create standard object names, properties, variables, class members names to JSON elements so that developers can expect something identically formed when requesting JSON information from a webservice.

If you’d like to be involved leave a comment or catch me on twitter - @davidcoallier.

This past weekend we went along to Dublin’s OSS BarCamp. There were some really great talks, Stuart Langridge’s Javascript presentation was a highlight. Jaime Hemmett’s talk on using Git for version control was useful and informative. Paul Biggar’s talk on PHC, the Open Source PHP Compiler, was thought provoking and certainly caused a few grumbles from PHP guys like myself in the audience ;). JD and myself managed to catch up with him after and talk through some of his ideas over a drink.

I also got to give a talk on how APIs will be the cornerstone of the next stage in the evolution of the web - web 3.0 if you will.

This was my first time talking about a subject that didn’t directly involve PHP.  I’m planning on doing a similar talk at BarCamp Belfast at the end of the month, so if you were present and have suggestions on how my presentation could be improved feel free to leave a comment below.

Andrea Trasatti (@andreatrasatti) made the valid point that a small company and startup are not the same thing. Also I’ll have to add a list of successful startups towards the end of the presentation to support my central argument that APIs can extend a customer base and service subscriber network.

So, my slides from the presentation are below, please do let me know what you think. As a company, we were delighted to be able to sponsor the event, and it was great to be able to connect to speakers and attendees alike over a few drinks after the event.

Just a quick post to remind the Irish and Dublin web community that OSS Bar Camp is running this coming Saturday 28th March, in DIT Kevin Street.

As the name suggests, the focus of this Bar Camp will be on Open Source Software. There has been a lot of work put into this by both the organisers and speakers, and a packed schedule has been produced. There’s a good mix of talks covering topics such as Linux, Javascript, Drupal, Git, and of course PHP.

Personally, I’m looking forward to hearing Paul Biggar talk about phc, and Jan Schmidt about GStreamer. Needless to say David Coallier’s talk on API’s will be awsome

I’m also looking forward to meeting everyone. If you’re into  PHP, or passionate about web technologies in general, please find me and say hello!

So, make sure you register for this free event here. More details on the event, schedule and venue can be found on the OSS Bar Camp site.

Personally, I believe that this will be one of the features of web3.0*. The ability to have a single login, not having to log in anywhere and your profile will be recognized, etc. (OAuth, OpenID, etc). We could almost say browser-identifiable-security where one browser window (with as many tabs as you want) could be associated with a single account and all websites you visit would know about you and your information. The idea itself is very neat, but brings with it issues around user privacy.

Whilst this is a really cool concept from a developers point of view, I can easily see why anyone would be scared of the ability to retrieve your Twitter profile from within any webpages. I have found a few other services and web apps with public APIs that are also affected by that sort of bug –  if they consent to being named, I’ll do so here.

The type of vulnerability we’re talking about here is commonly known as a CSRF vulnerability . Twitter has some protection against this attack on the forms that are used to write to the profile settings, direct messages, etc. It’s rather trivial to protect from CSRF — some good methods out there include adding encrypted tokens as well as verifying cookies — but the fact that http://twitter.com/statuses/user_timeline.xml is accessible by anyone logged in to Twitter, it means that it will also be available to the websites they visit.

For instance, using jQuery,  a malicious website could run something as such as:

1
2
3
4
5
6

$(document).ready(function() {
$.getJSON("http://twitter.com/statuses/user_timeline.json, null, function(data) {
// Do something interesting with the user data you have just collected
// Maybe ajax request to your own server to insert the data?
});
});

Using this you could easily track anyone who comes to your website and also retrieve a list of their friends if you feel a bit more … creative.

Basically the process is as follows:

Twitter Attack Scheme Diagram

1. The user logs in Twitter
2. Twitter creates a cookie and logs the user in
3. The user (while still logged in to Twitter) visits a malicious website
4. The malicious website uses the weak-cookie and retrieves information about the user
5. The malicious website outputs the data as usual and says nothing to the user.

One of the main implications of this openness and lack of user communication is user privacy. Many people could potentially be exposed with their names/profiles available in the wild. This will affect their privacy in a way that websites they visit could become known to everyone (And do we know how bad this could be in terms of reputation… :P)

I can think of two possible solutions to this problem. First, ensure a stronger authentication system for retrieving any API methods and even reading user information — not allowing the main website cookie to be used with the API would be a start. It’s a bit radical, but it may be the only option. A second option might be that the user gets choice whether to make their profile cross session available or not.

I’m not sure what they’ll choose but today after a few rants and playing around, I realized that this issue will probably become mainstream with other apps in the months and years to come, but only if the user is informed and their privacy respected.

* Some ideas from this post will be in my talk on Web 3.0 at ossbarcamp

[Thanks to Turtle Kid and the awesome War Games ]

We’re proud to say that echolibre will be involved with OSS Bar Camp in March; we’re looking forward to talking about Open Source products and development tools we love, as well as giving an insight into how web companies can bring value to their existing products by embracing Open Source concepts and methodologies.

You can follow the latest updates from OSS Bar Camp on twitter, and we’ll be posting more about the event as the weeks progress.