The Prepaid Wireless Internet Wiki is Evolving

As many of you know I am a frequent traveler in Europe and finding ways to stay connected while on the move has become sort of a passion. 2007 was definitely the year when prepaid SIM cards for accessing the Internet via GSM and UMTS networks became fashionable. At some point there were so many offers out there that it was difficult to keep track. So I started the Prepaid Wireless Internet Access Wiki to put down my knowledge and to invite others to do the same.

It has worked very well, the Wiki has been growing ever since. I even found some hot tips myself: France, not really on the afterburner in the mobile domain now has two prepaid Internet access offers and I am using one of them on a daily basis when I am in the country. And in Germany, my AldiTalk SIM card has been replaced by a Congstar SIM as the network operator makes all the difference. This is the power of the web! Sharing information and getting good tips for it in return. Thanks to all of you who keep the Wiki updated. Looking forward to the next tip!

Android 3G phone as a Wifi access point?

About a year ago I’ve written a blog post about how nice it would be if Nokia N-series phones with 3G and Wifi could be used as a Wifi access point. The post keeps getting a lot of hits via search engines and a lot of comments have been left until the comments section was closed automatically to reduce comment spam. Looks like I am not the only one thinking about such a feature. A year later a solution or rather workaround seems to have surfaced at least for some Windows Mobile devices. These days I am wondering if Google’s Android platform for mobile devices might be the choice for some people to really implement such a feature!?

So why on Android? The answer is Open Source! Windows Mobile, S60 and other mobile phone operating systems are closed source. Application developers can only use the Application Programming Interface (API) of the operating system which simply does not allow programmers to do such low layer things as reconfiguring the Wifi chip, setting up a system wide DHCP and DNS proxy and to interconnect the Wifi interface with the 3.5G interface. But with Android, things are different. The operating system is Linux so the source code and programing tools to modify the operating system are available. So as they say in the video below at the end, "start composing"!

Oh, by the way, there are already some open source mobile devices out there, the Nokia Internet Tablets (N770, N800, N810). Their operating system called Memo is also based on Linux and there is lots of activity in the filed. The latest version of the software even ships with an Xterm so deep diving without installing additional software is possible. There are even some tools ported from mainstream Linux to tweak the Wifi chip. Won’t help much on these devices for a Wifi/3.5G access point since the Internet tablets do not have a 3.5G Interface. Nevertheless it shows the possibilities.

Let’s see who gets there first, closed source or open source. Where do you place your bets?

SNCF is now .mobi

Sncfmobi
Bienvenue, SNCF in the mobile world! This December, SNCF has launched their .mobi mobile portal for travelers to look up train times and to order tickets. I’ve been used to this service from other train companies for years and I am glad to finally see a similar service in France now as well. Even though there seems to be an advertisement cooperation in place with Bouygues Telecom the service is based on HTML and usable on all wap 2.0 capable mobiles. Well done, SNCF, thank you!

Next task: Please upgrade your vending machines to accept international credit cards so I don’t have to queue up every time I have bought a ticket online (and please tell RATP, too…). A sorrow I share with many foreign travelers in France!

Via Fullblog

My Crazy Phone Numbers

As both my private and my business life is pretty international I would estimate that 80% of my calls are international these days. Most of these calls are carried over VoIP for some of the distance. Interestingly, that has some strange consequences for the phone number that the other end is shown. Some examples:

Business calls: I use a SIP VoIP client on the PC and the SIP network of my company for most business calls. To reduce cost, my company has a lot of voice gateways deployed in different countries. The IP network thus transports the VoIP call to the closest media gateway and then releases the call to the public circuit switched network. As a result the caller always sees a local number instead of my real number. Nice to hide the fact that you are not actually in the country. However, the number can not be called back.

For private calls I use Skype a lot. Skype does similar things and has gateways in many countries to release the call to the public telephone network as close to the destination as possible. Again a mysterious local number is shown (e.g. +491234). Most people are quite surprised to see such a number.

When I am in Germany and have to call a mobile phone abroad I use one of the many alternative PSTN operators. Again the number that is shown looks funny and has nothing to do with my real number.

