You might know by now that over the years I have developed a little fetish for HTTP request headers of mobile devices. At dotMobi this is a common reason to make fun of me, they let me discuss them for a little while and then either all walk away or just point out that I’m the only one who cares. Obviously, this is not helping very much my mental issues, so I’m here telling the world.
We all know how Apple is sometimes evil and how they tell everyone that the iPhone has a “full web browser” and is not mobile and bla, bla, bla. We know this is not really the case, but we certainly don’t want to ruin the only one thing in 10 years that might be making the mobile web take off!
The headers the iPhone sends do not provide a UAProf URL and all iPhones (2G, 3G and who knows next) all send the same User-Agent string where the only difference is the firmware revision. It is good if you want to know if it’s OS 1 or 2, useless if you want to know if it’s 3G, has GPS and so on.
Unfortunately it looks like Android is following the same path and not really helping developers. The G1 was the very first GooglePhone and everyone implemented a G1-specific UI or site. Hopefully more Android-based devices will come in the next few months and we will see much more activity on our websites, now, if this is true, be prepared for a new device detection nightmare. See these two User-Agents that we recorded in DeviceAtlas:
Mozilla/5.0 (Linux; U; Android 1.5; de-de; HTC Magic Build/CRA86) AppleWebKit/528.5+ (KHTML, like Gecko) Version/3.1.2 Mobile Safari/525.20.1
Mozilla/5.0 (Linux; U; Android 1.5; en-gb; HTC Magic Build/CRA71C) AppleWebKit/528.5+ (KHTML, like Gecko) Version/3.1.2 Mobile Safari/525.20.1
You might have guessed they come from an HTC Magic, the device that Vodafone should be releasing any day now. If you know how most device detection algorithms work you will know that they normally just walk the User-Agent string from left to right and try to match it with known strings. Notice how “de-de” and “en-gb” are before the string “HTC Magic” this will either break that search algorithm or make us record all possible combinations of languages.
But don’t panic, YET, the User-Agent string is not the only HTTP header that a browser will send when requesting some content. Since this is a mobile device (it IS a mobile device, right?) you might expect a UAProf URL. Even though UAProf has not solved all our issues, it was still one of the very few things we KNEW every mobile device would provide since probably year 2002 or so. It was not the case for the iPhone and the G1 and you will not be so surprised to discover that it is also missing with the HTC Magic.
I am sure I can thank HTC for this, not sure how much Google is responsible, surely they haven’t done much NOT to make it happen. I guess we’ll have to wait for some other vendor to come up with an Android-based device.
One last bit of my rant is about a NEW header that is added, instead of the Referrer, the browser sends a header called Origin, which is EXACTLY like the referrer, but with a different name! Good idea, isn’t it?
Andrea Trasatti's tech notes and more 
Well not EXACTLY the samehttp://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.htmlhttp://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt
LikeLike
Meh, this is security paranoia, but thank you for the links Paschal, I just learnt something new.
LikeLike
Andrea,Great post. Like you we believe in the power of headers. So we're going to do something about it. In June we're releasing a product for Windows Mobile & Blackberry into the public domain. It will allow you to add ANY header you want to the outgoing request header. In addition it will come with it's own set of standard headers. If you have a GPS on board your mobile device you can chose an option that will automatically include that data as you navigate to a web site.You shouldn't have to link to any external site when it comes to DEVCAP and TERMCAP – the device should tell you in real time what it's capable of doing. And if it doesn't then there should be a way of adding your own data to the outgoing request headers.We've solved that problem.Local GPS enabled search anyone?Cheers,Peter
LikeLike
It was new to me before last night!I’m with you on the Meh though. The kind of developers that are aware of these obscure new headers are the kind of people who develop sites which are not vulnerable to CSRF attacks in the first place.
LikeLike
Hi Andrea,I know how much you like headers so I thought I would post a link to some really cool headers. You will know exactly what they are when you see them. You will also know exactly what it means you can now do if you can see them.Enjoy. Here’s the link: http://petercranstone.blogspot.com/2009/04/whats-in-your-http-headers.htmlCheers,Peter
LikeLike
Andrea, I have seen this trend as well and, as most of us, I wonder what the future will bring. My guess is that we are facing the challenge of a new dimension; The device as the old well known dimension, and the browser as the new. I guess we will see UA stings identifying the browser, and not the device. A great example is “Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; Smartphone; 240×320)” which is the user agent of both HTC startrek and HTC Tornado. Makes sense, kind of… why should the browser report what kind of device it is running on? You dont see that in the desktop world. You also mention the UA profile. But what should be the contents of the profile? the profile of the browser or the device? The name implies that it is the profile of the UA, that is the browser in my previous example. Then this headerfield is useless as well… 😦 Opera Mini has solved this by addingpropriatory header fields. Whats your(and dotmobis) thoughts?
LikeLike
Jon Arne,this is my blog not dotMobi’s so here are only my views that will often also be the same as dotMobi, but not necessarily.On to your questions, I can only agree partly with you.UAProf was born to describe the “User-Agent” so that should be only about the browser. We all know that up until 1-2 years ago the browser was actually PART of the device so even though probably not perfect it made sense to ALSO describe the device.I agree with you that it is appropriate for the User-Agent string to describe the User-Agent only (i.e. the browser), in a perfect world.As things stand, in the mobile world, we hardly have any access, from the server to the capabilities of the device. In the PC/Windows/Linux/Mac world we have access to those details via Javascript and we know that computers will be able to handle plugins and “strange” contents very well. In the mobile world it’s not like that and even the iPhone that is usually considered the best you can get is actually very poor to deal with contents that are not video and MP3. We need an alternative and today it does not exist. BONDI could be an alternative, but it is still far from coming, I mean we are talking about 1-2 years from now (and that will only happen for high end devices initially, so mainstream is a few years)!I think this is a complex topic and needs careful thinking, but let’s just say that today, I would rather keep everything that was there and add something instead of replacing. So if I was developing a new device with a powerful browser that supports BONDI and lets the server interact with the GPS and contacts, etc, I would still provide the UAProf AND provide access to the new stuff. You can’t just drop stuff in one device and expect that it works and that everyone implements and supports new features.
LikeLike
Hi Andrea,You wrote “As things stand, in the mobile world, we hardly have any access, from the server to the capabilities of the device”.In a few weeks I hope you will be able to change your opinion. Right now we’re able to send any device capability to the server. On Windows Mobile you can access ANY device side data from inside the browser using JavaScript – On Blackberry we simply send you the data via the outgoing HTTP request headers.Totally agree with you on BONDI. It’s years away from being able to do anything. You could try Google Gears, (doesn’t work on BB) but they still can’t do what you need.The problem is really simple to define – the server needs to know more about the device and terminal capabilities of the mobile device “in real time”. Apart from writing a full blown mobile app to send that data via a socket the ONLY other way to do it is via the browser.I’ll be interested to see what you think of 5o9Me when we release it. I think you’re going to be surprised at what you can see. Only dependency is that it works on either BB or WM and requires that you use the default browser (which is also free)Cheers,Peter
LikeLike
did they spell origin correctly?
LikeLike