The firm will presumably be absorbed into the FT's existing operations, allowing it to build mobile apps internally rather than outsource them. Whatever the price tag may have been, it represents a pretty significant investment in mobile for a newspaper company.

In addition to forgoing Apple's revenue share, the HTML5-based app, which looks and feels a lot like a native tablet or smartphone application, has the advantage of being accessible from a range of devices and much easier to update. It also enables them to build out sites with the kind of responsive design techniques utilized by publications like the Boston Globe.

Mobile and tablet development is only going to increase in importance for publishers in the future. With this acquisition, FT can continue to enhance its existing mobile apps and use the development talent at Assanka to help build out future initiatives on various devices.

Facebook mobile is predicated on browser technology. As Facebook's engineering manager Dave Fetterman says in the transcript below, the browser is what Facebook is good at, how it got where it is now and how it will iterate for the future of mobile. We will touch on the future tomorrow, but be sure to read Fetterman's presentation at Facebook's f8 developer conference below because it will inform what we are going to explore tomorrow morning. Really, how did Facebook design for all those platforms and devices?

Editor's note: This story is part of a series we call Redux, where we're re-publishing some of our best posts of 2011. As we look back at the year - and ahead to what next year holds - we think these are the stories that deserve a second glance. It's not just a best-of list, it's also a collection of posts that examine the fundamental issues that continue to shape the Web. We hope you enjoy reading them again and we look forward to bringing you more Web products and trends analysis in 2012. Happy holidays from Team ReadWriteWeb!

What is below is a direct transcript with photos from Fetterman's f8 presentation. A few things to note:

Facebook mobile has its backbone in its mobile website. Everything that is built into the native applications actually comes from the mobile Web. Think of the way PhoneGap wraps a browser-based website and that is how Facebook approached the problem. And then some.

HTML5 is the future. The fourth page gets into how all of this history is leading Facebook to a precipice of change with HTML5 and the so-called Project Spartan.

Also note that Fetterman talks fast and occasionally swears. He is the classic Facebook engineer: kind of young, pretty brash and supremely confident. The transcript is as true to his actual words as possible.

Changing Mobile Standards Through The Past Five Years

We took an extreme HTML-based approach to this. So we will go into how we do this so you can learn how HTML5 is the way out of a lot of these problems.

Because, it wasn't really always this way for us. We have had the same mobile problems that you guys have. We are following the same mobile ecosystem that you guys are following to develop for your users.

So, we have the same problems of cross-platform development that you have and we are hoping that you can learn a little bit from us. So, we have been learning to deal with these issues with what we call "FaceWeb" and learning a new opportunity to get out of this that is emerging as we speak called HTML5.

So, in 2006, building a mobile presence meant that you had a WAP deck that was based on an HTML application with SMS and all of that. But, as you all know, mobile changed fundamentally in 2007. What happened then?

[Crowd] - The iPhone.

The iPhone! Great. What else happened in 2007, perhaps unveiling in the room that you are sitting in right now?

[Crowd] - The Platform.

Yes, the Facebook Platform API. So, what changed for us is that we had to develop a second user experience for the iPhone. A computer in your pocket that no longer sucked. So, it could have Javascript, a CSS and a really rich interaction model. In addition there was Facebook for BlackBerry, Facebook for Windows phone, for Nokia, for Samsung, for everyone now available through the Facebook API.

How about 2008? What was the big thing that happened in 2008?

[Crowd] - Ummm ... Android?

I will pretend that I heard the iPhone App Store. What most developers don't realize is that the first version of the iPhone, you could build websites but the App Store was not available to later. So, in 2008, the App Store enables us to build Facebook for iPhone. The flagship, the vanguard, the best substantiation of Facebook. Based off the API, the same way that you guys are building apps off the API now.

In 2009, what changed in 2009?

[Crowd] Ummm ... Android?

Android, yes. I will pretend that I heard Android. Android was the new player in 2009 and really started taking off. So, all of a sudden we have all of these users on all these devices using Facebook mobile in the wide rainbow of lovely different experiences across Android, iPhone, Windows, the Web. That was great from a user perspective. What sucks? The environment for my developers, essentially. You have the bad old days. You have four different platforms to build for something essentially. You want to build for all of those groups? You are going to have to build the sucker four times. Then there are all of the features - groups, deals, the new profile. All of this stuff and the matrix got really bad. So, we have to build things four times which means that the code gets slow. The code gets old. There are different versions of parity and things just don't work together which makes it extremely difficult for a fast moving company like Facebook.

Next page: Fetterman describes how Facebook reconciled M.Sites and Touch

How To Not Write The Same Functionality Four Times

So, how do we solve this problem? If we have any shot at solving this problem of building things four times ... if you want to build it once, the Web is probably your best shot. So, back in the day we said that we have two websites, right? We have touch.facebook.com and we have m.facebook.com. Different complete docket roots and who decided what is was going to be, where you are going to go based on your phone? Well, it wasn't that complicated. If you were a Webkit phone, you basically redirected towards touch, if you didn't, you got M. If you had CSS, hey, we could throw that in there, no charge, no problem. So, have had this guess and redirect sort of approach to the Web.

That doesn't really solve the problem of everyone having and optimized experience for their phone. Even things like inline images inside the screen, across CSS and versions, that is really problematic when you that those to my right are saved, those to my left are damned. That is the way it is going to work. So, if we had any chance of unifying these two groups and building something once for the mobile Web, we had to solve this problem.

