2009 was really a tough year and I, for one, am finally glad to see it behind me. Highlights were really tough to come by and lowlights were everywhere. Of course, the economy and lack of any recovery is the greatest lowlight of the year. Politically, 2009 was a total disaster and not looking to improve in the immediate future which will prolong the poor economic recovery.

But I don't want to talk politics or talk about looking backward - everyone is doing that. I want to look ahead at what is coming down the pike. Call it predictions, call it looking ahead, call it what you will. Here is what I see coming soon.

Social Media will begin a transformation

It simply must. There are already jokes being posted on blogs everywhere about the "Social Media Guru" bloat. There are many problems with Social Media that need to be worked out. It's extraordinarily labor-intensive to get and stay connected. Some people (read "so-called gurus") are trying to automate their twitter postings by recycling things over and over again. There are some twitterers who's postings I can time like a top-40 station's rotation. This is just the symptom of the problem. The problem is that it takes so much effort to get above the background noise of social media that business is having a very hard time with it. Whenever something is labor-intensive it gets automated or outsourced - both result in the legitimacy of the results coming into question.

I think people view social media in the same way they tried to push "eyeballs" during the dot-com bubble. It's new, no one really knows what works, so they promote anything as the answer.

Already the early adopters are beginning to withdraw from the platforms (see those leaving Twitter behind, facebook becoming "uncool", etc). In order to stay current, this platform will need to find a way to show real results - not simply counting followers.

More Powerful Web Applications

Alright, so I'm a bit biased here since I write web applications, but I think we will see an explosion of really user-friendly web applications. Going beyond the idea of tabbed navigation (yawn), but into application that follow a more free-form user experience. AJAX is the heart of things here and while we see bits and pieces everywhere (popup boxes, etc), 2010 will be the true start of an explosion of new web-based application UI development

Look at Google Wave for a start. It's a good beginning, but suffers from a real need for a broad user base to make the collaboration work well. The real-time updates from all collaborators is a really good start. I'm looking to see more multi-tasking applications. Not in the CPU sense, but in the user sense. Almost all applications confine users into doing a single task at a time (see www.tynken.com for an application that doesn't confine users that way).

While this isn't a ground-breaking prediction, after all we have been seening more powerful web applications every year, I think the broad acceptance and use of AJAX by the development community and support in the browsers means we are about to see a real breakout year.

Use of old applications in new ways

In order to gain faster adoption, applications will be written to piggy-back on existing applications. Not mashups, but using an existing application in a new way. Posterous is one example - using email to post blog entries. Signal is another - using email to update database applications. These types of reuse of application knowledge means that it's going to be easier to get users online.

Mobile, mobile, mobile

I think the appStore is getting in the way of itself. There are beginning to be signals that developers are frustrated with Apple's stranglehold on distribution of their product. Android is growing a developer base, but lacks a good single-point application distribution channel. Sound schizo? You bet. On one hand, the appStore is a good thing - single point to promote and distribute. On the other hand, Apple's handling of the appStore means there is opportunity. I was really dissapointed with Sprint's handling of the application potential for the Instinct. I like the phone, hate the lack of developer support and promotion.

Developers can no longer just be concerned about browser compatibility, we now must be developing multi-platform applications so that users can access our software on the users terms, not ours.

I think that is a good start. Let's go out and make 2010 a year to remember for technology! Got more predictions? Leave them here.

AJAX is a great tool and has provided web developers with the opportunity to create wonderful, engaging applications that work better than anything else preceding them. By requesting information asynchronously, one can develop applications that function very much like traditional, installed applications. The resulting application has lower development costs, no distribution costs, lower support costs, and can be integrated with more, 3^rd party applications than a traditional installed application.

However, AJAX has a new set of problems to be handled in order to have a safe, secure application.  Let’s look at two basic things that have to be done in order to make it work right.

Request Hijacking and Spoofing

One of the most basic attacks and problems to an AJAX system is simply the sending of requests to the server directly. While this doesn’t seem to be an issue – it’s huge. Why? Because they can screw up your database, put items in a shopping cart, change pricing, and more.

Let’s look at a quick example, you are running Bob’s Micro-Dog Supplies website. It has a great AJAX interface that is smooth and beautiful. When people add items to the cart it is all done in AJAX. Here’s where the problem comes in. When they check out, you call the following URL  https://www.bobsmicrodog.com/checkout.php. In the POST variables you list the products, the quantity, the price each, and the total price. Sounds great, right? Wrong.

By submitting to the URL with different POST data I could buy the entire order for pennies. Remember, your URL’s are only slightly hidden.

How to fix it

Use AJAX for user interface and non-consequential data management. Pricing and ordering are not inconsequential. A better way would be for the server to have the cart and data and the AJAX version simply make references to it. Anything that is of consequence should be maintained and controlled by the server.

Authentication

The next issue is maintaining authentication. Unfortunately for bobsmicrodog.com, their application had a login script that returned the rights via JSON to the browser. This allowed for a great user experience – it was fast. However, bobsmicrodog.com never checked anything again. If the user could click on a link the server would accept the information. Too bad, that little Johnny learned the URL to send and now they have all the customer information because little Johnny Hacker got into the private side of the site.

How to fix it

Not only must you store all information of consequence on the server, you must also assume that every request to the server is illegitimate. Store security information in a database on the server and verify that the user is who they say they are and that they have the rights to do what they are requesting. Don’t assume that the request can’t be sent via any other method.

You’re not there yet. Because there are sneaky people around, you need to go another step forward. One of bobsmicrodog.com visitors is ordering information while at a coffee shop with wifi. Little Johnny Hacker is sitting in the coffee shop with a sniffer and discovers the customer. Now they have session info, and user keys, and whatever else was posted on the requests. So they form a URL with the session information and maybe other details in the query string or in post data. Bobsmicrodog has modified their system so they check the session and recheck the rights for that user. Oops, now they have Little Johnny Hacker masquerading as the legitimate customer.

How to fix it

You not only have to check the session information, you need to make sure you know where the requests are coming from. Verify the IP address along with the session information. You may have a case, however where the IP address is shared among all users (like behind a proxy server). In that case, checking IP may not be sufficient and you are going to have to be more creative.

The best thing to do is to not use the standard session mechanism but set up your own authentication system to keep track of who is logged in and where. Sessions are automatically created by the server which makes spoofing a session ID easy. Avoiding using sessions in the traditional sense prevents this issue from coming up.

Summary

AJAX applications need to be rethought. It’s not a matter of just calling your standard processing script using AJAX calls. The security issues are more numerous with an AJAX application. You need to do more verification of access rights than you would do with a standard application. You need to have a much safer method of verification user identity than you would do with a standard web application.