Even though there are others idea that have tried accomplishing the same goal as HipHop for PHP, I believe it is quite safe to assume that Facebook has a large enough user-base to produce code that is solid enough to run and can run well.

The announcement has been made on the Facebook blog earlier today, and tonight there is going to be the video tech talk that everybody can watch:

This evening we’re hosting a small group of developers to dive deeper into HipHop for PHP and will be streaming this tech talk live. Check back here around 7:30pm Pacific time if you’d like to watch.

A few questions come to mind even though we haven’t seen the code just yet. My main concern though is the one of buffer overflows and the security implications of turning PHP code into C++. As they say on the blog, it took nearly 18 months before having a relatively stable version and 3 developers. This is a very short lapse of time to develop a solution used by so many.

Another interest of mine related to this release is how does it compete with the likes of phc or roadsend php. If it does at all.

However I have noticed on their blog that Facebook has also developed HPHPi which seems to let you use HipHop but without having to actually compile your code before running it (The concept seems a bit like APC’s stat on and off switch from the few lines of description), which seems like a quite interesting idea for the development stages.

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.

Anyone who has ever worked with a client to build a web site or web application will know that there are areas where the client could benefit from having a better understanding of what is involved in the development process. Ultimately, when a client is better advised in these areas, they can make more informed decisions. This also can be beneficial to the development company or freelancer, as it can ensure better communication from the beginning of a project.

The Irish Internet Association is…

the professional body for those conducting business via the Internet from Ireland. The IIA provides leadership to enterprises and society conducting business in Ireland. The aim of the Association is to Connect, Inform and Promote.

I’m delighted to have been asked by the IIA to chair this working group. I’m looking forward to working with what I’m sure will be a talented team of professionals from development, security, and decision making backgrounds.

If you would like to be involved in the Web Development Working Group, you can drop Roseanne Smith of the IIA an email on members@iia.ie or you can contact me on eamon@echolibre.com .

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 ]

Ok this is a trivial remote code injection / theft and sensitive data access/loss attack, but what I wanted to say in this post is the speed of answer and resolution from the skitch team. After putting a nice little security audit/report and sending it to them, I got an answer from them about an hour later saying thanks for all this and they had fixed the problem. They even thanked me for telling them and said, I quote:

As a security precaution, we have also changed our “masterkey”
that is the basis of all session-id-generation and keys for
automated logins, as well as invalidated all existing sessions
to make sure no user already compromised by such an exploit
are compromised for future logins.

As we’re constantly fighting against XSS-attacks, being a site
driven by user content, humble humans still fail at times, and
we would love and welcome any future bugreports you might be
able to come up with revealing similiar problems in our code!

Fairplay to Skitch.com and it’s team. This is very responsive, open minded and nice at the same time. Well done