So, what do we need to do? WebKit wasn't enough, we had to have a better level of granularity. What is the difference between a Javascript enabled mobile website from a non-Javascript enabled mobile website? Really, Javascript is there to enable certain types of display and certain type of interaction, primarily AJAX. But, when you think about the controller --- what is Groups? What is the news feed? What is Message? Those are kind of the same thing and they really don't have to be written twice. So back in the day you had to use inefficient solutions like NetBiscuits which were opaque. You could do some XSL post-processing but you can't post-process your way to good Javascript, it doesn't work. With Webkit you started to get poly-fills and modernizer and all this great stuff. But, you actually needed a way to write your code once.

Progressive Enhancement

Here is what we did.

The cornerstone of this is detecting what your phone is going to be able to do. Capabilities, then you can start the right experience. You guys heard of WURFL at all? Wireless Universal Resource File? This is one of the projects out there that attempts to map a user to a user-agent set of capabilities. You know, what is your screen size? What is your JS? Can it do cookies? These are all pernicious, nasty problems that need to be solved. And the use-agent, as you guys can tell, doesn't do the job. So, you need an open database for manufacturers and concerned citizens to be able to tell you what is up. We sponsored this project and this project is continuing to evolve as an open source data site.

So, once you have these capabilities you actually have to figure out what to do with these. A button on Facebook isn't just like it is HTML or this block of Javascript or something. What you want for the homepage is to have your composers render a button that does something. So, you guys say what we really want is a button. You guys figure internally what should be rendering. If it is a low-end phone maybe it is just straight up post form. It if it is a mid-range phone with CSS, maybe you could layer CSS on there. But if it is a high-end phone you really want an AJAX style experience. So, this technique was pioneered by somebody like Yahoo blueprint. So, instead of saying at the top level that this is going to be a good site and this is going to be a low-end site, each component inside that declarative markup that renders the display will decide what it is able to do. And they compose together to form the ideal experience for that phone. This technique is called progressive enhancement.

So, this actually got us to the point where we were able to write once and run anywhere across the Web. And, you know, the Web seems doable. You can do that on your desktop browsers already. Mobile is getting to the point where you actually can do this using a system like this. But, you guys are probably bored about hearing about the Web, despite the fact that an iPhone user and Android user, whoever, can go use a mobile website competently because they all have good browsers, everyone wants an iPhone feature.

So, we were able to eliminate on of our four stacks and get to the point where we had three and that is great. But, of course, everyone wants and iPhone feature. They want their stuff to look like and iPhone, to perform like an iPhone, to feel like an iPhone, all of that. So, we could write it in Objective-C, which we had to do, or we could think about this. Right, so, what about the Facebook news feed is really iPhone-y? You have the top, you have the fixed header, you have it to render directly from cache, all that great stuff. But really, if you look at the content of the publication, that looks a whole lot like a m.site news feed. There is not really that much that is different, there is nothing that special about any particular stack. So, that means that you have to write it three times to do exactly the same shit.

Crazier Than You Guys Can Imagine

So, what if we put the actual browser inside the app? That is the crazy idea. The way we did this was even crazier than you guys might imagine. So, there are a few phones, what browser is going to be able to work for all these phones? Well, three of them have pretty good WebKit implementations. So, we thought, what if we put a Webkit enabled site inside the app and just straight up make that thing work? Just, forget it, we will figure out how to make that thing work.

So, this is actually pretty crazy. This isn't just building Javascript that runs on the client and uses the back end as a data portal. We are actually straight up injecting the site inside these apps. Not quite as simple as getting a UI Web view or whatever. You have to have some interactivity between that Web view and the container but what if we could just straight up use the site? It is almost the same thing, right? So, this is what we did and it is kind of insane.

So, I want to tell you what we learned from this. Of course, unifying the site into the content containers is difficult and something that we would have to overcome but, betting on the browser is just kind of something that we do at Facebook. It is what we are good at and it is our ultimate opportunity to move fast and we are betting hard on the Web because that is what got us here (f8) today. So, we basically want to put the browser inside the Facebook for iPhone app.

Next page: How Facebook moves fast with browser tech and iterates daily

Iterate Daily

So, what doe this get us? It means that you can ship daily. You do not have to wait for an app store approval, which sucks, and you don't have to wait for every user to download this version on the binary which has to be shipped over into their phone. That sucks. You can ship every day. You can break it every day, but you can ship every day.

You can ship it in easy language too. Your Web development team, you iPhone team and your Android team don't have to be separate. They are all the same people, they are all solving the same problem. And you can ship once instead of having to ship four times.

So, how does this work? Project FaceWeb is an extension of this progressive enhancement idea. So, instead of the phone saying I am rendering for a WebKit browser, we send an agent that says you are going to be rendering for a WebKit UI WebKit view inside the iPhone app. So, what you have to do is detect that, style a Web code to make that work, build a bridge between the things that you want to write to interact natively with the Objective-C, say in Javascript, then build HTML pages for Facebok in the iPhone. So, you build much smaller native goop instead of having to build over and over again.

The Answer: Wrap Facebook Mobile Inside the Native App

So, how does this technically work? Essentially the user hits the news feed icon on their iPhone. If this thing is enabled for this FaceWeb technology, it won't map to a native Web controller, it will instead map to some end point on our server that literally says serves up m.facebook.com/home.php. It can't just jam that thing in there. It can't just have the Web view. You actually have to know how it is going to be interacting with the Objective-C. So, you have to send back a JS skeleton which specifies the "platform extraction calls layer" required for that frame. Then you make another trip and load the home.php and the Javascript.

It is a bit of extra work and that does affect some things. But, what that means is that we can write a basic m.facebook.com site and use Javascript to make it work on great phones and use this abstraction layer to interpret Javascript when applicable to do native things like say open the camera for something like the iPhone application.

So, what kinds of things have to go across this bridge? Obvious things like sensors and data. If you want to get your GPS, your accelerometer or orientation lock or some of these things, some are available in HTML5 but a lot of them aren't. So, you have to be able to make some of these sensor-esque answer queries. Depending on the display and how aggressive you want to be, you have to be able to render things look like iPhone. Look like Android. And, you can't do those things just with the browser. You could in theory do this with JS but to look exactly the same you are going to have to use a native call. And additionally, there are elements to Facebook for iPhone that we don't really want to move to HTML. For instance, the camera flow. You open up the camera, you take a picture, you put it in your album or you select something from your gallery and caption it and upload it. That is a lot to do in a browser but it is easy to do in native. So, if you want to deep dive into any existing native flows, that is a bridge we are going to have to cross as well.

Next page: The sticky points and problems with designing once and running everywhere

Sticky Points: Web v. Native Design and Design

PhoneGap has already solved this first problem actually pretty well across even more than just the iPhone. The common problems that you will run into if you do this is; one -- objection, it doesn't look native. Second one is that it is not going to feel native and third is that it isn't fast enough. Here is what we found for each of these things.

The initial mandate was, hey, you guys want to do this thing in HTML, fine, I don't want to be able to tell the difference between Objective-C rendered news feed and HTML rendered news feed. This actually didn't end up being a big problem in terms of visuals. The Web and the app actually work pretty well together. When we shipped this to users there wasn't any complaint except for one that I thought was pretty funny.

There was an iPad "app" for Facebook that was friendly for Facebook, It just simply wrapped the m.site. Some users said, hey, Facebook is copying the app that wraps its m.site as part of its Facebook for iPhone application. Which we were because we were actually just using our m.site and that was great. So, the fact that it doesn't look native, we don't actually have a big problem with that one.

Still, there are some things that you have to look out for. Position fix and overflow scroll were obviously a big problem. Android 2.1 and below, no chance. (Android) 2.2, it is starting to work and iOS 5, thank god, has promised to implement all this stuff. So, you guys are in a better position now to start down this road than you would have been 10 months ago. CSS regradients are a problem, images are a problem and [there are a couple of more gotchas].

Web v. Native Feel: Scrolling

Another problem is that it doesn't feel native and almost always this means scrolling. It doesn't really mean, hey, I want to swipe to delete. That is like, pfft, who cares? Almost always it is going to be something about interactivity and scrolling. Something that the native code does really well by using the GPU and like pipelining all that shit but it is something that it really hard to do in HTML. So, when people say that it doesn't feel native, they are going to be talking about scrolling.

Sometimes you do have implement scrolling. iScroll works pretty well, Hewitts is working on a library that is pretty good. So, you kind of have to defer to a good JS scrolling library. And, make sure you do things like resize your images because was once the responsibility of the GPU is now the responsibility of the browser. And, there are all these little things that just aren't documented, like the keyboard showing up and not closing on Android and iPhone. There are just a lot of little things that are baked into the system that are getting fixed.

The Issue Of Speed

The final one and this is the real bad one is that it just isn't fast enough. If you see a slowdown in your Facebook for iPhone application, it means that we are working through just how to make an HTML-based application work for Facebook for iPhone and it has been pretty hard.

So, tactic one is obviously pre-cache the hell out of this thing. If you render a news feed, start and going to get the content for all of those stories because when the user hits that, you want to have the content ready for them. Cache your Web views. If that doesn't work, the best thing that you can do is to just trick your users. At least have content appear to be ready. Fill out the rendered skeleton and then put in that cached content and then beneath, go get your new content. At least users will feel that there is something there because that is usually what their initial response is. A white screen is just not going to cut it.

So, gotchas in PERF means that you are going to use a lot of JS. You are no longer just loading data, you are loading pre-rendered markup, which is a lot more expensive. And things like HTTP cache and the app cache, they say they work within UI Web views but often they don't. So, you have to be really careful about promises that are made here.

Taking The Approach Everywhere

But, this worked well enough that we said we are going to put the Android app on this party train too. So, we were actually able to write something like the m.site news feed once. Any time you change a news feed story or add a news feed story or add commenting and Liking or whatever, that is going to show up on low-end m.site, high-end m.site, Facebook for iPhone and Facebook for Android the very next day, or whenever we push, which is actually pretty awesome.

So, we did do this. Now we have elements of the Facebook experience, the browser running inside everything. Especially the most volatile stuff, the stuff that relies least on a certain type of display, the stuff that is going to be evolving and changing so much, like the news feed or your profile timeline, we are doing this straight in HTML. That is where the maximum benefit is.

Next Page: How HTML5 Is Leading Facebook In A New Direction

How It Has Evolved: Heading to HTML5

So, what is the history of this? So, for iOS 3.4 and 3.5 we actually did this. Your news feed and your profile feed are actually being sourced from the m.site. So, that means if the m.site changes and adds a feature, you guys get it. If the m.site is broken, it breaks everything. There are positives and negatives there. To be launched in iOS 4.0, requests, notifications and search, this list-style content that doesn't require very specific native access, that is going to be based on FaceWeb as well. Android 1.6 and 1.7 follow the same suit. The feedback and the design have been pretty great but the bugs have been pretty crappy though. Because when you version your Javascript and things go wrong, you are tying your future to the actual Web working perfectly all the time which is something that we obviously move fast on very often.

