Challenges and Considerations Unique to
Web Application Development
Matt Szaro, George Mason University. Fall 2011.
Tuesday, November 29, 2011
1/7
With the advent of the Internet, the world of computing and computer science has undergone a
staggering number of paradigm shifts. Use patterns have been undeniably effected; humans interact with
online services daily for a multitude of purposes (perhaps most notably to seek information or
entertainment); businesses and governments increasingly rely on networks for communication and
cooperation; software vendors are increasingly realizing the potential of digital distribution as a practical
alternative to brick-and-mortar sales of physical media. For the computer scientist, perhaps the most
relevant paradigm shift is the radical alteration of the software development model. For decades, clientside software was, for most intents and purposes, the only form of software. The potential for post-release
software updates or feature additions was slim at best, and impossible at worst. Security concerns were
limited to managing access rights afforded to those with physical machine access. Localization needed
only be considered in cases where physical media was to be shipped to a foreign country. And a
developer could be certain that his or her software would be run on only one type (or class) of machine.
Today’s landscape is very different - the advent of web applications has voided the aforementioned
statements. Web applications face a more difficult development process than client-side software,
including a continuous-and-incremental release cycle, a slew of varying security considerations, and the
unique problem of mobile access and client fragmentation (Zepeda, Vaughan-Nichols).
Perhaps the most radical paradigm shift in the development model in the context of web
applications (or admittedly any application run in the cloud) is the unique opportunity for continuous
improvement. Traditionally, software development was done in an incremental fashion; after planning
and design phases, the implementation would occur. Assuming that testing could demonstrate that all was
well with the current implementation, it would be pressed to physical media and shipped. Theoretically,
all would be well. Realistically, any randomly-selected software engineer would likely agree that shipping
a bug-free product is so astronomically improbable that it is generally considered to be impossible. It is
not financially viable to press and ship new physical media at short intervals. Annual releases are not
unheard of, but in many cases, client-side software operates on a two-to-four year release cycle. From the
viewpoint of the user, this means that any software flaws would not be corrected until the next release,
Tuesday, November 29, 2011
2/7
years down the pipeline; from the viewpoint of the developer, this means that any new features or
software improvements would not be accessible to the end user until the next major revision shipped,
once again years down the line. Of course, the advent of the Internet has enabled digitally-distributed
patches; nonetheless, there is much overhead involved with distributing a post-release patch to customers,
and even more overhead in convincing said customers to apply said patch (Zepeda).
The web application has a much different development-and-distribution model. Indeed, the very
nature of remotely-served content ensures that content pulled down by the browser (or any network client,
really) is the latest revision on hand. The developer can be certain that as soon as their code is pushed to
the production server environment, it is available for use (and quite likely in use) by the entire user-base
within minutes (Meier). Because the cost (both financial and temporal) of pushing code to a server is
negligible, there is no major hold to prevent developers from pushing new code very frequently. This state
of affairs leaves the web developer at a unique advantage compared to his client-side counterpart: he is
free to make code changes, both to fix software flaws as well as to roll out new features and
developments, at any time he chooses - all without an associated distribution overhead, and all without
concerns of which software version clients are using.(Meier). This unique benefit has led many web
application developers to adopt a radically different development cycle - one of frequent, incremental
development. The web developer is able (and in many circumstances, encouraged) to roll out minor
changes at very frequent intervals, rather than major revisions at large intervals. Perhaps the greatest
example of this is Google, whose seemingly daily tweaks to their products and services have led over the
long term to a constantly-evolving, constantly-better portfolio which in many ways outpaces anything its
more traditionally-minded rivals can match (Reynolds). (Microsoft, for instance, adopts a traditional
model with its web products; Windows Live Mail receives an interface lift and major new featureset
annually or so, whereas Google’s Gmail receives minor UI changes and a single new feature or two
weekly, and sometimes sooner.) This gradual-yet-constant evolution also has the advantage of a greatly
diminished learning curve: figuring out where a single button is repositioned, or how to use a single new
feature, on a weekly basis is far less intimidating to the less tech-savvy userbase than is a complete
Tuesday, November 29, 2011
3/7
interface redesign. While advantageous in the fact that such applications are more easily updated, these
more frequent roll-outs face far less software testing, leading to a much more difficult time maintaining a
secure environment.
Web applications face unique security concerns as compared to client-side applications. In
general, client-side software is mainly concerned with security on the local machine. Operating systems
deal with managing access for those with physical access. Office suites deal with avoiding exploits and
security issues when reading in files. Most client-side security concerns are of a local nature, and deal
primarily with how the user interacts with the software, as well as how the software interacts with other
local resources (be it files, other software packages, or whatever else). On the web, the game is
completely different. A web application by its very nature is exposed to the entire Internet; effectively, to
the entire planet. While a local install of MS Word may be targeted by malicious .doc files, a website is
open to attack from anyone in the world with an outbound connection. Web applications accept orders of
magnitude more input from users and other applications than do discrete installs of client-side
applications (Nyrhynen). Unfortunately, any opportunity for user input is an opportunity to exploit
security flaws, and this is no different on the web. There are steps that can be taken to minimize risk of
some of the more common attacks. In cases where the web application interacts with a database based on
user input (this is most applications), good developers will take steps to filter out SQL queries, PHP code,
HTML tags, etc (Meier); trivial cases of SQL injections and malicious JavaScript can be filtered out with
a good parser, or in many cases a simple application of regular expressions (Fonseca). However, skilled
exploiters will easily find their away around such minimal protection. Web application security concerns
arise all the way down the software stack; even if a website runs well-formed PHP and JavaScript code,
due to the exposed nature of the system, an available exploit in PHP itself, or anywhere down the stack Apache, OpenSSL, or any number of Linux/BSD packages involved in content generation - could mean a
breach of data integrity (Fonseca). This is especially of note in web applications; a failure of data integrity
on a local system may mean the compromise of one user’s password, or one system’s documents; a data
breach on a large-scale web application can compromise the data of hundreds of millions. Such a failure
Tuesday, November 29, 2011
4/7
is not possible with client-side software - several classes of security issues are not applicable when
running locally. However, the hugely destructive result means that extra levels of security precaution are
necessary, again adding to the difficulty of web development.
Client fragmentation is another concern much more applicable to web applications. Historically, a
client-side software package is run under only one environment. Excluding cross-platform “runtimes” like
Java from the mix, a software package would run on one and only one class of machine. A Windows
package, for example, will not run on a SPARC processor, or a BSD environment on x86. Thus, the
developer is free to make assumptions which simplify user interface design. A Linux programmer, for
instance, can safely assume most users will be using the device with a keyboard-and-mouse; that most
users will be running an X11 graphical environment; and that most users will have a display resolution of
1024x768 or greater. Web developers have no such freedom. Browser fragmentation alone makes frontend implementation difficult - jQuery, for instance, has huge blocks of code specific to the Trident
engine, huge blocks of code specific to the Gecko engine, and yet more targeted to WebKit, Presto, and
several others (Zepeda). In recent years, however, a much bigger challenge has come to light - device
fragmentation. While the plurality of PC-compatible hardware (and its device drivers) is a consideration
for some client-side software engineers, the majority of them do not encounter such problems, as they
work on much higher-level products, which rely on device-independent OS abstractions. Web developers
can never be sure what type of device the visitor is using. A full-screen AJAX interface may work
brilliantly on a desktop computer, but how will the click-and-drag interactions react to a touchscreen
tablet? Designing layouts and organizing content also proves a major challenge for those writing browserbased applications. Smartphones and their sometimes sub-480-by-320 displays can render an otherwise
perfect interface completely unusable and/or unreadable (Reynolds). Developers are beginning to flock to
the idea of multiple, device-specific interfaces - often developing one for a full-screen Desktop browser
and another for a mobile device view. In many cases, designers are beginning to roll out yet another
discrete mobile interface for tablet devices (Nyrhynen). Others question the usability or value of such
mobile interfaces, and opt for native, mobile applications instead. In all, the variation between browsers
Tuesday, November 29, 2011
5/7
and devices can be overwhelming, especially in combination. Developing a browser-based interface that
will run on everything from Safari on iPad to Mozilla on Solaris can be a staggering task; one which a
developer writing Microsoft Word for Windows does not have to face at anywhere near the same level.
Yet for any software-as-a-service or software-in-the-cloud model to succeed, reconciling this
fragmentation is a necessity. One simply cannot afford to alienate all users of a particular class of device,
or particular browser rendering engine. One platform is not enough; web application developers must
target for hundreds of combinations of platform and browser, or even screen size and device. This makes
UI design a much greater challenge on the web.
Web applications face a variety of different development challenges, considerations and design
ideas as compared to their client-side counterparts, and ultimately, a more difficult development cycle.
They face significant advantages in deployment and distribution, due to their capability of being instantly
updated, with all clients always using the latest version of the software; the ability of developers to
constantly improve their platforms has finally given software engineers access to the more natural
engineering model of constant evolution. However, this model introduces problems with software testing,
and introduces security flaws. A different class of security threats affects web applications as compared to
locally-run applications - a class that I would argue is both more varied and more dangerous - and security
flaws which are present in other areas of the software stack (for example, in the HTTP server itself, the
SSL implementation, or what have you) can potentially cause huge damage or allow data breaches
affecting millions of users. Fragmentation across both devices and browsers leaves web developers with
the unique and difficult challenge of designing a user interface which will be truly accessible on any
Internet-enabled device. These challenges are unique to the web, and
together create a much more difficult and security-oriented development process for the web developer.
Works Cited
Fonseca, J., M. Vieira, and H. Madiera. "Vulnerability & Attack Injection for Web Applications."
Dependable Systems & Networks, 2009. DSN '09. IEEE/IFIP International Conference on, 2009,
93-102. doi:10.1109/DSN.2009.5270349.
Tuesday, November 29, 2011
6/7
Meier, J.D. "Web Application Security Engineering." IEEE Security & Privacy Magazine 4, no. 4
(August 2006): 16-24. doi:10.1109/MSP.2006.109.
Nyrhinen, F., and T. Mikkonen. "Web Browser as a Uniform Application Platform: How Far Are
We?" Software Engineering and Advanced Applications, 2009. SEAA '09. 35th Euromicro
Conference on, August 2009. doi:10.1109/SEAA.2009.37.
Reynolds, Franklin. "Web 2.0 - In Your Hand." IEEE Pervasive Computing 8, no. 1 (January
2009): 86-88. doi:10.1109/MPRV.2009.22.
Vaughan-Nichols, Steven J. "The Mobile Web Comes of Age." IEEE Computer Society 41, no.
11 (November 2008): 15-17. doi:10.1109/MC.2008.471.
Zepeda, J. S., and S. V. Chapa. "From Desktop Applications Towards Ajax Web Applications."
Electrical and Electronics Engineering, 2007. ICEEE 2007. 4th International Conference on,
September 2007. doi:10.1109/ICEEE.2007.4345005.
Tuesday, November 29, 2011
7/7