Keeping the Web Open

PUNE, INDIA: The web is the focal point for most development activity these days, causing it to become an amalgam of the most disparate set of clients, servers, and applications. Already there are so many different online communities being followed by developers, each having its own set of new technologies, SDKs, and concepts to work on. If the development continues at the same pace, then pretty soon, there will be chaos. There will be different islands of information, each requiring separate plug-ins and web browsers to enjoy full benefits.

One of the reasons behind this is that the web is no longer a static set of web pages created in HTML. In that era, even if there were minor incompatibility issues between different browsers, they wouldn't be so noticeable. People would still be able to access all the information, even if its presentation was a little distorted. Developers would still be able to develop, and would have to do minor adjustments to make their websites compatible across different web browsers.

Look at what's happening now. The web has become a place to interact, thanks to all the social media networking sites. Its presentation has become richer, with more compelling graphics, audio, and video sharing. So there's Silverlight from Microsoft, Adobe Flash and AIR, umpteen clients for Twitter, so many IMs, unified messaging clients, and finally the latest fad on the web--Cloud Computing, where practically everything happens 'in the cloud'. If this continues, then it will impact interoperability of different services on the web, and with so many online developer communities, security issues will cause further problems.



Keeping all this in mind, it's essential to have a re-look at all the standards, technologies, and coding practices that the web is built on, and identify the right way forward that would hold the web's sanctity, and keep it integrated, interoperable, and secure. One of the movements toward making this happen is called the Open Web. The philosophy behind this is to keep the web an open place, with development that follows standards, and the end users are the focal point for the same. Ultimately, its the users who're going to make the web grow bigger. So while the web should retain its de-centralized nature, it should allow innovation to happen on it freely, with everything well-documented and accessible to developers.

How should this happen?

I had the opportunity to moderate a panel discussion at Google's DevFest event, held in Pune recently, where around 300 developers had participated. The panelists comprised of experts from Google and two of its partners-OrangeScape and Impetus Technologies (See names of participants in the photograph). It was an interesting mix for a healthy discussion, because we had the providers of development tools on one side (Google), and the users of those and other tools on the other side (Impetus and OrangeScape). The discussion revolved around how to make the web more open, with a focus on HTML 5, responsible coding, and finally Cloud Computing.

The move to HTML 5

One step toward enabling an open web is to upgrade the fundamental base that the web has been built on-HTML. The current HTML standard is now reaching its limits and unable to handle the vast amount of development and rich media being put up on the web. That's why the next version to the same, HTML 5 has been taken up by the World Wide Web Consortium, or the W3C, for ratification.

The Google participants, Rajdeep and Patrick, gave examples of HTML 5 usage and how it can replace the need to use Flash plug-ins. “Virgin America has just announced that they're dropping Flash and using HTML 5”, was the response given by Patrick. The example given by Rajdeep was that of YouTube, which currently runs on Flash video. He said that there's a YouTube version that also runs on HTML 5. Rajdeep also extended this further by saying that HTML 5 can be used in their own product, Chrome to build extensions, which can be used for offline access, store user options, etc. He said, “The whole point is that we want to give users an experience where they have experience similar to desktop apps similar to browser, where you don't have Internet connectivity.”

Another example quoted by Rajdeep was of the GeoLocation API, which has been standardized across browsers that support HTML 5. It uses various features where the device has GPS, triangular location, etc for building interesting apps, like in a social web scenario you know the location of the user (with the user agreeing to be located on the web of course). So more power in the browser will in effect be good for end users.

“There's no need to install Flash to use it. Just use plain browser with HTML 5”, he said. He added that for a developer, this is important because you don't need all those expensive tools for development.

Use of HTML 5 at OrangeScape and Impetus

OrangeScape's Mani was of the view that from a browser compatibility standpoint, not all browsers use HTML 5. That's why, from a products company or any services company, it would be very difficult focus on one browser, especially when IE is a major browser that doesn't support HTML 5. The HTML 5 platform itself is a combination of multiple technologies, and Mani said that they use CSS 3 from it, which will automatically downgrade to the lower version if the browser doesn't support it.

Vineet of Impetus said that they were using and experimenting with HTML 5 to provide better user experience, with features that are not possible otherwise with today's tech like Java, Flash, etc. The other aspect he focused on was that once the HTML 5 spec gets standardized, there's a lot of potential for innovation, and to deliver great features.

Other benefits of the Open Web for developers

There's a lot more to the Open Web than HTML 5, and Patrick highlighted some of them. He mentioned the widely implemented Geo-Location API, followed by stuff like Websockets, Accelerometer API, which aren't yet standardized, but will become a part of the Open Web. He mentioned CSS3-which is all about presentation; the new stuff in JavaScript, with some really interesting features. Patrick finally quoted a Google project called CAHA, for JavaScript security. He mentioned that the project is aimed at rewriting your Javascript, so that it's sandboxed and only accessible for running in social networks.

The need for responsible coding

With so many companies offering free SDKs and tools to develop web apps, how do you tackle security issues? After all, these tools are free and anybody can use them. And with every developer community having hundreds of thousands of followers, security does become a concern. How does one ensure that there are no rogue applications? How do you ensure that the developer who's created the web app has followed the right coding practices or not? How do you know that the coder is not creating the web app with a malicious intent? Web security therefore, becomes another key concern when we talk of the open web. For instance, there can be security issues in developing extensions for Google Chrome. There's a way by which a developer can circumvent the Same Origin policy while coding for Chrome, and nullify cross-site scripting.

