Via the WMLProgramming mailing list, see this bug report, and listen to the sound of an assumption creaking gently in the wind.

For quite some time now, folks in the mobile industry have been using the User-Agent HTTP header to identify devices, look up capabilities (using a device database like the WURFL), and deliver appropriate versions of content. Industry initiatives like transcoding which threaten the ability to do this have been met with a variety of flavours of opposition... but it looks like there's a new threat to this practice:

"The different User-Agents are an expected outcome of how Android works. Different parts of the Android system handle different actions.

The browser renders the various mark-up languages, but it will hand off to other applications to handle various file types. In the case of the video player, it uses the OpenCORE framework as you indicated to play video files where the source is HTTP."

Despite the problems such an approach might cause, it isn't actually wrong, either. RFC1945 defines a user agent as:

The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.

So what happens now? Do we start expanding device databases to include not only browser user agents, but also those of individual applications on individual platforms - even presuming that we can distinguish different devices by the apps that run on them? Or do we use some other mechanism to determine device capabilities?

Comments

[nLL]

This behavior same as iPhone's. When you try to stream/download a video, it too sends different user agent.
We could assign a short lived session/download key to url and associate it with initiating browser/device imho it would be less painful than trying to build another database.

[Peter]

Welcome to Mobile - where everything is different. We've come up with a solution that solves this problem for web developers. Our software allows you to send real time device capabilities to a web server using the HTTP request headers (via the browser). This allows you to know exactly what the device is capable of doing before you even have to send a page. Works on all mobile platforms as well. If you're not interested in encrypting the meta data then there is no server side installation required. All you will need is a script to read the incoming headers with all the answers. You can send anything you want from the device - all you do is read the OS API and then our software does the rest.

Cheers,

Peter
www.5o9inc.com

[Tom Hume]

Peter - can you provide some more details of how your product works on all browsers? I'm curious, it's the kind of thing I can imagine being feasible using client-side scripting... but can't see how it can be done without that.

[Mobilitics]

Hi,

some time age I noticed that HTC Hero (don't know about other Android devices) has a browser setting for allowing mobile view. If you enable that setting, UA string is

Mozilla/5.0 (Linux; U; Android 1.5; en-se; HTC Hero Build/CUPCAKE) AppleWebKit/528.5+ (KHTML, like Gecko) Version/3.1.2 Mobile Safari/525.20.1 525.20.1

but if you don't want mobile pages, UA string is

Mozilla/5.0(Macintosh; U; Intel Mac OS X 10_5_5; en- se) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1

so it seems that UA also depends on user's settings.

Cheers,
Harri - http://www.mobilitics.net

[James Pearce]

But this has been a problem for a while, right? - At least, since devices started shipping video players whose provenance was decoupled from the browser. Not as user-upgradable as they are now, but still on a different roadmap to the browser.

Ericsson handsets started the practice of requesting pages with one accept header and images with another... in about 1999.

In a previous life, I attempted to model all the hardware & software components of the world's mobile devices for this purpose. A recognition engine could (statistically, more than anything else) work out capabilities from knowing about the chipsets and the 3rd party software deals that manufacturers had done (e.g. with data sourced from teardown analysts like iSuppli).

Suffice to say I went crazy before it ever really worked. So I do empathise with the pain.

[Cranstone]

Hi Tom,

You already figured it out :). Here's how it works. We have a database that sits on the mobile device (a mobile app if you will). It collects meta data from the device. We break it down into three buckets... Who, What and Where. For What and Where we simply read any device side API that we want the meta data from. This along with personal information added by the user gets stored in the database. The database can be encrypted and also every piece of meta data is under the control of the user. (In addition the meta data can be encrypted in transit for additional protection). What happens next is straightforward. Part of Mobile app contains a browser plugin that essentially adds the meta data to the HTTP request headers when I navigate to an approved domain (also under the control of the user). It adds it via the W3C approved X header format. So for example a header might be HTTP_X_TOM_HUME_LATITUDE="meta data goes here". Now as you've already figured out all I have to do at the server is use a script to read the incoming headers and the data inside them. It conforms to all approved standards and allows you to know in real time what the device is capable of doing without looking anything up.