So, the mission is to operate from one code base and adapt to all the browsers in the world. This sounds like something that Facebook would say, this is actually part of the HTML5 battle flag.

HTML5 is probably the way that we should have done it. This is the way we get to do it now because HTML5 has changed so much under our feet. The initial attempt at building a hybrid application, there were certain things in HTML5 that weren't ready yet and we said forget it, we are going to keep moving forward. The initial attempt to defer certain things to native rendering and native handling that really could be better handled by something like HTML5 and with in-browser technology - device access, good native frameworks and application and display code.

What has changed between then and now that we can take advantage of and that you guys can, who are going to be starting down this hybrid path, might be able to take advantage of in the near term?

Device Access

So, device access. Simple things like getting things that are privileged inside the device. Geo-location, network connectivity, obviously very big for caching, things like your camera and your contacts, what has changed? Well, geo-location has actually been pretty good for a while. This could certainly be HTML5 and that is what we use inside out m.facebook.com based Places and Deals stuff. Network connectivity is emerging and that is getting to the point where you can rely on newer browsers to do it via HTML5. Camera and contacts, because those are so wildly different, a lot of those things are still specified. But, if you want to look at a general list and start by asking the system for a response and getting an answer back, PhoneGap.com actually has a lot of this stuff and they have been able to this poly-fill to make a lot of this work. So, this is the easiest problem but it is the furthest along towards getting solved, especially since we have started working on this hybrid application.

History

There are certain development frameworks that are native. Being able to manage your history, it's weird. Because your history inside a native stack is very different from a browser history. Browsers are very idiosyncratic about how they handle history and it is a very different model. History management, client-side storage is obviously the big one and threading. With threading, if you guys have developed in iOS, you know there are certain things that you have to respect. That is true in Javascript as well. So, you need a good way to figure out how to get other threads to do your work and get it in a cross-platform way.

HTML5 is emerging standards to make all of this go away as well. History management, there is some good stuff in HTML5 coming. IndexDB and client-side storage is getting much better as well. Things like WebWorkers, if we did these things again, we would be able to do it in HTML5.

Can An App Be Built Now Using Only Web Technology?

Finally, I think the important thing is, could you build your app building straight up Web technologies? The actual Web technologies they are using, you are using. Scrolling, refresh, fast stuff, these are things that we had to defer to a native handler in an awkward way. But, scrolling, thank you to Apple and iOS 5 for promising that they are going to make scrolling, position fixed overflow scroll, this might be the problem of the past. Fixed position headers and good scrolling is a hallmark of what people have come to think of as a native application but it is a problem that can be solved by good JS now thanks to these new frameworks.

I think the most important takeaway is that the JS rendering engines have just gotten so much better in the past year and a half. V8 and Nitro have shown that you can build full-fledged, client-side JS applications instead of using Objective-C or Android Java and they will run and users will love them. Things like Netflix have done this very productively already.

So, the emergence and the investment of big browser manufacturers that are making really, really good JS stuff, which is finally paying off. And if you guys are just starting down this path, you will be surprised at just how much success I think that you could really have.

Move Things, Break Things, Fix Things Fast

So, we have been following what was available to us along the road for us since 2006 in Facebook mobile. If the best that we can do is XHTML, fine. If we have a really good browser that uses JS and CSS fine. If we can build and iPhone app and an Android app, that is great. But, what is changing beneath us now is actually the emergence of this HTML5 standards and browsers that implement these standards. Especially around device access and the ability to write apps entirely in Javascript. We have seen a lot of benefit to writing something in HTML. All of our developers are good at HTML. Only a few of them are really good at Objective-C and Android. We are able to make our Web developers the same as our client-side developers in some respects.

Being able to write it once today and ship it tomorrow? That is something that Facebook is really good at and that we love doing and that is at the center of being able to move fast. Move fast has an implicit third clause - move fast, break things, and fix things fast. That is very difficult to do if you have already shipped your binary to Apple or Android and they have to download another version of it.

Google recently implemented new technologies in Chrome enabling Web apps to securely execute low-level code in the browser, blurring the line between Web and native apps. Google wants Web apps everywhere, and today's Chrome release is full of new ways to promote them.

Google has been pushing the Chrome Web Store this year to encourage developers and build a revenue stream. It expanded international support for the store and app marketing, and it launched an API for in-app payments. Today's overhaul of the store is all about marketing Web apps and making them more appealing.

Google has been steadily dialing up the importance of Web apps in a long succession of Chrome versions. Its recent technological advancements offer a new, Web-based vision of software, and the new store and browser features promote it. It's not just about the desktop, either; as we observed when today's features launched in the Chrome beta channel in September, it's a rather tablet-like interface.

Read more about today's update on the Chrome blog.

What do you think of Google's vision of Web apps? Share your thoughts in the comments.

In the meantime, a Brazilian company called Movile has launched a new version of its Web app store, Zeewe 2.0, which incorporates some key HTML5 features and could provide a roadmap for U.S. developers, like Facebook, in creation of a Web app store.

One of the features of HTML5 is the ability to use offline caching to create Web apps that work when you do not have an Internet connection. This is essentially what Movile has done with Zeewe 2.0. The app store will function just fine, even if your smartphone is in airplane mode.

