Month: septiembre 2007

Is The Web Ready For HTML 5?

Fuente: internetnews.com April 16, 2007

If Mozilla, Opera and Apple’s Safari browser have their way, the HTML specification (define) could be getting its first major point update in a decade.

The three vendors have banded together in a proposal to the W3C for the HTML 5 specification, which includes Web Apps 1.0 and Web Forms 2.0 specifications and that it’s also backwards compatible with HTML 4.

“HTML5 is about preserving the information people have accumulated over the years,” Opera spokesperson Anne van Kesteren told internetnews.com. “By remaining backward and forwards compatible, we hope to ensure that people will be able to interpret HTML for decades if not centuries to come.”

HTML is the foundation markup language on which the Web was and is built and was originally created by Tim Berners-Lee. The last major upgrade to HTML was in 1997 with the release of version 4.0. The HTML 4.0.1 recommendation was published in 1999.

The W3C, the standard body responsible for HTML, has been focused for the most part with working on the XHTML (define) specification with version one issued as a formal specification in 2000. XHTML 2.0 is now a working draft; XHTML is a hybrid of both XML (define) and HTML for Web markup.

According to Charles McCathieNevile, Chief Standards Officer at Opera, the W3C has effectively abandoned any effort to develop the HTML that has been used on the Web since HTML 4.01.

“That specification is still poorly implemented, in part because it is not very clear in a lot of cases how to implement it,” McCathieNevile told internetnews.com. “We along with Apple and Mozilla felt that it was important to do something about this.”

It is unclear whether Microsoft will support the HTML 5 effort with its Internet Explorer browser.The company did not respond to requests for comment.

If adopted, HTML 5 promises some tangible benefits for both Web users and developers.

“HTML 5 will enable better cross-browser compatibility and better support for “Web 2.0″-style Web applications in addition to documents,” Brendan Eich, CTO for Mozilla, told internetnews.com. “HTML 5 also allows for better support for multimedia.”

The Web Apps 1.0 specification, which would form a core part of the HTML 5 standard, is intended to provide features that make it easier to author Web-based applications.

Some of those additions include context menus, a direct-mode graphics canvas, in-line popup windows, and server-sent events.

The other core new element is from the Web Forms 2.0 specification, which extends the way that forms are defined. The proposed specification includes new attributes, DOM (define) interfaces and events for validation and dependency tracking as well as XML form submission and initialization. The specification also aims to document existing practices in the forms area that have not yet been officially standardized.

The Web Forms 2.0 specification has been in play since at least 2004. That’s when Ian Hickson, then a developer at Opera, first helped to author the effort. Hickson now works for Google.

In their proposal to the W3C, Apple, Mozilla and Opera ask that Hickson be named as editor for the W3C’s HTML 5 specification as a means to preserve continuity with the work that he’s already done.

Continuity and standards are key to the message of why HTML 5 is important and why the three partners want to see it adopted as a formal W3C standard. “Having more Web applications based on open standards gives users more choice between Web browsers and between operating systems,” Eich said.

Though HTML 5 is not yet a formal standard, HTML 5 technologies are already in both the Opera and Mozilla Firefox Web browsers.

Mozilla’s Eich noted that Firefox 2 already provides support for client-side storage and has supported the “CANVAS” tag element since Firefox 1.5. Going forward, Mozilla is adding offline Web application support for Firefox 3.

Opera’s McCathieNevile noted that Web Forms 2, an enhancement to the original HTML forms, are implemented in Opera, and are in use, for example, at my.Opera.com. The canvas element and API, which enables graphics to be rendered more quickly, is already implemented in Opera and can be seen in a large number of opera widgets such asArtist’s Sketchbook (http://widgets.opera.com/widget/4647) and Circular Tetris (http://widgets.opera.com/widget/4196).

By working on the HTML 5 standard and implementing some of the items in it, the Web could well end up with an HTML standard that is actually effective.

“Active involvement helps us clarify implementation questions and ensure that the standards are implementable,” McCathieNevile said. “If HTML 4 had gone through a “Candidate Recommendation” where it had to be implemented completely before it was published as a final version, it might be a much clearer and better specification.”

10 Ways for a Web Worker to Achieve Work-Life Balance

Fuente: Web Worker Daily September 2007

One of the problems with being a web worker is that the lines between work and life have been so blurred as to be non-existent. The Internet is always on, accessible from just about anywhere, and our work and play are often both in the same browser.

As a result, we lose touch with the rest of life, and work takes over our lives.

While we’ve talked before about getting work under control, today we’ll look at 10 more ways to achieve that work-life balance.

1. Don’t always be connected. If you’ve got a Blackberry, a laptop or some other mobile device, you can’t ever get away from work. When you’re out of your office (or your home office), allow yourself to be disconnected. You don’t need to get email all the time, the instant it arrives. It can wait a few hours. When you’re away from your computer, you should allow yourself to live. Let this be your most firm boundary. Even better, unplug your Internet connection when a) you want to get some real work done or b) you are done working for the day.

2. Limit work. You need to set working hours. You can’t be working around the clock, from early morning hours to late at night, or you’ll have no life away from work. So set your hours — when you start and end, when you take lunch, even schedule other breaks. And set your limits to less than you work now. Sure, that’ll mean you’ll have less time to do your work, but that’ll force you to focus on the important tasks and eliminate the less important ones.

3. Make life a priority. What do you want to do besides work? And don’t say Twitter or Digg or YouTube. Something outside of the Internet. Exercise, reading, writing, spending time with family and friends, hobbies, sports, gardening. Whatever it is that you love to do, make it a priority. Schedule time to do it. Don’t allow work to push these priorities back.

4. Batch tasks. You have a dozen small tasks that you do throughout the day. Batch them together, like with like, and do them all at once. Email is a good example. Instead of doing email all day, have specific times when you process and respond to email. Same thing with IM: don’t be available all the time, but only once a day (for example). Same thing with phone calls, and other small tasks you do every day. It’ll save you time and stop your important tasks from being constantly interrupted.

5. Define what you want to do today. Web work is never finished. You could do 100 tasks today, and not be done. You won’t do 100 tasks. You might not even do 10. So no matter how much you do, you won’t be done. Instead of putting yourself on that never-ending treadmill, define a limited number of important things you really want to accomplish today. And focus on those.

6. Limit meetings & communication. Meetings, phone calls, IMs all waste your productive time. Which means that you have to work longer to get as much done. Instead, try to get out of every meeting possible. Most meetings can be accomplished through email. And ask people to email instead of call. Then limit email to twice a day (or once, if you’re brave). Or at most, once an hour, if you need to be connected that often.

7. Do the hard stuff first. Reward yourself after a good day’s work by putting the fun and easy tasks at the end. Start your day with the tasks you know you’ll want to put off, and get them out of the way. That way, you have good stuff at the end of the day, and the hard stuff doesn’t weigh you down all day.

8. Slow down. It may seem weird to read “slow down” as a tip when you want to get your work done so you can do stuff outside of work. But in truth, trying to cram a lot of work into a small amount of time is too stressful. I advocate doing less, but focusing on the important stuff … and doing it slower. Pay attention, enjoy yourself, relax a little. This applies to when you’re not doing work … eating, driving, doing fun stuff, showering. Slow down and pay attention, and life won’t seem a huge rush of tasks, but will become more enjoyable.

