Security flaws and public web betas

Following up on my previous post, events of the past week have shown a much more obvious reason for the missing security model in Google Base - it isn't secure even in its present state. Jim Ley first pointed out a cross-site scripting flaw last Wednesday: More Google security failures. CNET reported another error which allowed the sea of porn already uploaded to Google Base to bypass the Google SafeSearch filter (see Google fixes glitch that unleashed flood of porn). Apparently, both these issues were fixed quickly but I don't expect this to be the end of it and the publicity can only attract more hackers.

Jim Ley also made a very prescient post ten days before the Google Base launch ( Public betas risk all our data) in which he wrote:

There’s been a big increase in making all your website projects beta in public, however most companies seem to have decided this means they can avoid actually testing their product before they release it. It wouldn’t matter much if was Joe’s random web application, but it’s not these beta products share the same domains as existing heavily used sites. This means domains are trusted by users, but people are expecting something different, this means that both compromised site phishing attacks like I described when I demonstrated the Google flaw last year, and attacks on user data stored on the same domain become very easy for an attacker. I’m not a security consultant, I’ve no idea how to hack sites, I don’t go looking, but it’s trivial to find cross-site scripting (XSS) flaws in these beta’s, it’s almost too difficult to miss them, which is why I believe the public betas are getting so little testing that there are bound to me more.

There has undoubtedly been a big increase in public web betas, and also an increase in the duration of these betas (Gmail is still in beta almost 20 months after its launch). My first thought is that this must be a reaction to litigation risk, but looking at the Google Base terms of service I think they have this well covered! Nevertheless, flagging a service as beta should warn potential users of its weaknesses and help mitigate PR risk. If an unwitting user were to suffer because confidential data were exposed through using one of these beta services then public reaction is likely to say "it's a beta - you should have known what you were letting yourself in for".

I think this does raise a problem for the many Web 2.0 startups that should be emerging from their beta phases quite soon, unless they have deeper pockets than I imagine. Particularly in the web-based office space, once people start to pay for a service I expect they will want to use it to create content that is not public. I expect most of these companies will follow Google's Limitation of Liability clause:

YOU EXPRESSLY UNDERSTAND AND AGREE THAT GOOGLE SHALL NOT BE LIABLE TO YOU FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES.....RESULTING FROM.... (iii) UNAUTHORIZED ACCESS TO OR ALTERATION OF YOUR TRANSMISSIONS OR DATA

It remains to be seen whether concerns over security and consequent liability will hinder the development of these businesses and it probably won't until something really bad happens. However, it does reinforce my view that if you have developed a brilliant Ajax application which is attractive to businesses (rather than individuals) you will probably see a faster return if you offer an intranet deployable version as well as a hosted service version. Before its acquisition by Yahoo, Oddpost was pursuing both routes to market, although I have no idea if they had any success with the corporate deployable version. But this is a topic for another day.