Patrick Chanezon of Google gave a very good metaphor for platform standardization, comparing application development to sea surfing. He said that when you're building a web-app, you're a surfer. You're on the wave, and there's all the sea that's pretty flat before the wave. It's that sea that ensures our apps stay float. That's the stuff that doesn't move. It's the same sea here, and a thousand KMs away. Today, this sea means TCP/IP, Intel machines, etc, which don't move too much. They've been standardized, and everyone takes them for granted. Then there are waves that start forming, and depending upon your application, you're at a different level on the wave. In HTML 5, you're in the beginning of the wave. HTML 5 receded from the edge of the wave where there's the foam, which is very noisy, you don't know what you need to support, etc. In the cloud computing platform, you're at the edge of the wave, so you need to know what you're doing because it may change very quickly. So, depending upon your risk acceptance layer, you surf in the foam or you stay a little bit behind.

Rajdeep of Google responded by saying that users can report abuse for all Chrome extensions that they download. So if a user gets the feeling that his personal information is either being used somewhere else, or being mashed up in a way he doesn't want it, then he can report it and the Chrome team can bring down the extension. Going beyond Chrome, Rajdeep referred to OAuth, an open protocol to allow secure API authorization. He said that if you're on one website and you want to access the info from another website, say to import some contacts from Gmail or Yahoo!. Then, one option would be for the app to ask for user's name and password, go and hit the endpoint and get the contact. This is an unsafe method. With OAuth, it only asks a user name, redirects to the homepage of that particular website, and there you enter your credentials and an OAuth token is sent back.

So there are standards coming around to make things safer. But there are always things or loopholes that can be hacked. It's the responsibility of the community that they're not abusing these services that are being provided.

OrangeScape and Impetus' take on Responsible Coding

On the aspect of responsible coding, Mani was of the view that the security measures you take depend upon the use case. At a high level, HTML 5, Flash, etc fall under Rich Internet Applications. Their characteristics allow developers to develop 3 kinds of apps-offline apps, where you don't have access to the network all the time; You deploy it on the client, and make sure the versions are synchronized every time the server comes up. Second is a conversation kind of application where the client takes care of the document model that's rendered in a browser, and the server takes care of incrementally updating the document model. The example here would be Google Wave, which incrementally updates part of the document. The third kind is a document oriented application, where the client has a rich state, meaning there is a model available on the client side, and the rich client takes care of modifying the client's date and sending it to the server.

Depending upon one of the use cases above, you may or may not have access to the local machine. Offline application need access to the local machine. There has to be some way by which the developer has access to different access privileges and you ask the user to explicitly state that, before you can start doing certain modifications. The ability for HTML 5 or across RIAs to make available these safe, protected and unsafe code need to be available for making a developers' life simpler. As developers, he added, we all love hacks, so the last thing we want is reduced features in the name of security. That's why the need for a use case that balances the security aspect.

Vineet from Impetus was of the opinion that as we grow with the open web technology, and its community also grows, the safety mechanisms will also come from the community itself. This is the era of social networking. The excitement that the open web brings is collaboration. We can as a community help define the open web. This is a very valid point, and there are already online communities and non-profit organizations like OWASP, or the Open Web Application Security Project, whose objective is to improve application security.

Standardization and Cloud Computing

Considering that everything seems to be moving into the cloud, it's only natural to wonder where the standards are going as far as various Cloud Computing platforms are concerned. For instance, Google already has around 100,000 apps on its AppEngine Cloud Computing platform, and likewise, other platforms have their own strong followings. This most certainly calls for standardization, so that developers can freely move their applications across different platforms, and the users are also safe from getting locked into the services of one particular Cloud services vendor.

On the issue of standardization, Patrick from Google said it was too early to comment on it because there isn't much standardization that has happened on it. Currently, there's a lot of innovation happening on the Cloud Computing platform from companies of all sizes.

Everyone's looking at the space from a different angle, due to which their offerings are also different. Apart from that, there's also a need to scale horizontally, which has to do with moving out from relational databases to no-SQL based databases. For instance, Facebook uses its own database, Twitter has adopted from Facebook, while Amazon has something called SimpleDB. So currently, everyone's in the innovation mode, and standardization will only happen over the next two years.

Rajdeep was of the opinion that everyone today has a vision toward cloud Computing, and unless that converges, it would be too early to talk about standardization at the Cloud Computing level. However, we can talk about cloud computing standardization at the tools level. For example all APIs Google supports, say in AppEngine. Even though the underlying datastore is non-relational, it's more like key-value pairs, but there is an abstraction layer, which is standardized. In AppEngine, if you're developing in Java, you don't need to know the low level APIs. You can develop using JDO or JPO. Of course it's not 100% supported, within the limitations of what can be done in Big Tables. “It was a conscious effort that we discourage people to access the low-level APIs, because application portability becomes an issue”, he said. That is why instead of coming up with our own server side stack, we used servlets, JSPs, because we wanted the J2EE spec incorporated in our stack as much as possible.

Mani of OrangeScape seemed very optimistic about standardization because the underlying concepts for the cloud computing and storage remain the same, just like how a database has evolved over a period of time. An RDBMS came up with an underlying concept for database storage, which is distributed storage and columnar database. You take any database, BigTable, Azure Table storage, they're all columnar databases, which is why we've abstracted out the layers, and built all the other layers and made the applications portable on all the platforms. Now, somebody has to come up with a standard, so it's only a matter of time till we get there.

Vineet of Impetus was of the view that while developing products, he would not want to be driven by maintaining three different versions because there are three different platforms that need to be supported, each with three versions of code. The porting efforts in that would be mind-boggling. According to Vineet, all of this would have to be driven by the quality of service offered by the Cloud Services provider.

An end user would expect a certain level of standardization so that he could take his application and deploy it on any platform, whether on JEE or some other platform. Vineet felt that toward this end at least, they're excited by the fact that at least JEE has given them access to the underlying APIs, but at the same time, he believes that there's still a lot of work left to be done.

The Author was hosted by Google in Pune.