Wednesday 10 June 2009

To Reader or Not? Can we Really Do Without It?

Yesterday being the 2nd Tuesday of the month, saw the usual slew of update notices from the regular culprits. However, a new actor came into play this month: Adobe! The first appearance of what has been nicknamed «Adobe Black Tuesday Updates». This actually represents Adobe's commitment to having a regular patching schedule to address security issues, bugs and whatever else needs to be fixed.

Adobe since late last year has been hard with a slew of vulnerabilities in their products but more so in their flagship Reader product. The root cause of the issue was the inclusion of JavaScript and related bugs in that provided a vector for exploit. The vulnerabilities have been covered to a great extent on the intrawebs and there isn't really much more to add. Adobe attempt to take a rational approach to the issue and sent out advisories on how to take palliative actions (by disabling JavaScript support in the product) until proper patching could be done.

The push that some security experts (including some prominent figures such as Mikko H. Hyppönen from F-Secure, Paul Asadoorian from Pauldotcom.com) to abandon or adopt alternate products and formats is just not realistic! The biggest criticism toAdobe has been why use JavaScript in what is essentially an electronic paper format. This attitude neglects the important factor that the technology is there for a reason. In most cases that reason is based on identified business/customer needs and those same customers have built solutions which need the scripting to continue to function effectively.

A number of business and government organizations have adopted the additional scripting capabilities to make the documents more interactive and to facilitate the content entry/usage for their users at a time when Web2.0 was far-away. A lot of interesting solutions have been explored and created using this dynamic document capability such as automated tax reporting forms, real-time report generation, ... There are and probably will be a continued need to support this type of scripting technology to give documents more interactivity and to breach the divide between static data and the ability to have near real-time solutions for reporting and information manipulation.

Could Adobe have handled this better? probably but they have embarked on a road to manage the risks more effectively! Could a solution other than JavaScript be used? from a technical point of view most likely but practically Java is a well-adopted programming language.

The underlying hard truth though is that calling for the dropping of one or another product is just not constructive and in most cases will go against the end-user's business goals! More constructiveness is needed to achieve solutions that help end-users minimize the risks but at the same time continue to allow them to streamline business process with the solutions at hand.

Related Links: