There was also this question in the air whether it was actually possible to write a full-blown security testing framework with just browser technologies – something that browsers were really never meant to do for a range of reasons. We did succeed at the end and here are some of the things that made us take HTML5 on board and the things that we’ve learned during the process.
A Custom Language
If it wasn’t for the lack of support for Xulrunner and XUL, we would have never looked at HTML5 as a replacement. That is right. XUL is amazing framework but it is Mozilla-centric (almost like Java, Flash, Silverlight, ActiveX and other) and lacks any support because it was never meant to be used outside of Firefox. XUL was built all around the design principles behind separation of concerns. Internationalization files, styles, structure and code were all kept separately and overlays provided the most powerful way to extend things as you wish. I still believe that XUL and XPCOM is an awesome combination and perhaps the most powerful desktop programming framework ever made but it was never meant to be.
The Mozilla community was betting hugely on HTML5 as the next generation of programming platform and after having a look at some ongoing projects such as B2G (now Firefox OS), the Chromeless browser experiment, Firefox for Android (completely native) we started to realise that XUL might be soon deprecated and we had to think for the future. We decided to go with HTML5 which was a serious gamble. In fact, it was down crazy.
Going With HTML5
HTML5 happened to be a bit difficult initially. It does lacks any native look and feel but after going over this thought for a while, we realised that this is actually an advantage rather than a disadvantage. HTML5 lacks internationalisation support. It lacks the theming and overlaying features of XUL and initially it felt as being quite immature and dull. It lacks XBL. It is certainly not a XML language. When you are programming in HTML5 the only way is to build everything yourself and compose your application from the ground up in whichever way you desire.
It was difficult to envision how that will translate to our needs but we did it. The UI was built from scratch and all the application elements were encapsulated into a small framework. Can we extend the UI in the same way we used to do with XUL? Definitely not! However, it was simpler and less confusing. HTML5 rendering turned out to be quite fast and very robust for both Firefox and Chrome and for once we saw potential.
We had all the bits that we started with we developed our desktop software but the next big problem to tackle was really about how to deliver a web application security scanner as a modern web app. That was the difficult question. It was difficult because in order for the scanner to work you have to break out of the security model that the browser employes and that is not something browsers allow you to do. We were not lost because we already knew that worse come-to-worse, we will simply embed a browser rendering engine and write the rest of the code natively but we hoped to make our next generation product a first class citizen in both Firefox and Chrome.
Adding Our Own API
For sure, we couldn’t do it with the standard API provided by browsers so we decided to do what the B2G folks did with Firefox OS and add our own API that enables our applications to do what we wanted them to do while still remaining web apps by definition. These augmentations, as we like to call them, were delivered as extensions which provided a thin layer between the browser and Websecurify, our own code delivered as a web app. The mechanics behind the extensions are difficult to describe so I will skip this part. However, it is enough to say that our extensions turned out to be maintainable and provide the functionalities that we required from browsers to support in order for our in-browser web application security suite to work in the same way you would expect it to work as a desktop app.
Websecurify Httpview with full access to browser HTTP trafic provided by the Websecurify Firefox Extension.
The HTML5 app plus a browser extension turned out to be a good combo. The HTML5 app takes care of the delivery mechanism, which as you know, it is over the Web. It also simplified the updates because we no longer had to wait for months before we roll them out because we could do them on daily basis as we go (something that we still do today). The HTML5 app that we wrote also meant that we were future-proof and here to stay as a technology company being able to adopt, pioneer and innovate in previously unexplored field. On the other hand the browser extensions that we delivered provided this much needed support to go beyond what modern browsers are capable of without compromising the user experience or security. The result is tremendous.
Until this point you must be thinking why I am writing all these things. What is this guy’s agenda? When we started writing our XUL-based app we always wanted to contribute our framework back to Mozilla while keeping our scanning technology to ourselves. We felt it was a good compromise. Now when we no longer develop for Xulrunner due to all the reasons explained above, the only thing we can share is our experience and I believe there is a lot to learn from it. We are still trying to figure out the best way to make the old XUL framework public.
View full post on Mozilla Hacks – the Web developer blog
Industry’s first HTML5-mobile application development framework spurs switch to mobile web as the preferred development and deployment platform. (PRWeb November 15, 2010) Read the full story at http://www.prweb.com/releases/sencha/touch/prweb8004667.htm
View full post on web development – Yahoo! News Search Results