And when I am out and about and want to call abroad from the mobile I use the services of Rebtel which lets me call a national number and then forwards the call internationally at a fraction of the cost of a direct call from the mobile. Again, same story with the calling number being displayed on the other end.

So why is there a number displayed at all at the other end if it is just fictuous? Nobody ever heard of CLIR?

P.S.: I wonder if there is a law prohibiting media gateways in a country to send the international number from a different country!?

P.P.S.: For the moment I seem to be the exception. So most people these days pick up the phone and say: “The number looks funny, this must be you, Martin!”. Sort of an alternative caller ID…

Wifi Printing becomes En Vougue

Wifiprint1
Recently, I had to get a new printer as the old one is slowly wearing out and an integrated scanner/copier would be a nice thing, too. Quite some things have changed since I last went to the computer store to buy a printer. Half of the printer/scanner/copier solutions starting from €120.- had built in Wifi so it can be used by all computers in the household. Looks like the Wifi chip has finally become cheap enough to make it into these sorts of devices. I wonder when/if digital cameras will be equipped with Wifi as well.

Wifiprint2
After some back and forth I decided to go for an HP C7280 for around 270 euros. A really impressive device with lots of functions. Setup was straight forward, input of the Wifi WPA key and it was part of the network. A bit of configuration in the Wifi access point to ensure it always gets the same IP address and the network was ready, too. The PictBridge USB port also supports USB sticks for direct printing and Bluetooth dongles to print directly from a mobile phone. I tried it with the Bluetooth dongle I usually use with my PC and the printer detected and used the Bluetooth stick without any manual configuration. Once the phone has sent the picture via Bluetooth the print starts automatically. Very nice. Printing from a PC via the Wifi network works just as quickly as over Ethernet or USB cable except for a somewhat long startup time of 20 seconds or so before the first page is printed. Subsequent pages, however, are printed without delay.

While I am very impressed with the printer I am VERY disappointed with the PC software of HP. I installed it on two computers and both, after rebooting, had a nasty task running in the background which consumed 100% of the processing power. Looks like I am not the only person with that problem so fortunately the Internet provided quick help. HP, how can such a glitch happen? Also, the software is not really light on CPU resources. While the printer is online some tasks in the background keep loading my CPU. Not that I would bother too much but the fan on my notebook runs almost permanently. Again, HP, what were you thinking? I’ve fixed the problem with a little hack, i.e. by killing the tasks running in the background and only activating them when I want to print something.

Despite the flaky HP software the printer integrates nicely in my home network due to the built in Wifi chip. No longer do I have to use memory sticks or to carry a notebook around when I want to print out something from a computer which is not close to the printer.

Velib’s Mobile Site

For a couple of months now, the city of Paris has an extensive network of automated bike rental stations throughout the city. The service is called "Velib" and is very well accepted. Velib’s are everywhere these days when you are out and about.

Screenshot0014_2
Velib also has a mobile site where people can search for the nearest Velib station and can see how many bikes are available there. The picture on the left shows how this looks like in the browser. It’s a bit pathetic that in this day and age, the service is still based on WAP 1.0, but o.k., it’s better than nothing. The service in it’s current state is a bit difficult to use but it shows the potential for tomorrow: With mobile phones with built in GPS receivers becoming more common and powerful mobile web browsers with AJAX support can be easily enhanced in the future to locate the user, center the map around his position and show him the next bike rental station with the information he needs.

Velib should publish a JavaScript API to retrieve bike rental station positions and availability information. I am sure somebody in Paris will quickly come up with a mobile mashup that combines Velib and Google Maps.

Offline Web Applications on Mobile Devices – Part 2

This blog enty is part 2 of my thoughts on offline web applications on mobile devices. In case you haven’t seen part 1 and are interested in this topic, you might want to read part 1 first before continuing here.

When allowing web applications to store data offline and to access locally available information a number of issues arise that require special attention:

Data Synchronization

When storing data both in a local database in the network, the databases have to be synchronized once the mobile device regains network connection. Even for single user applications local and remote database synchronization is not straight forward since the user could have first used the application on the mobile device while it was offline to change some data and later on via the desktop that modified that data in the network. This means that when the mobile devices goes online it can not assume the data base in the network was not modified. Thus, the application needs an algorithm to compare the changes made in the database on the mobile device with the changes made in the database on the network and then modify the local and the network database accordingly. The same applies to multi user applications such as shared calendars.

