Category: Mobile

Sorry, your HTTP headers are incomplete

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?

logme.mobi update

I felt like my little site to see a browser’s HTTP request headers, logme.mobi, would at some point die and that is why I have not updated it in months. The reality is much brighter and while I see crawlers visiting every other day (don’t care about those very much and I’m sure they do not care about the service!), I also see mobile devices and strange User-Agents coming every day. This is of course a good sign, a proof that it is useful to some and even if it’s very simple in concept it’s good that it is being used.

For this reason I have spent half an hour today to make a small change that I think can be very useful. Up until yesterday I showed the headers as PHP stores them which was probably OK, but less than perfect as PHP uses its own header names and changes everything to uppercase. Using a simple function (apache_request_headers) I have now changed to the actualy names as received by Apache. This is probably a change that will not make a huge difference to the most, but it’s a valuable improvement to some. I have some other improvement on my mind, but I need to install some software and unfortunately I don’t have time, but expect something soon.

I also removed the officially-dead-for-quite-a-while list of tests. I originally created them thinking of using them as a test suite for browsers and mobile devices and wanted to store results in a database. Eventually and thankfully, dotMobi came in and we developed a nice site for testing that is fully integrated with DeviceAtlas and so now I’m linking that site, if you want to run any tests (see the online docs for TA-DA). Remember that in order to login you will need valid mobiForge/DeviceAtlas credentials; on the up-side, all your tests results are stored with your profile.

New Gmail mobile built on HTML5

I was very pleased to read an article from Alex@Google that describes how they have decided to develop the new gmail mobile web interface.

There are at least two reasons why I liked this article, one is that, as Alex mentions, the team originally developed a J2ME application (that I used quite a bit on my old Sony Ericsson W810i) and then decided they needed a web application to serve slightly different needs (and probably slightly different users). The second reason is that it seems like if you don’t create an application for the App Store you are going to fail, while Alex explains quite a few reasons why developing a web site was better than a native application.

Bottom line is, of course, that users get multiple options and an opportunity to choose what suits them best.

I think the article is well worth 10 minutes of your life, if you still haven’t read it, hurry up to check HTML5 and WebKit pave the way for mobile web applications.

Google crawls and converts WML pages

I knew the Googlebot Mobile visited and stored results for XHTML-MP and WML pages and I assumed they would be used as results to mobile users.

It looks like not only mobile users get “desktop” results, but also the other way around.

I was searching, as usual, for some strange User-Agent string and I found this result:

The converted page looks OK in my browser, of course, but I have no clue what it says! 🙂

Swedish Beers @ MWC 2009

In the last two years, when going to the 3GSM first and MWC last year, I always joined Swedish Beers. While it is a very informal event it is actually very well populated and it’s a very good opportunity to have a good beer, if you like and to meet good guys in the mobile space.

This year I am definitely planning to join the event once again and I look forward to meet lots of mobilists there!

Thanks to Helen for arranging everything, of course!

PS: Yes, dotMobi is a sponsor, but we sponsor because it’s a great event!

WordPress Mobile Plugin by Andy Moore does dirty things

Last week I wanted to take a look at the recently released WordPress 2.7 and of course wanted to give it a go on a mobile. As you might have noticed I’m on Google’s blogger and there is, unfortunately, no mobile version, so a proper mobile plugin would be a big plus for me and a good reason to move away.

I download the tiny zip from the official site, opened the readme.txt file. The file itself did not tell much if not that it would make my blog mobile. Fair enough, I took the php file and copied it in wp-content/plugins. That is all that was apparently required to install and in fact in the admin interface I had a new plugin available, I selected it and enabled on my Mac. The site URL was a local one, of course, wordpress.local (and added to my hosts file to access it).

Looking for some further information I went back to the official site (that I won’t link) and notice that in homepage there’s a nice link mentioning that my wordpress.local is the latest site which installed the plugin! A bit surprised I opened the small PHP file and noticed that there are two calls, one on plugin activation and one on deactivation. Being PHP it was not so hard to find what it does and I was very disappointed with the discovery. On both events the plugin calls a remote API AND send an e-mail to Andy Moore mentioning the site name, URL, and the admin’t email, YES, YOUR E-MAIL address.
In my case, the SMTP server was down, so the e-mail did not get delivered, but to my great disappointment the API was reached and that is why my local install was mentioned on the website.

Nothing wrong has happened, in fact I’m pretty sure if Andy wanted to contact me he would definitely find a way, but it was very disturbing to discover that this happens without letting the user know. If I had been a bit smarter I would have looked at the code and I would have discovered it, the problem is that the average wordpress user will not bother to look at the code and will probably not even be capable of understanding what’s going on. We are not all developers and my impression is that Andy is relying exactly on the inability of his users to disable the feature. The software is GPL and everyone is welcome to look at and change it and that is exactly why I did not even bother to look at it, I took it granted that nothing bad would happen.

In case you wanted to disable this functionality (but it’s probably too late now, I admit), what you should do is open wordpress-mobile.php, find the function wordpress_mobile_plugin_activate (it’s at line 1664 in version 1.3), go to the first line of the function and just add the following line:
return true;

Do the same for the function wordpress_mobile_plugin_deactivate (line 1673 in version 1.3).

Andy has definitely spent time to get this plugin working and maintaing it and I think it’s perfectly fair for him to ask for money and ask his users to provide usage details, but asking and taking are different operations, I my opinion.

SecurityFocus on mobile devices for the first time?

SecurityFocus Newsletter #485 is I think the first issue of the newsletter where mobile devices are listed. 2 issues have been reported one about the iPod Touch and iPhone and the other about the Nokia 6131, both are vulnerable to remote attacks on the browser.

The interest for security on mobile browsers is yet another proof that mobile is about to take over the rest of connected-electronics.


4. Nokia 6131 Multiple Vulnerabilities
BugTraq ID: 30716
Remote: Yes
Last Updated: 2009-01-05
Relevant URL: http://www.securityfocus.com/bid/30716
Summary:
Nokia 6131 is prone to multiple vulnerabilities.

The device is affected by URI-spoofing and denial-of-service issues.

Remote attackers may spoof the source URI of a site to direct users to a malicious location and trigger crashes in an affected device.


23. Apple iPhone and iPod Touch Prior to Version 2.0 Multiple Remote Vulnerabilities
BugTraq ID: 30186
Remote: Yes
Last Updated: 2009-01-05
Relevant URL: http://www.securityfocus.com/bid/30186
Summary:
Apple iPhone and iPod touch are prone to multiple remote vulnerabilities:

1. A vulnerability that may allow users to spoof websites.
2. An information-disclosure vulnerability.
3. A buffer-overflow vulnerability.
4. Two memory-corruption vulnerabilities.

Successfully exploiting these issues may allow attackers to execute arbitrary code, crash the affected application, obtain sensitive information, or direct unsuspecting victims to a spoofed site; other attacks are also possible.

These issues affect iPhone 1.0 through 1.1.4 and iPod touch 1.1 through 1.1.4.