We're the inventors of mod_gzip, so we took that which is already IT approved and turned it into Mod_Mobile. It now supports real time data compression using both gzip and bz2 and also real time decryption of the incoming content.

There's lots more information on our web site (www.5o9inc.com) including free trial versions. You don't need anything on the server to see it work. Just a script to read the incoming headers. After that you can do whatever you want with the data. We also have introduced something called contextual menus inside the browser. Think of this as nav links that can be coded in HTML but show up in the browser menu for quick navigation like a mobile app would do. Except you can do it with a single line of HTML.

BTW we run on iPhone, Symbian, Blackberry, Windows Mobile and Android and on the server side (if you need the encryption/content acceleration) we support IIS and Apache 2.x.x

Cheers,

Peter.

[Tom Hume]

Thanks Peter.

You mentioned that you support all mobile platforms. How does that work on devices without client-side scripting?

[Cranstone]

You don't need client side scripting - only server side. The data is pushed to the server, not read from the device. That's the beauty of it. The meta data (Device Capabilities) becomes part of the web page request. Doesn't require any effort or anything fancy on the client.

Although for those who only want to use JavaScript we have a solution we call JSAPI (pronounced j-sappy). This allows you to use JavaScript in your web page to access device side capabilities (assumes that the user gives you permission). To see what the code looks like go to this page: http://www.5o9mm.com/jsapime.htm and right click and view source. It's all there.

Cheers,

Peter

[Tom Hume]

How do you push data to the server from, say, a Nokia 6230i? I get how that might be done on platforms that let you do stuff in JavaScript or run native apps, but I'm wondering more about the fat mid-range of Sony Ericssons, Nokia Series 40, etc.

[Cranstone]

The browser does it for you. Here's the deal... on your Nokia 6230i you open up the browser and navigate to a web site, www.tomhume.com Inside that web page request is all the meta data that tells you what the device is capable of doing in real time. Go to this site: http://www.5o9mm.com/ and you can click on the Symbian link and see it running on an N97. Same principal applies to the other phones. The dependency is an HTTP browser and a connection to the web.

[Tom Hume]

Perhaps I'm being a little slow... Could you go into some specifics? Using my Nokia 6230i, I access http://tomhume.org/. What HTTP header fields is the browser adding into the HTTP request I'm making? And how is your software persuading the S40 browser to modify its HTTP headers in the first place? This sounds really interesting, I'd like to know more...

I get how a native app on Symbian, Android, etc., might do this. I'm struggling to see how you'd alter the behaviour of a web browser on devices where there are no third-party native apps allowed.

[Cranstone]

You're not being slow at all. It takes a few tries before everyone gets their head around it.

>> What HTTP header fields is the browser adding into the HTTP request I'm making?

The ones that are in the database. (the mobile app that sits on the device). For example it might be, carrier, cell tower id, lat, long, speed, browser height, browser width, my name, address, email address, zip code, likes, ad preferences. Basically it's a fully customizable database. All of these "headers" and the associated meta data can now be added in real time to the HTTP request.

>> And how is your software persuading the S40 browser to modify its HTTP headers in the first place?

We're not :) What we do is "jump in" as the browser sends the request to www.tomhume.org and for a split second we hold it up and ask the mobile app if it has any meta data for that domain. If so, we add it. If not we release it. (This all takes about a nano second).

>> I'm struggling to see how you'd alter the behaviour of a web browser on devices where there are no third-party native apps allowed.

You're correct here. If the device does not allow third party apps then our solution doesn't apply "unless" we work with the OEM and they include our software on the device.

[Tom Hume]

Peter - how does the "jumping in" work? I can imagine lots of applications for such a thing (and plenty of security risks too)...

[Cranstone]

>> how does the "jumping in" work?

We use a standard browser filter and as the request leaves the browser we simply stop it and add the new meta content (if there is any to add, if not we don't stop the transmission)

>> I can imagine lots of applications for such a thing (and plenty of security risks too)...

Let's talk about the security issues first. When we started we met with prospective clients both on the Enterprise side and also the Consumer. The consumer (mobile user) wanted three things:

1) Convenience
2) Privacy
3) Control