Access to Local Information Outside the Browser Cache

A big advantage of mobile devices is the ability to support the user’s creativity at the point of inspiration. When pictures, videos, podcasts, blog entries etc. are created on the mobile device they can automatically be enriched with other information such as GPS location before being instantly sent to a picture and video sharing site, blogs, etc. Current web applications, however, do not have access to files and other local data beyond what they can write into the local web database themselves while the device is not connected to the web. In the future it is thus necessary to create an interface for web applications to enable them to access user created content and additional information such as location information. Access to local information needs to be dealt with carefully as it presents a security and privacy issue as will be further discussed below. From the technical point of view the big question is how web applications could gain local access in a generic way to make them interoperable over a wide variety of devices. Some devices might have more sources of information than others. As using proprietary APIs to access such information would make web applications device specific, a standard set of functions must be designed which are then translated on each device into proprietary operating system commands.

Security and Privacy Considerations

Allowing a web application to store data locally or to even access local information beyond the browser cache has a number of security and privacy implications which have to be considered when implementing such functionality.

The main issue with having a local application and data cache in the web browser is that JavaScript applications can use the local cache for user tracking. Advertisement platforms could use the local interface to write a JavaScript program that is included in all web pages of their advertising partners and that records from which page it has been invoked in the local cache. When the same JavaScript application is executed again from a different page it reports the last page back to the advertisement server which can then generate a user profile. As most users are unlikely to agree with such methods the user has to be informed that an application wants to store information locally and what kind of privacy issues this could bring with it. The user should then have the choice to allow or deny the use of local storage either temporarily or, in case the JavaScript application is trusted, permanently.
Access to local device information outside the browser cache is even more sensitive as malicious JavaScript applications could read private data of the user and send it to a server in the network. Therefore, the user has to be informed about the JavaScript application trying to access local data and give the user the possibility to allow or deny the request. It is then for the user to decide whether he trusts the application and thus allows access to local resources. Again, the user should have the choice to allow access temporarily or permanently as trusted applications should be able to access local data without further queries to the user once agreement has been given. Otherwise, usability of the application would suffer.

As always, comments are welcome!

Being a Mobile Network Operator For a Day

Plugs
When you go to a lot of meetings at other people’s locations you learn over time to take two indispensable things with you to stay connected: First, a multiple socket outlet with a long extension cable as there are usually only two power sockets for 20 people. This has the nice side effect that other people are usually more than grateful for your seemingly bright idea (see picture on the left). Second, I bring my own Internet access as either there is no Wifi or Ethernet cable available or a firewall blocks my IPsec connection back to the home network.

Ap
Last week, I hosted an internal meeting at one of our locations for a number of employees coming to town from all over the world. Usually, our Wifi network works quite well except, of course, when you need it. So the local Wifi went on strike as soon as our two day meeting started. But we are an R&D lab, so we have Wifi Access Points around that can take over in times of crisis. So I became a mobile network operator for a day.

Traffic1
The Linksys WRT-54 Access Point with OpenWRT has a nice graphical network traffic analysis tool which I used throughout the meetings to see how much the network was used. Most of the time there were around 15 people connected to the access point, mostly for keeping up to date with their eMail and browsing the web a bit (the split attention syndrome). Even in the breaks when usage increased I was quite surprised that the usage of the network rarely went beyond an average of 10-20%. In other words, most of the time 80-90% of the capacity was not used.

Traffic2
I would have guessed before the experiment that utilization would be much higher as people often report from conferences that Wifi access at some point comes to a standstill. Looks like my conference was too small and my visitors less demanding despite some YouTube videos being streamed during the breaks 🙂

On the left are some graphics which show how the network was used during high times. The time recorded on the graph is around 4 minutes.

Offline Web Applications on Mobile Devices

I am currently doing some research in which directions applications on mobile devices will develop in the future. The following post on offline web applications on mobile devices has been inspired by a blog entry on Ajit Jaokars OpenGardens blog.