Offline caching means that Web app downloads up to 10-times faster than the original version of the store. We have seen various U.S. developers, like Amazon and Mozilla, start implementing offline caching in their apps. The browser does not need to go back to the server for data retrieval. Currently, four main Movile partners have games that will function with the data caching aspect as well: Block Dream, Blast Effect, Checklist and Card Flip.

The faster an app store is, the more likely that users will click through to buy and app. Once a user has an app, Movile hopes that they will then use their new payments API to push users towards in-app purchases.

Carrier Billing Partnership With Zong

Movile has created a roadmap that a company like Facebook should take note of. HTML5-based applications tied through carrier billing and the mobile browser. It is about as easy a formula to follow for a consumer than almost anything else in the mobile realm.

Movile head of innovation Eduardo Lins Henrique told ReadWriteWeb that almost 60% of the apps available through Zeewe are from game developers. That would mesh with what we have seen from domestic developers - the gamers are on the forefront of the HTML5 push. Henrique also said that there is an adult content section to the Zeewe store, something that most U.S. HTML5 developers will probably shy away from. Yet, do not discount the ability of the massive adult content ecosystem to push the envelope of HTML5 development.

Does Movile have the right model? How long before something similar comes from a prominent developer in the United States? Let us know in the comments.

When Apple changed their subscription rules to require that publishers fork over 30% of the revenue generated from apps sold in the iTunes store, many media companies played along, hoping that making their content available on iOS devices would help them survive the transition from print to pixels.

So how's the HTML5 experiment going? Pretty well, it turns out. The publication is now getting more traffic to its tablet-friendly Web app than it saw on the old native applications, according to Reuters. The newspaper company said that's it now seen over 700,000 visitors to the Web app.

Just as with native apps generally, people who read the Financial Times via the Web app from their smartphones and tablets are more engaged than users who visit the publication's desktop website.

"They are consuming about three times as many pages through the app as they are through the desktop in an average visit," Rob Grimshaw, managing director of FT.com, told Reuters.

When you use the FT Web app from an iPad, the experience comes pretty close to mimicking that of a native news app. It's pretty light on the slick, animated type of UI tricks that tablet apps often have, but you can do things like swipe your finger right and left to navigate the paper's different sections.

It's still pretty early in this battle. For media companies deciding how best to allocate their budgets for their mobile strategies, the experience of the Financial Times provides an early indication that developing cross-platform Web apps can pay off.

The update also contains some long-awaited improvements for users of Mac OS X Lion, which did not get along well with Chrome previously. In addition to fixing "many crash bugs" and adding "some all-around visual polish," this release adds Lion's new scrollbars and support for its full-screen mode.

Check out what Native Client can do:

The new release also opens the Web Audio API, which enables Web developers to build in sophisticated audio effects instead of just playing back simple sound files. Google provides some examples of the kinds of cool effects made possible by this API, and they're worth a listen. (Note: you'll need a browser that supports the Web Audio API, so try it in an updated copy of Chrome.)

This Chrome release expands the realm of possibility for browser-based applications. Now that native-level code can run in the browser, where is the line between "Web apps" and "native apps" in the desktop environment?

What's your primary browser?

Weaknesses in Web applications make up 31% of all vulnerabilities, according to HP. Technically, reports of Web app vulnerabilities have gone down in recent years, but that is not necessarily a good thing. Legacy Web apps still provide a great risk to enterprise security.

HP founded a program called the "Zero Day Initiative" (ZDI) in 2005 designed to reward security professionals for responsibly reporting unknown vulnerabilities. Since 2005, Apple Quicktime has the most reported vulnerabilities with Microsoft Internet Explorer coming in second. Java, Firefox, Webkit, Real Player and Adobe (Shockwave and Reader) also make the list, along with HP OpenView. Those are some of the most fundamental technologies on the Web and their breadth contributes to the problem of enterprise security risks.

HP notes that it does not really matter if there are new vulnerabilities or not. Malicious hackers already have an ample surface of attack with existing vulnerabilities. Patching, closing, fixing, debugging, replacing software, installing security measures or any other method that can be done to fix those vulnerabilities across the entire enterprise landscape would cost hundreds of millions if not billions of dollars. Yet, considering the volume of attacks keeps on increasing no matter how many vulnerabilities are reported, it behooves industries to attempt to get their networks up to do. See the chart below for mid-year attack totals from 2009-11.

SQL injection (SQLi) attacks are very popular among "hacktivist" groups like LulzSec and Anonymous. Booz Allen Hamilton's recent email leak was mostly SQLi related. The prevalence of SQLi attacks is laughable. Worming an SQL attack into a company's server should be fairly simple to stop with a layered security approach that stops the data injection with firewalls or data sandboxes within the servers. It is a popular attack because it works. It works because enterprises either do not know what they are protecting against or have been too negligent in updating their security policies.

Check out HP's entire report here (PDF).

What can enterprises do to close the gap between legacy vulnerabilities and Web application usage? As we have seen, the attack surface is wide, like a stretched-out cloth that can easily be penetrated by hackers who know what they are looking for. As Web apps become more critical to critical business functions, how can IT managers and the security industry shrink the amount of avenues that malicious hackers use to gain access to sensitive information?