9. Block schedule. Schedule your day in blocks, so that it’s compartmentalized and there’s time for everything. A block for the important tasks (Item #5), for the smaller tasks (Item #4), for routine tasks or errands or chores, and for the non-work stuff you really want to do (Item #3).

10. Be firm. Whether it’s with a boss or co-workers or clients, you need to have clear boundaries of your time, and be firm with those boundaries. Don’t be afraid to say no. Make your boundaries clear, and don’t allow them to be violated. This may mean telling people that you’re changing how you do email, or your hours, so that they know what to expect. You may get negative reactions. But be firm, and stick to your guns.

Usability Testing for the Web

Fuente: ACM queue July/August 2007

Today’s sophisticated Web applications make tracking and listening to users more important than ever.
Today’s Internet user has more choices than ever before, with many competing sites offering similar services. This proliferation of options provides ample opportunity for users to explore different sites and find out which one best suits their needs for any particular service. Users are further served by the latest generation of Web technologies and services, commonly dubbed Web 2.0, which enables a better, more personalized user experience and encourages user-generated content.

Although there is considerable debate over the definition of Web 2.0 (and much criticism of it being merely a marketing buzzword), the term is useful in distinguishing key innovations, such as weblogs, social bookmarking, tagging, wikis, RSS feeds, Ajax, Web APIs, and online Web services, that have significantly altered the Web user experience since the 1990s.

As the Web matures and evolves, users increasingly view it as a platform for applications, and they demand a much greater degree of personalization and control. As such, it’s important for Web developers to discover and closely track certain user feedback, such as their motives for coming to a particular site, areas of the site they find difficult and/or confusing, and the features they like the most. Retaining existing users, encouraging them to spend more time on the site, and bringing in new users have become greater challenges than ever. Usability testing is a way of addressing these challenges.

When the Internet was in its nascent phase, it was viewed as merely one of many sources for getting information. As PC and Internet use has increased across the globe, users have become more savvy and know more precisely what kind of information they are looking for on the Web and how they would like to receive it. This has made usability testing an essential part of the testing cycle. Unfortunately, its importance is often overlooked, to the detriment of any particular Web application. We need to change our mind-set and adopt usability testing as a part of the everyday testing cycle.

This article looks at the challenges of usability testing, particularly within the context of the current wave of Web 2.0 technologies. It does not necessarily present solutions, but instead highlights most of the challenges, issues, and difficulties you might face in your own projects.

Objectives of Usability Testing
Usability can be defined as the degree to which a given piece of software assists the person sitting at the keyboard in accomplishing a task, as opposed to becoming an impediment. Usable systems are most often assessed according to these three criteria:

Ease of learning and learning retention
Speed of task completion
Error rate and subjective user satisfaction/quality of service
There are a few basic principles to consider, based on these criteria:

First and foremost, make your application easy to use. This will reduce user churn, prevent calls from frustrated customers, and help keep people on your site. But what is the benchmark that says that a Web application can be easily used by anyone who visits your site? This is a tricky question, because what’s easy for some people might be difficult for others (just as integration in mathematics is simple for some people and a sleep killer for others). So the question is, how can you know if your Web application is simple to understand or if users have to go through the help pages to find out exactly how things work? One simple technique is to give your application to the QA team to test without permitting them to read the functional spec or product requirement document. You needn’t remove the help pages entirely, but users shouldn’t be forced to consult the help pages often; and on each subsequent visit to a site they should be able to remember whatever they learned during their first time using the application. If they have to refer to help pages each time they visit your application, then there is something truly wrong and you need to take corrective action.

Also, many sites expose their APIs to developers, who then add this functionality to existing applications. Do users feel comfortable using these new features? A good site will make users feel comfortable learning new features and inspired to explore the site further.

Make your application fast. Fast is a relative term; you should always make sure that the speed of your application is on par with that of your competitors. To increase the responsiveness of services, many sites now use Ajax technology, which makes Web applications behave more like desktop applications. This is an intermediate solution between the slower response times provided by Web servers and the normally faster response times of desktop applications.

Another technique to increase responsiveness is to overlap or clump together operations without making things look too messy. Find out different permutations and combinations of performing an operation in your application, then analyze which repetitive tasks could be overlapped or achieved in a single step (aka, refactoring). One way of doing this is to use Web server logs to find out which pages users visit most and which pages they find difficult to use. For example, suppose you have an e-commerce site that leads users through a six-step (page) process. If the Web server log shows that many users are leaving the site during page four, chances are that page has a problem. Perhaps the user is finding it tedious to input so much information, or perhaps the server process itself is failing. Mining the Web server logs is a good technique to track user behavior closely, but it’s a tedious, time-consuming task. Later in the article I discuss multivariable testing, which can help resolve this issue.

Listen to your users. Many times I have reported issues to sites and failed to receive any acknowledgment. If you want these loyal customers to keep giving valuable feedback, you should immediately prioritize the issue and get it resolved in a timely manner. Allowing users to send feedback easily and making them feel that you are listening to them is very important.

You can also provide a very Web 2.0 user-feedback feature on your site, where users can comment on the site’s features and discuss them with others. This is very good way to find your users’ pulses and discover what you are doing, both right and wrong.

How to achieve better usability
The best way to get usability feedback is to test the application with a QA group that knows nothing about it. Once testers have gone through the product requirements document, the functional spec, and at last, the testing spec, they will be testing the application with a specific mind-set influenced by their prior exposure to it. It is difficult for them to break this mind-set and test while “thinking outside the box.”

In one of my own projects, we had a dedicated QA team testing a product for nearly three months. In between this testing cycle we asked another QA team to jump in and do the ad hoc testing; this helped unearth many usability issues. An engineer who is totally unaware of an application can test it as an end user and may come up with valuable insights and observations.

Checking the usability of a piece of functionality is as important as testing that piece of functionality itself. You need to discover what challenges and difficulties users may encounter with your application and how you can handle those in advance. Make notes of such points and discuss them during periodic team meetings; if a point is valid it should be communicated to the project manager. Then the manager and the QA team can discuss these concerns and resolve the problem. The accompanying sidebar outlines some basic techniques for unearthing many of these usability problems.

Tracking user behavior
In the past, most sites acted strictly as information providers, and developers hardly bothered to track users. Now, with more and more users treating the Web as a platform, it’s imperative that developers pay more attention to how they use certain sites and what their preferences are, and respond to that information accordingly.

One of the techniques used to track user behavior is called multivariable testing. Generally speaking, this is a series of tests, each representing an area on a Web page where content can be rotated through. Multivariable testing allows you to track user behavior at runtime and to make changes and then check how they’re working immediately. Many vendors make products to assist in multivariable testing, but there is still the challenge of fulfilling user needs based on their geographic locations, user behavioral patterns, and so on. For example, the needs of users in the United States are different from those of users in Korea. If you are trying to reach a global audience, you need to take this into consideration.

Tracking users with cookies is a tricky proposition; most users will feel like somebody is spying on them. Using Web 2.0 technologies, we might one day be able to track user behavior without users’ knowledge and without putting cookies on their machines. This would be similar to vehicular movement studies on highways for proper traffic management. In these studies, cameras are placed at regular intervals to monitor traffic density at particular times of the day, which types of vehicles are moving by that road, and other variables. If we come up with similar technology that can monitor people’s behavior on a particular Web site, we can find out where people are coming from, their browsing patterns, etc.

Unless we conduct a survey, however, finding out the age group, sex, nationality, etc. of users will be the main challenge. Even a survey will not guarantee that users will provide accurate data, but we can make educated guesses about them. For example, if a user is spending a lot of time on education sites that discuss engineering degrees, we might guess that this user falls into the 20-35 age group.

What’s Next?
M-Web 2.0 is my concept of the Web a couple of years down the line. The user base of mobile and handheld devices is increasing much faster than anyone can imagine. As cities are developing wireless networks and new software and features are being added to mobile devices, I can imagine 95 percent of the population using WAP-enabled mobile devices in the next few years. The limitation with PCs and laptops is that they are bulky and the user has to log in to connect to the Web. Keeping this future trend in mind should ensure mobile browser support for many Web applications.

Are we ready to adopt this change? How are we going to shift billions of Web sites to mobile browsers without losing usability? This is the next big challenge that lies ahead of us.

Usability Testing Guidelines and Standards
1. Create a feature usability matrix.

List all the functions in your application and ask people outside your team to test all of them. Testers should note their observations for each function and rate them according to their ease of use and practical utility.

Using this data, prepare a feature usability matrix, which describes the application’s functionality, how easy it is to understand, and whether users require external help with any particular feature. This matrix will help you discover which functionality performs well and which needs rework, and it will help you to continuously improve the site’s usability.

2. Create a comparison usability matrix.

Look at the features list for your site. Check how these features are implemented in competing Web sites. Record points of comparison, such as ease of use, look-and-feel, responsiveness, etc.
With these observations, prepare a comparison usability matrix and have this reviewed by your QA team. Whichever features get a lower rating against your competitors should be corrected. This matrix will ensure that your services are on par with your competitors.

3. Create a customer feedback usability matrix.

The automobile industry is attentive to customer feedback and tries to implement common change requests in their new models. Toyota’s success owes a lot to its customer feedback processes. The same best practices apply to Web applications. Can customers provide feedback easily on your site? Can they easily find existing issues discovered by others? What process is in place to take action on this feedback?

Providing a rating/review feature such as Digg.com on your site will help improve the product and build strong customer relationships. You can then use this data to create a customer feedback usability matrix to track how responsive you are to customer feedback.

Additonal resources
Usability Testing of World Wide Web Sites; http://stats.bls.gov/ore/htm_papers/st960150.htm.

Internet World Stats: Usage and Population Statistics; http://www.internetworldstats.com/stats.htm.

VIKRAM V. INGLESHWAR is a QA engineer for Yahoo! in Bangalore, India. He has spent more than four years in the IT industry, testing PDA and telecom software and Web-based applications. He holds a bachelor of engineering degree and has completed a Diploma in Advanced Computing course. His areas of interest are automation and white-box testing.

Building Secure Web Applications

Fuente: ACM queue July/August 2007

Believe it or not, it’s not a lost cause.
In these days of phishing and near-daily announcements of identity theft via large-scale data losses, it seems almost ridiculous to talk about securing the Web. At this point most people seem ready to throw up their hands at the idea or to lock down one small component that they can control in order to keep the perceived chaos at bay.

Before going any further, let me first define the three main problems that people are trying to solve by building secure Web applications:

The first problem most people encounter is authentication. How does the application know who is accessing it and what they are allowed to access?
Problem two is the ability of an attacker to trick users, once they have authenticated, into doing work on the attacker’s behalf. I call this problem request forgery.
The last problem is the risk involved in hosting UGC (user-generated content) on a Web site.
In this article I discuss each of these problems, the current state of existing solutions, and the unsolved problems that continue to plague large Web applications.

The Browser Security Model
The Web is, by its nature, a difficult system to secure. To provide a unified user experience with adequate performance, most large Web applications are distributed, and the requests and replies used to get work done in any system attempt, as much as possible, to be stateless. Because each request attempts to be stateless, the server itself must maintain all the state governing a user’s actions. Unlike an application, but like remote login, no single, long-lived session is maintained between the client – aka the user’s browser – and the server. To make a flow of Web pages seem more like a Web session, there are several tricks to maintaining and communicating state on each request between the browser and the server. Authentication is a good example.

To authenticate themselves to a Web application, users must prove they are who they claim to be. Most applications have username and password schemes where each user is assigned a unique username and then selects a password that is known only to that user. Once the user has successfully given the username and password to the application, the user moves to a logged-in state. These concepts are familiar to anyone who has used a computer in the past 50 years. They come directly from the multi-user time-sharing systems of the 1960s.

The problem is, whereas with a time-sharing system users had some sort of unique mapping between them and a communications device such as a terminal or long-lived network connection, with the Web that is not the case. The user could, for example, be using a service on mail.foo.com and then decide to click on the calendar and access calendar.foo.com, which is likely to be a completely different set of servers and may even be in a different physical location from the mail servers. They are still related services provided by foo.com, however, and the switch between them should appear seamless to the user.

The way in which large Web applications maintain authentication state is to depend on cookies, which are set by servers and stored in the browser, and to depend on the browser to implement what is now called the browser security model, though it ought to be called the cookie security model. This model is a contract between the servers and the browser, stating that the browser will send cookies only to a server in a domain that set them in the first place. The domain is defined by the DNS name assigned to the servers. In the previous example, foo.com is the domain name under which the cookies are set.

As in any protocol implemented independently by several parties, different implementations have different bugs. This means that the security model as implemented by Mozilla in Firefox is likely slightly different from the one implemented by Microsoft in Internet Explorer, and those are different from the one implemented in Opera, and so on. The security model is actually the union of all the available implementations. Protecting your system from only the browser with the biggest market share always leads to trouble.

A concrete example will aid in understanding the security model. On every request the user’s Web browser sends the set of cookies that it believes belongs to the domain that the user is working with. If the user is working with the domain mybank.com, then the browser will send the cookies that have been set in the mybank.com domain. If the user moves to another domain – for example, freemail.com – then the browser sends only the cookies that are set by freemail.com servers. Changing any part of the domain changes the set of cookies that the browser is willing to send. Thus, freemail.com and freemail.net are not equivalent; they are distinct domains.

Cookies
In a Web application the user’s cookies act as an authentication token to use the system. I do not wish to address the problem of correctly implementing cookies as login tokens here. Suffice it to say that cookies need to be cryptographically signed to make sure that they aren’t tampered with and have to be issued only after a valid password or other piece of information is verified by the servers. The two problems with cookies that I address here are: How much scope should they have, and for how long should they be valid?

The scope of a cookie refers to how many services it can access. From the user’s perspective, a company’s whole Web site represents a single application. If, for example, a company provides e-mail, calendars, blogs, and product reviews, the users would like to log in once and then be able to access all those systems equally. Having to type a password for each subsystem, such as mail, calendar, blogs, and reviews, is considered a poor user experience and would not be tolerated.

There are other risks with having too tightly defined cookies and requiring users to type their passwords more often. One of the reasons that phishing is so successful is that users have been conditioned to type their passwords in response to a particular page. As long as users are presented with a page that looks similar to the login page, they will type their passwords. Studies have shown that even savvy computer users can be fooled by a well-constructed, but fake, login page.1 The more often users type their passwords, the higher the risk that they will be phished. Most large services allow their users to sign in once and then to roam about the entire site for some period of time. Only when the users do something that is deemed to be more serious, such as purchasing a product, are they asked again to prove who they are by typing a password.

Deciding how long cookies should remain valid is also a security issue. Clearly, making cookies valid for only one transaction would be ridiculous and annoying, requiring a password for each page transition. At the opposite end of the spectrum, making a cookie valid for all time is equally ridiculous because of the potential for theft and abuse.

The problems of cookie scope and lifetime have not been solved. Most sites, however, have their own rules of thumb, which they attempt to keep internally coherent.

Request Forgery
Once users have logged in and their browsers are dutifully sending their cookies to the server on each request, another problem arises. What if users are able to make modifications to their data on the site they’re using? For example, they could be writing a restaurant review or a blog entry or even changing their password. If the URL of the service that is being used to perform the update is easily guessable, then the user is open to request forgery.

In a request-forgery attack, the attacker creates an URL that will cause something to happen to the user’s account when the user clicks on it. Imagine a blogging system where, to delete an entry, the user posts an URL such as http://myblog.com/username/delete=blogentry where username is the user’s username and the blogentry is a number.

An attacker wanting to delete a victim’s blog entry needs only to craft an URL using the victim’s real username (usually visible on the blog) and the appropriate blogentry number inserted, and then trick the victim into submitting that URL. The attacker can send the victim an URL, such as the one shown below, or place it in a Web page that the victim is likely to read: The user doesn’t see anything, but if this image tag is successfully deployed in a page on the myblog.com site and the user views it, then the blog entry will be deleted.

The server needs a way of figuring out that the user actually meant to take an action. One way is to request the password again on such an action, or the server can make each URL unique in some way, usually by requiring that a signature be generated and put into any URL that takes an action on behalf of the user.

Javascript
The challenges we’ve been talking about so far were present in the static Web content of the 1990s, but an even thornier set of problems is associated with the dynamic Web of the past decade. Whereas it used to be simply that static HTML pages were served to the browser, now code is actually executed in the browser.

This code is often written in JavaScript, an interpreted language that the browser executes while it is displaying a page to the user. Almost everything interesting that can be seen on the Web or any advanced UI tricks are performed with bits of JavaScript downloaded from the Web server and operating within the browser. JavaScript can do just about anything, including looking at all the data in the page the user is looking at – after all, it was designed to manipulate pages and make them look more interesting. JavaScript can also grab and manipulate the user’s cookies and other metadata.

Browsers do not follow the same restrictions on executing JavaScript that they do on setting cookies. A browser will accept JavaScript from any location that a page tells it to.

Unlike cookies, JavaScript does not adhere to a security model based on the domain name of the site. Once a piece of JavaScript has control of your browser, it can do anything, in any domain it likes, no matter from where the code was served or from where it makes additional requests.

One of the risks with JavaScript is that a company has to trust what it’s serving up to its users. A company that serves third-party JavaScript is taking a serious risk with its site because if the third-party JavaScript is malignant, or just contains errors, those problems will directly affect everyone who is served that page. The problem, as the next section explains, is not just a third party serving JavaScript. Many sites now allow users to customize their pages by adding JavaScript to them.

User-Generated Content
Most people who write JavaScript for a living are not malware authors, and though they make mistakes, they are genuinely interested in doing things right. The biggest challenge facing Web sites now is making UGC safe.

The past few years have seen an explosion of sites that allow users to upload and share content. Whether it’s blog entries, reviews, audio, JavaScript, photos, or video, all of these data types are generated by users and then shared with thousands, perhaps millions, of other users worldwide. It’s simply not possible to have human editors review all uploads by all users before they are pushed out onto the network. Virus-scanning software and other blacklist-based solutions go only so far, as the scanning software needs to be constantly updated with new signatures to prevent new attacks from spreading.

You might think that as long as code is not shared among users, there is no way for a virus to spread, but with the advent of the JPEG virus, which inhabits the header of JPEG-encoded pictures, even allowing users to upload photos provides a vector for viruses. Sites that allow users to customize the look of their pages with JavaScript are easy targets for viruses and worms written in that language. The challenge for any site that wishes to allow users to upload and share data is how to do it safely and how to protect the users from each other.

The UGC challenge has a spectrum of solutions. The first is simple: do not allow any UGC and forgo making that a part of the service. Many large sites actually do exclude some or all UGC, but the market pressure is to use more. Those sites that do allow UGC see their popularity, and hence market value, increase.

Most sites now allow some form of UGC, and the smart ones do this by having a very restrictive whitelist of allowable things the user can upload. These whitelists can take on many forms. If the UGC is in the form of HTML data – for example, an online review – then users are restricted in which tags they can use in their text. They are usually allowed bold, underline, italic, and other simple formatting attributes, but they are not allowed to upload full HTML or to use script tags. In the case of photo sharing, the photo can be programmatically resized when it is uploaded, which destroys any data the user had in the JPEG header. To prevent people from instigating a denial-of-service attack on a video-sharing site, the uploaded videos are limited in size. Each type of UGC must be taken on a case-by-case basis. What works for photos may not work for video and vice versa.

Deciding how to handle UGC is similar to deciding on any of the challenges mentioned in this article. What you do is highly dependent on what your system wants to do and what data you need to protect. If users wind up with cookies as their authentication mechanism, then you cannot allow them to upload JavaScript because they will be able to programmatically steal cookies and thereby gain control over other users’ data.

What the Future Holds
At this point you may be tempted to unplug your computer and throw it away in frustration, but that isn’t a very productive solution. The fact is, the Web, and the Internet that underlies it, was designed as a collaborative system for people who were, for the most part, going to behave well and not act maliciously. We are now long past the era where those design principles made sense. What is needed to make the Web a more secure system that people can use and want to use on a daily basis are a few features that were left out of the original design.

A better model of who can do what and to whom when a user is viewing a Web page is one step in the right direction. The browser security model, which depends on domain names to decide who receives the user’s metadata, is probably too coarse of a model to make applications any more complicated than they already are. Every mashup is a security smash-up waiting to happen. People are still designing new systems for the Web that actually attempt to get around the limited browser security model, allowing unfettered access to data in one domain from another. This is clearly moving in the wrong direction.

Depending solely on cookies – in particular, those that have a scope global to the entire domain of a Web site – does not work well for systems with multiple services. It’s time to find a new way of implementing sessions in the sessionless protocol that is HTTP requests. Finding a good way of preventing request forgery must be a component of any solution proposed for the session problem.

The RIA (rich Internet application), where more work is done using JavaScript or Flash in the browser, is the next frontier for security issues on the Web. Issues such as input validation and preventing malicious data from getting into the user’s workspace become more difficult when the source code is downloaded to, and visible in, the browser. It will be very important for programmers to make sure that any sensitive data is verified by the server before the application acts on it.

The problems with UGC will continue because that is where the Web is going, and sites that can’t handle serving UGC will be surpassed by sites that can. The solutions that are most needed now and in the future are those that allow users to generate and share content safely.

References
1. Dhamija, R., Tygar, J.D., Hearst, M. 2006. Why phishing works. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems: 581-590.

GEORGE V. NEVILLE-NEIL is a consultant on networking and operating system code. He also teaches courses on various subjects related to programming. His areas of interest are code spelunking and operating systems. He earned his bachelor’s degree in computer science at Northeastern University in Boston, Massachusetts, and is a member of ACM, the Usenix Association, and IEEE. He is an avid bicyclist and traveler who has made San Francisco his home since 1990.