Nothing happens unless the user first enables it. In fact we've been caught a few times doing tech support when programmers can't see the headers. We suddenly remember that unless you have added www.tomhume.org to your approved domain list nothing happens. Also people wanted granular control over what they shared that was personal. So for instance I can share my zip/postal code but not my real time lat/long. Or vice versa. Or as I trust the web service I can share more data that drives relevance.

Also we added a set of Open API's. Let's say that you have a mobile app that uses some proprietary encryption - you don't want to share those algorithms with anyone. No problem. You encrypt the meta data and then hand it over to us via the API and we add it to the HTTP request headers. It arrives at the other end (web server) and all you do is have a script that reads it and then passes it to an engine that does the decryption.

On the Enterprise side we learned that they wanted three things...

1) To make money via "net new revenue opportunities
2) Nothing new to learn - they wanted to use their existing programmers and their toolsets (perl, python, php, javascript etc)
3) Zero integration issues - we solved this by taking something that they already like mod_gzip and turning it into mod_mobile. All you need is a single line in your config file to run it

When we started we approached the problem from the standpoint that the web that we currently know in the future will be the web that knows me. There is nothing sinister in this - we just don't see people typing anything on these devices. Or if they do it's minimal. What we wanted was a way to overcome the limitations of the device, small keyboard, no mouse and tiny monitor. This allows you to do everything without the need to enter data.

Finally it also allows you to offer new services based for example on sensors that attach to a mobile device. A blood pressure monitor connected by bluetooth sends "meta data" to an app on the device. You can then share this data in real time via our solution and you don't have to worry about encryption or privacy etc.

Cheers,

Peter

[Tom Hume]

I'm still not getting it, Peter. What's "a standard browser filter" on, say, the Nokia 6230i? Can you give me a URL describing how this might be configured?

[Cranstone]

A browser filter also known as a mime filter, or a browser plugin. An example is "NetNanny" which installs as part of your browser and allows you to filter certain URL's from loading. Also think of it as an app... so as long as the Nokia 6230i supports the ability to load an app then you can install a browser filter (app).

With our solution there is no configuration, it all runs in the background. The database app which stores the real time meta data simply talks to it anytime the browser gets a web page request.

Database (app) sends data to ---> browser filter (app) which appends it to the outgoing HTTP request headers which goes to the ---> web server where they are read by a script. You can then use CGI to pass the data ---> to a web app server

[Tom Hume]

Isn't there a contradiction here? You describe your product as available for all platforms, but quite a few of the most popular platforms out there (e.g. Nokia Series 40, Sony Ericsson mid-range handsets) don't support the loading of applications or plugins that do the filtering you need. Does your product work on Nokia Series 40 devices and mid-range Sony Ericssons? I can see how it would behave on devices with native apps, but not on the rest.

[Cranstone]

What I should have said when making the statement that it's available for all platforms is the following - the mobile platform must support a HTTP connection via a browser and the OS must allow for the addition of third party applications. If not then we don't work. Sorry about the confusion. Going forward I see this as a significant part of the future for mobile.

I'll check on the S40 series - but the above caveat will apply.

[Cranstone]

One other comment to bring this thread full circle... at the end of your blog you wrote... "Or do we use some other mechanism to determine device capabilities?" We have another mechanism to solve this problems.

[Tom Hume]

That cuts out an awful lot of devices :) And leaves mainly the more advanced ones, no?

Are you able to quantify what percentage of devices your product runs on, which aren't capable of identifying screen width and height through client-side scripting? Those would seem to be the ones where a product like this would really prove itself.

[Cranstone]

WM 5.0 and above, Blackberry 4.02 and above, All versions of Android, iPhone and iPad, Symbian S60. Not sure on the exact percentages, but a reasonable number. IMHO it's not just about identifying the screen width and height through client side scripting. It doesn't supply enough context to deliver a great experience and drive net new revenue opportunities. How many times have you had to type in a user name and password? Cookies don't work and they certainly don't support privacy. HTML5 is meant to be the great savior, but how many phones will support it correctly.