The new Firefox for Android app is faster and sleeker than its previous version. In a few words, it actually works. That was not always the case with previous Firefox for Android builds that were difficult to navigate. It is designed to look and feel like an Android application and has a new home screen page, buttons and easy to use features like Firefox sync, add-ons, tabbed browsing and bookmarks. In preliminary testing, the app is more responsive, pinches and zooms faster and generally looks cleaner. Outside of optimization, Mozilla is pointing the way that mobile browsers could and should go in the near future.

Mozilla also has the IndexDB API that gives developers local database storage to make Web apps, websites and restart-less add-ons. The API can also help developers make some application functionality available offline and can increase performance and reduce data usage.

The IndexDB API signals a trend in mobile that companies like Mozilla and Amazon are starting to take advantage of - the offline app. Amazon's new Kindle Cloud Reader, while still a bit buggy, caches the app and its data so it can be used without an Internet connection. This could dynamically change how mobile Web apps are used by developers and consumers and, along with HTML5, is the next evolution of mobile development.

Image: The Firefox Fennec also known as Firefox Mobile

Web Intents, based on an existing capability in Google's Android mobile OS, will let Web apps express a simple call for an action, like 'share' or 'edit,' which receiving apps will be designed to use, without either app needing to have specific knowledge of the APIs of the other. This way, instead of having to code for each specific Web app one might want to access, developers can just use these simple requests, which will be built into the browser. The Chrome and Firefox teams are each building this functionality for their own browser, but they're combining their proposals to use a single API for Web app developers to reach both platforms.

"If I built an image gallery application and I wanted to let users edit an image so that they can remove red-eye from a photo I either have to build an application that edits the images, or integrate with a 3rd party solution. Doing this is hard and stops you from building an awesome image gallery; and what happens if the user has a favorite service that they already use to remove red-eye? Simple, you have a frustrated user."

The goal of Web intents, says Kinlan, is "to allow developers to build applications and services that could work with each other, but not need to explicitly know about each other." The concept was inspired by Android's functionality, he says, but "the API bore no resemblance."

Android has had these same capabilities for a while, which has made life easier for mobile app developers in Google's ecosystem. With the Chrome team taking big steps to advance its browser, especially by fleshing out its Web app store, Web Intents will be a timely addition to the desktop platform.

Now that each team is working on Web Intents, some pretty interesting code examples are available to play with. Here's Mozilla's demo video of how they want the user side of the experience to work:

In July, Google launched their API for in-app payments in apps delivered through the Chrome Web Store. The transaction incurs a flat 5% fee.

Mozilla, maker of the Firefox browser, has challenged Google's concept of Web apps, though, contending that because Chrome Web apps can be made "installable," using some local storage and computing, they're not true Web apps, which should be fully accessible via any Web browser. Google may envision a world where all software lives on the Web, but as it monetizes the Chrome Web Store worldwide, it clearly has a motivation to make its own browser the user's privileged point of access.

Until now, credit card accounts and personal information have been stored in centralized, online databases, making them vulnerable to attacks. With the new cloudKey system, which uses standard encryption technology and a "distributed key" topology, appMobi aims to deliver a more secure solution.

With cloudKey, customers' private data is stored using 256-bit AES (Advanced Encryption Standard), which is the NSA-approved data encryption standard. It also uses a "distributed key" topology, which means that the appMobi servers don't house the private data themselves, only decryption keys. These keys on their own are worthless - a hacker would still need to get hold of a user's device in order to obtain the credit card data.

Even then, doing so would be difficult. The data on the device is encrypted, too, and hackers would have to crack a password to get access to that information. Even if a hacker was able to break through all these barriers, the payoff would be minimal - perhaps just one credit card number. For most hackers, that would represent too much work for too little reward.

cloudKey Technology

The new cloudKey e-commerce system easily integrates with payment gateways from PayPal, Authorize.net and even direct carrier billing. It has been tested in all major browsers, including Chrome, Firefox, Opera, IE 6+ and Safari, and works both online or on mobile.

The system's technology does not require specialized hardware, either, which makes it different than point-of-sale focused payment systems that use NFC, for example. With NFC, devices have to come equipped with secure storage - a special on-device hardware storage area where credit card information and other private data is saved. Although appMobi's system is not competitive with NFC, as it's designed for online and mobile purchases, not physical ones taking place at a cash register, it is possible that parts of this system could be used to enable a secure storage area of sorts on NFC-equipped phones that lack the necessary hardware, like Nokia's C7 and N9. These new Nokia devices, it's been discovered, are not capable of supporting mobile payments or mobile wallets, for that very reason.

Where to Get It

The cloudKey technology will be immediately integrated into appMobi's 1Touch payment system, for use by mobile and Web developers. It will be free for 30 days, and afterwards, there will be a flat rate of 10 cents per transaction.

So I decided to put away my laptop (a MacBook Pro, for those keeping score at home) and try to go a full day without any native apps. I ran my new Chromebook through the paces, and although it's a Friday, true - a day when a lot less tech news and tech blogging tends to happen - I was still able to perform my job, with little more struggling than if I'd moved to any new computer (or upgraded to a brand new operating system).

But a caveat here before I sing the praises of my Friday on a Chromebook too vociferously: I have moved much of my world into the cloud, and the Google cloud at that. I already rely on Google apps: I use Google Docs, Google Calendar, Google Reader, and of course Gmail in lieu of native app alternatives to writing, scheduling, RSS-ing, and email.

Replacing Native Apps