On the desktop, many web browser based JavaScript applications exist today with well designed user interfaces and connectivity to services and databases on the web. Web based applications such as GMail (email reader), Bloglines (blog reader), Writley (text processor), etc. are now even taking over some of the functionality of locally installed programs.  On mobile devices, this trend is not yet wide spread. In my opinion, there are a number of reasons for this:

  • Web browsers on mobile devices need to become AJAX capable. This is well underway and in the mid-term its likely that most mobile devices will include such a browser. As JavaScript and the functions for asynchronous communication with the web server are standardized, developers can design applications which will work over a wide variety of mobile devices. This is an important key to success as services which only work on a limited number of mobile devices are unlikely to be successful as they will be unable to attract a sufficiently large user base.
  • Web applications need to work even if the network is not available. This is crucial for applications such as calendars, address books, etc., which have to be accessible at any time and any place.
  • Some applications should also be able to get access to the resources of the device which is important for applications used for uploading information such as pictures to the web or use the device’s built in GPS device to get the current position to be able to deliver information relevant to the user’s current location.

With the traditional server/browser approach these things are not possible. If the connection to the network is lost, web applications can not be loaded onto the device from the web server and user input can not be sent back to the web. A number of different initiatives have thus started to address these shortcomings.

Google Gears

Google’s approach is based on a web browser plugin which offers JavaScript applications on web pages an API to store pages locally. Furthermore, the plugin allows applications to store data locally. When the page is accessed when the device is not connected to the network, the local copy of the web page including the JavaScript program is used instead. The Gears plugin extends a web browser with the following functionality:

  • A local server which feeds the web browser with web pages which have been stored in the local cache in case the device is used in offline mode.
  • A relational database in which JavaScript applications on web pages can store information. To stay with the example above, a calendar application could hold a copy of the user’s calendar entries which are synchronized with the calendar entries in the web when the device is online and the application is used.
  • As synchronizing the local and remote data depository after going online could take considerable time it is important that such activities do not block the execution of the JavaScript application on the web page. Thus, the Gears API contains a ‘WorkerPool’ which allows executing JavaScript code in the background.

At the beginning of 2008, Google Gears is only available for desktop based browsers as it depends on a web browser plugin interface which is not yet available in any mobile browser. As the software is available as open source under a BSD license the way is free for mobile browser developers to include it in future versions of their products. While Google Gears enables web applications to run offline, there is not yet an extension which also allows web applications to use local resources (e.g. access to the file system, getting network information, GPS information, etc.).

Nokia S60 Web Widgets

Nokia’s vision for local web applications on mobile devices are widgets. Unlike Google Gear’s approach a widget is not executed inside the web browser. Instead, it just uses the web browser’s core as a runtime environment and otherwise looks like a native application. Widgets can even have their own icon that appears along local applications in application menus of the device. Not running in the user interface of the web browser but instead having the full screen available has a number of advantages. From the user’s point of view the program can be started and controlled just like local applications. When the widget is started by clicking on the icon in the program list, the web browser core is loaded and the JavaScript and HTML page which the JavaScript application can modify is shown on the screen just as a local application.

The first version of the web widgets packet does not offer local storage to applications which limits its use to times when the device is connected to the network in case data needs to be stored between invocations of the widget. Also, there are no interfaces at the moment to get other data from the device such as calendar entries, address book access, etc. Widgets do have access, however, to system information such as the current battery power level, network properties such as signal strength and network name, display light control, vibration control, speaker control, memory properties, etc.

HTML-5

For version 5 of the Hypertext Markup Language (HTML) the World Wide Web Consortium (W3C) is specifying tools to make web pages and embedded JavaScript applications available offline. The approach taken by the W3C is very similar to Google Gears and also features offline caching of web pages and a data repository for JavaScript applications to store data locally. There are two ways of storing data locally. For simple data structures, data can be stored in name/value pairs. For more complex data, JavaScript applications can use a SQL database with standardized functions to query, insert, change and delete data. The advantage over Google Gears is that once the standardization of HTML-5 is finalized, browsers can natively support offline web applications and a plugin like for Google Gears is no longer required.

That’s it for a first overview. In a future post I’ll take a look at data synchronization between the network database and the local cache, why and how some applications should be able to access local data beyond the cache and the security and privacy implications of local web applications.

As always, comments are welcome.