What we wanted was 100% accuracy on every request and we got it. There is no need to interrogate the device, you know ahead of time which is exactly what you need. Sending down a request to figure out something is a waste of bandwidth.

Where our approach really shines is cross platform. Most people can support one platform, maybe two. Ours runs on everything (caveats already listed). Need a sensor data encrypted from your phone along with lat/long/speed and few other things. It's simple to do. It seamlessly integrates with your Web apps with nothing new to learn.

There's no substitute to knowing ahead of time - as your blog mentions the alternative is the continuous updating of online databases with device profile information.

Do we leave a lot of devices "off the table so to speak?" Yes. Can't be helped. We had to look to the future. There's no going backwards now. It's all about smarter data plans, smarter browsers and smarter phones. It will start in the Enterprise and then migrate to the Consumer.

Cheers,

Peter

[Cranstone]

Tom,

One more follow up. Just reading about the device specs for the WinPho7 - see below

800×480 screen (320×480 to follow)
256MB RAM, 8GB flash storage
4-point multi-touch
ARMv7 Cortex/Scorpion or better
DirectX9 support by GPU
Codec acceleration (probably on GPU via DirectX)
5 megapixel camera with flash and separate camera button
Three hard buttons: Start, Search, and Back
GPS, accelerometer, compass, light and proximity sensors

The first and last are important - all kinds of sensors are going to be added to these devices and the screen size and resolution is going to be all over the map. Building mobile apps cross platform is going to become cost prohibitive. Which leaves the browser as the way to go. This brings us full circle back to the very problem you talk about - device capabilities. No way JavaScript is going to tell you about the sensors and other items (SIM cards, Processor ID etc). And User Agent will not be able to keep up with all the new things that are going to appear in the next 5 years.

There is no silver bullet in mobile. Ours is one approach that solves the problem. Others will likely appear. It's a mess out there.

Cheers,

Peter

[Tom Hume]

I think we may have crossed a line from editorial to advertising here... ;)

By my reading of some recent UK handset stats, you're covering a small percentage of the devices out there (<5% of one operator I looked at, IRO 10-20% generally I think). That's quite a long way from everything, or all platforms - caveatted or not.

I agree with you on the value of not typing in a username and password, but exchanging this complexity for managing a list of trusted sites through an on-device application doesn't seem to be much better, unless the user experience of your app is better than that of browsers, and you can persuade users to install it, and educate them about it. Given how tough it is to get users to install apps in the first place, outside the hallowed grounds of iPhone/Android/Blackberry, this seems quite a struggle.

FWIW we're finding HTML5 acceptable for delivering apps across iPhone and Android so far - surprisingly pleasant.

I wonder what other alternatives are out there? Perhaps this logic has to shift to the client, if the server doesn't cut it... or we'll see mixed approaches (client supplies if it knows and can, server substitutes otherwise).

[Tom Hume]

One more, I'm off to bed now ;)

I'm familiar with some of the problems of developing apps across platforms, and with the pain of dealing with fragmentation in mobile. I agree that long-term the browser may be the route things go; in the meantime, both Apple and Google are doing a much better job at dealing with fragmentation than the folks behind J2ME managed to do tho.

There's a JavaScript API for access to sensors documented here, it's been part of the WRT spec since 1.1:

http://library.forum.nokia.com/index.jsp?topic=/Web_Developers_Library/GUID-6C74942D-1C2F-4B7A-A501-2434B54611E2.html

night night :)

[Cranstone]

Agreed. You asked a question and I gave way too long an answer which crossed the line. Sorry about that.

As for the sensor api. It's an API that allows widgets (not the same as a browser) to retrieve and manage information about sensor channels on a device. Guess what - it doesn't work on the other platforms. So now I'm back to square one - HTML5 for some things, JavaScript for others, widgets for others, apps for others. It's not a sustainable business model. HTML5 is going to be the closest there will be to a solution that doesn't involve some sort of client work. And once you get used to working in the browser you're not going to want to hire mobile programmers to build and rev apps.

Here's an interesting post for you. App is crap, why Apple is bad for your health. http://www.bothsidesofthetable.com/2010/02/17/app-is-crap-why-apple-is-bad-for-your-health/ - sums things up pretty well

Goodnight :)