There are, however, some native apps upon which other aspects of my work world depend. Thanks to the suggestion of Wired's YoruFukurou as my Mac Twitter client. I use Things as my To Do list manager, as I can sync my tasks across Mac and iOS. I use the native app version of Evernote. I use Text Expander to save keystrokes for the phrases I type over and over again throughout my day. Starting just last week, I've given Spotify a whirl; before that, iTunes was my music player of choice. And finally, there's Skype, the tool that the ReadWriteWeb team uses for both chat and voice messaging.

And it was a replacement for Skype that had me scrambling first thing this morning. We have an editorial meeting every morning - voice, not video - and I had to take the Skype call on my iPhone. Strike 1 against the Chromebook, perhaps, but not an insurmountable problem. There are other Web-based VOIP alternatives, least of which being the new Google Plus Hangouts. And for the rest of the day, I found myself using imo.im, a Web-based tool where I could still monitor Skype chat.

To replace the my native app Twitter client, I utilized the Tweetdeck Chrome app. To replace the native Evernote app, I used its Web version. I installed the Aviary Chrome apps to handle screenshots and photo-editing. I could have used Google Music, I suppose, to play songs, but I ended up using the Spotify app on my iPhone instead (cheating, yes). Likewise I updated my To Do list on Things by utilizing the iPhone app.

And that's one of the major discoveries I think from my day: although there have been a lot of complaints about the state of Web apps not being quite "ready for primetime," many of us now carry two computing devices with us: one laptop-like machine and one smartphone. What my Web-based Chromebook couldn't do, my iPhone could. That could be an indictment of the Web, I suppose, or an admonishment for those who've neglected building Web apps in exchange for focusing on native ones. Or it could be a recognition that our productivity today now relies on a lot more than simply one device. And in a lot of ways, that's an argument for the cloud and for the Web. Store your information there. Access it anywhere, no matter if you're using a smartphone, a native app, or a dumb terminal.

What I Like About Chrome OS

There were things about the Chrome OS that I found really surprising and actually quite pleasing. I love the way notifications work, for example. As a Mac user, I've become quite reliant on Growl to give me the pop-up messages when I have new mail, new Skype messages, and the like. Notifications in Chrome OS work similarly, and I was able to configure my Gmail, my Skype messages, the Tweetdeck Web app, and Google Chat to give me the notifications I needed. Even better, that Google Chat app stayed open across all tabs, so that I didn't have to locate the tab in which I'd originally started the conversation.

I was also surprised with the ease with which I could handle file downloads. As a tech blogger, I was worried about capturing, saving, and editing images. Every blog post requires some sort of image, after all, and these inevitably have to be cropped and resized. (And yeah, I need practice with Aviary for sure.) But you can still save files to the Chromebook (and Google makes it easy to transfer these to Picasa, no big surprise), and one of the things I assumed would be the biggest hassle was only a slight hassle.

What Irked Me About Chrome OS

But there were hassles, don't get me wrong. I had a fairly high incidence of crashing browser tabs. Of course, as a Mac user, I'm pretty accustomed to my Chrome browser crashing. But it occurred with a fairly high frequency today, forcing me to scour for a Task Manager (Chrome does have one) and to assess what was actually eating all my memory. Lo and behold, it was Google Plus. I blame the animated kitty GIFs.

I also never found a replacement for Text Expander, and I hope some dear ReadWriteWeb reader has a suggestion to help me there. I type " < a href= " a lot during my day. Anything that can save me from those keystrokes would be awesome. I also struggled to capture screenshots with Aviary, particularly of the multitude of crashed Chrome tabs.

Admittedly, I'm pretty hard on a computer - I work online after all. And at the end of the day, despite a lot of reservations, I think the Chromebook is very much doable for most folks. It's not a stellar experience, not yet at least. It takes a lot of patience, but for really, that's not a surprise when it comes to tackling a new machine and a new OS. And at the end of the day, a lot of the struggles I had aren't necessarily the fault of the Samsung hardware or of the Chrome operating system.

It's the reluctance on the part of folks to try something new. And yes, all of you who are still using Internet Explorer 6, I'm looking at you. How many folks have the patience to try something new? Or, as we've been accustomed to with tech companies that promise things "just work," do we expect a seamless out-of-the-box experience?

The drawbacks to Chrome OS, of course, are also the fact that a lot of effort has been put into making shiny native apps, to the detriment of Web app development. With HTML5, I think we can do most things in a browser now. There wasn't anything today I wasn't able to do, even if I had to search for an alternative to the app I was accustomed to using. (The one exception: watching Netflix. But that's why I have my iPad. I've already refused to install SIlverlight on my Mac to enable viewing there.)

Disclosure: I received a Samsung Chromebook having been an attendee at Google I/O. Chromebook error message image via Engadget.

That's where Brazilian mobile services company Movile finds itself: with a thriving business of mobile users throughout Latin America, who are heavily engaged in purchasing SMS services and virtual goods, but with the knowledge that there's far more to be done than sell those existing products. Movile has a corporate vision of leapfrogging over the App Store 1.0 experience so dominated by Apple among smart phone owners in the United States. How does the company aim to build the app store of the future? By combining cross-platform mobile HTML5 with ecommerce and now social APIs.

The technology itself is interesting, but it's made even more so because it's coming out of Brazil. "We believe that the future of mobile apps is based on the open web standards of HTML5 and driving cross-platform mobile experiences that leverage the social graph," says Flávio Stecca, CTO of Movile and Zeewe Lead. "We think [our platform] will boost discovery and usage of HTML5. We expect that in the future, most users will find the best mobile apps, not by going to a traditional app store but through social discovery - just like they do with web content today."

If I had any Facebook friends using Zeewe, then they'd all know now that I added the apps I found. I rated several apps, played a Tetris rip-off and generally had a good time using the platform this morning. Zeewe now offers easy hooks for developers to make those experiences social and with leaderboards where appropriate. The company says it's got an Android version and an in-app payment API well underway and both will be launched soon.

Movile believes that the future of apps will be based on the cross-platform mobile web, but also on tablets and web-enabled TVs. In order to take a leap at leading that market, the Brazilian company is focused on international markets outside its home territory of Latin America.

Global Mobile Innovation, Born in Brazil

Movile is a big company already. It has 10 offices around Latin America and employs nearly 300 people, 70 of whom are technologists. The company's bread and butter is premium SMS services and payment for virtual goods. Brazilians are very into both. A deeply social culture, a fast-rising lower to middle class and a frenzy of economic activity after decades of military dictatorship and subsequent hyper-inflation have all added up to making Brazil one of the most dynamic economies on earth when it comes to social and mobile technology. Only Malaysians spend more time on Twitter per capita than Brazilians do, for example.

Movile parlayed its early success serving this market into a deal that sold 60% of its shares to international media conglomerate Naspers. Naspers is from South Africa and is a silent giant that many US tech watchers may be unfamiliar with. It's one of the world's few old media companies that have succeeded in shifting into the new online media economy - largely through a wave of acquisitions of startups around the developing world. Naspers handles its startups in a way I wish US companies would: they hardly change anything. They keep successful executive teams in place and provide support for early winners in the developing world to just get bigger.

Some of those startups take a similar strategy themselves. Naspers-owned Brazilian e-commerce company Buscape, which was acquired for nearly $400 million USD in the most-watched deal in Brazilian web tech, has followed its parent's lead, for example. Buscape acquired 10 companies last year, including a meta-site indexing multiple daily deals offerings, and lets those startups continue operating semi-independently under its corporate umbrella as departments of Buscape.

All of these companies and companies inside of companies are allowed to maintain a high degree of independence in order to innovate. They are focusing outside their own markets, they are building for a world of even more mobile use than they see today and they are alligning themselves with the open and international web.

Is the web a US-centric phenomenon dominated by Apple and Facebook? Not in Brazil, it's not. Facebook may be coming on fast and will likely soon overcome Google's social network Orkut - but Apple devices will likely remain an exclusive status symbol for the very elite well into the future. Not just because the population in Brazil is poorer than in the United States - but because iPhones and iPads cost twice as much there as they do in the US thanks to heavy taxation.

In Brazil the technologists I spoke with were much more interested in low-cost, affordable, accessible and open web and mobile platforms. Add social and in-app payment APIs and mobile web apps look stronger and stronger. Will it all add up to make mobile web apps a viable competitor to native mobile apps some day? Only time will tell, but it should be a good contest.

Disclosure: Movile and Buscape were among the companies that paid my travel expenses to visit Brazil and report on the tech scene there.

In many ways, this is what people have been predicting for a while -- HTML5 will kill the native mobile application. There are few better companies than Facebook to take up the mantle of HTML5 to foster an environment of Web applications. Facebook has the user and developer base, the social reach and deep pockets to make a big splash in the mobile ecosystem.

It will reportedly work like this: open Facebook's mobile site and get a drop-down menu of Web applications. Those apps can be opened and then framed within Facebook to give them Facebook functionality.

If this report is true, there are a couple implications to consider. Foremost, Facebook would rise as a distributor in mobile applications, a place where it currently has no presence. Their current application for iOS and Android is relatively uninspired, almost like they have thrown a token app out into the ecosystem until they can build something they see are more revolutionary, such as Project Spartan. Second will be the widespread adoption of HTML5 and the acceleration of its growth as a Web standard. The correlation may be the equivalent negative impact on Adobe's Flash and its sooner-than-expected banishment from the toolbox of mobile.

Also to be considered is that Facebook, despite its 700 million users and mountains of data, is not suited to be a mobile application distributor. One of the things that Apple and Android have that Facebook does not is that they control their platforms. The idea for Facebook is to wrest control of applications from within the platforms through something that the OS owners cannot fundamentally control - the browser. In the end though, you are still using an iPhone or an Android. What is the incentive to go to Facebook to do something that Apple and Google already make so easy?

Of the Alexa 500 top sites in the U.S., 40% were optimized for smartphones (42% iOS, 38% Android). Yet when it comes to Android, those 200 sites overwhelmingly returned the same page to both a smartphone and a tablet, meaning that developers have not rendered Android specific versions of their sites for Android tablets. See the infographic after the jump.

"For iOS there is only one phone and one tablet with known resolutions and screen sizes," Blaze said in a release. "For Android, phones and tablets come in many shapes and sizes with new ones coming out monthly. Variety provides more choice to consumers but creates a burden for site owners to keep up."

Android device fragmentation has been a problem for developers since the beginning of the platform. It is very difficult to create a native application or a mobile optimized site for Android when devices have screen sizes ranging from 3.5 (various smartphones), 4.3 inches (HTC Evo), 7 inches (HTC Flyer, Samsung Galaxy Tab) to 10.1 inches (Galaxy Tab). There are phones and tablets that range in between all those screen sizes as well.

Blaze also did a speed test on tablets and smartphones. It says that the iPad 2 is 25% faster than the iPhone 4 and 20% faster than the iPad 1. The Android Motorola Xoom tablet is 25% faster than the Samsung Nexus S smartphone.