Category: Uncategorized

If you are a frequent reader of this blog you are probably aware that I prefer to keep my personal data close to myself. I don't want my personal address book, calendar, etc. etc. with Google or anyone else in the cloud, I don't want anyone collecting location information, anonymously or not without my consent and I don't want my devices to frequently call the mother ship. In this day and age, that's quite a challenge with iOS and Android sending information back into the cloud if the settings are left unchanged. So I was wondering how this data collection works in practice today and how much can be prevented from going out.

To have a closer look at what's going on I set-up a test environment with my Android 2.2 based phone connected to the Internet via Wi-Fi. The Wi-Fi access point was not directly connected to the Internet, however, but instead to the Ethernet port of a notebook that had Internet connection sharing enabled via its own Wi-Fi interface and a second Wi-Fi access point. This way, Wireshark can be used to trace the communication between the mobile device and the rest of the world. To see how Android interacts with Google and the rest of the world and how this can be scaled down I tested three scenarios:

• A device fully configured with a Google account, but calendar and address book synchronization disabled. Most people won't even deactivate this synchronization but I figured that's where most people who prefer to keep their data to themselves would start.
• As above but the Google account inaccessible due to a change of the password.
• After a factory reset without a Google account configured.

Lets take a look at the first scenario:

When the device is switched on, the first thing it does is to connect to synchronize the clock with an NTP time server (north-america.pool.ntp.org). Next, it retrieves GPS ephemeris information (xtra1.gpsonextra.net). This is interesting since gpsonextra.net is a domain registed by Qualcomm (and not Google), the maker of the radio chipset of the device.

After that, the device registers with Google (android.clients.google.com). For the interchange of most information, SSL is used so it's not possible to see what kind of data is interchanged inside the encrypted channel.

If registration with Google was successful the device then registers with Google Talk (mtalk.google.com) as Google Talk starts automatically in the background. This even happens when I configure Google Talk not to log me in automatically. I should add that I never registered to use Google Talk so I guess that comes as part of the Android/Google account.

And finally, the device starts talking to another time synchronization service (time-nw.nist.gov). Since this doesn't happen when I set the date and time to be configured manually, this interaction is probably there to check and correct the Android date and time. Again, this is not a Google service, NIST is the National (US) Institute for Standards and Technology. From that I infer that the NTP interaction above might be for the Qualcomm GPS calibration and not for Android itself.

All these interactions take place in the first few seconds after Internet connectivity has been established. After that, the device remains quiet until an app is started that interacts with a server on the network.

I wasn't able to trace an interaction with the Google location server that is reported to scan for WiFi SSIDs and Cell-IDs on a regular basis if this is not disabled in the configuration. This is most likely because my setup was stationary so the device was not able to collect information.

Put together, there is quite some interaction going on with the default settings. As mentioned above, many things can be disabled in the configuration. In a follow-up post or two I'll have a look at what can be prevented from going out and how that limits the use of the device.

Just in case you every now and then come cross Absolute Radio Frequency Channel Numbers (ARFCNs) and can't tell just from looking at them which band and frequency they represent, here's some interactive help:

• An ARFCN Calculator for GSM
• And one for UMTS and LTE

Very helpful!

After the general introduction to the Eclipse programming environment in part 1 and the basic concepts of object orientation and how it is used in Android in part 2, this part now finally takes a look how the theory looks like in practice. The application I had in mind since the beginning of this series is about exploring the network information such as cell-ids, signal strength and other data that Android provides to apps via its Application Programming Interface (API). In the following I'll show an extract of the code. I'll publish the source of the full app once it's a bit more polished.

As described in the previous post, Android apps use an event driven execution approach. When the app is started by the user, Android loads the app into memory and then jumps to the "onCreate" method. The following code snippet shows the beginning of the onCreate method of my app.

    /* Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
       
        /* If saved variable exist from last run still exist, recover them */
        if (savedInstanceState != null) {
        […]
        }

As I want to do my own things when the app starts, the onCreate method is "overridden". This means that while the original input and output parameters of the method are used in my app so Android can call the method in a defined way, the code in the method itself is unique for my application. In some cases it makes sense to not only have individual functionality in overridden methods but to also execute the code of the original method. This is done in the first line of the method by calling "super.onCreate".

The onCreate method receives a parameter that references data that the app has saved while it was last executed. This way, the app can populate all necessary variables at startup so it can continue from its previous state as if nothing had happened. This is quite helpful as Android closes an app automatically for various reasons such as, for example, when the system runs out of memory. An app is also closed and then automatically reopened when the user rotates the device and the screen orientation changes, something that happens quite frequently. So in my app I use this reference to populate a number of variables, such as the number of cell and location area changes that have occurred before (not shown in the code snippet above).

Once the variables are initialized, my onCreate method puts a number of things in place to get access to the network information. What I am interested in are mainly the cell-id, the location area code, the signal strength and when one of these change. On a machine that only runs a single program, a loop could be used to periodically check if these parameters have changed and then display them on the screen. In practice, however, this would not work as Android is a multitasking operating system so a single program must not lock up the device by running in a loop. Therefore, apps are event driven, i.e. a handler method is called when something happens. The app then performs an action such as updating the display and then goes back to sleep until another event happens and the handler is called again. So the way to get to the network status information I am interested in and to be informed about changes is to create a listener class with listener methods that Android calls when certain cellular network events such as signal strength changes occur. This is done with the following code:

     /* Get a handle to the telephony manager service and install a listener */
     MyListener = new MyPhoneStateListener();
     Tel        = (TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE);
     Tel.listen(MyListener, PhoneStateListener.LISTEN_SIGNAL_STRENGTHS);

In the first line I instantiate an object from a class that I have defined further down in my app, the "MyPhoneStateListener" class. In the second line a reference is retrieved to the service object that manages the cellular network connectivity. In Android, this object is called the Telephony_Service, which is, from my point of view, a bit misleading. In the third line of the code, I then install my listener object as a listener of the telephony system service. This way, whenever the signal strength or other properties of the cellular network connectivity changes, the app is automatically notified and can then perform appropriate actions such as displaying the updated signal strength, cell-id and other information on the screen.

I'll describe the details on how that is done in the next post.

Today I read an article on the video quality of Facetime and Skype on an iPad2 here (sorry, article is in German). For both, the author came to the conclusion that the video quality is quite bad compared to Skype on a PC. So I wonder why this is so!? Perhaps it has something to do with the available processing power? I can observe similar things on my netbook where Skype video resolution and quality is far behind what I get on my fully-fledged notebook, despite the processor almost running at 100%. While things are probably not going to change on my Atom based netbook with a weak GPU, I wonder if the graphics GPUs built into mobile devices will be able to help in the near future with encoding and decoding the combined real time audio and video stream? I think it's quite an application. Let's see what Google has to say when they release their own video calling application on Android devices soon.

While TMN doesn't let me use their 3G network with my German SIM card as reported in an earlier post, they do offer SIM cards for Internet access which are interesting for occasional use or travelers in the country for a couple of days. For the details on the offer see here. While the throughput in their network is quite o.k. and in the range of 3 MBit/s, their network has some compatibility issues with my 3G dongles.

I don't see such issues often anymore but TMN is one of those networks that still seem to have a strange RAN software version running that make my 3G dongles get stuck every now and then when an RRC state change occurs. Sometimes the connection recovers after a minute or so, sometimes I have to reset the connection entirely. The only thing that helps is a constant ping to keep the RRC connection in Cell-DCH.

TMN, you might want to run a compatibility check against some mainstream UMTS hardware not necessarily sold in Taiwan…

After the general introduction to the programming environment used for Android App development, the second part of this series now focuses on two major concepts every Android App is based on. This is the basis for the details I’ll then describe about what my experimental app does and how.

The first concept of every Android App is that it is programmed in an object oriented language, namely Java. The core of object orientation can be described in two parts:

First, object orientation means that every line of code of an app is part of a class. On the highest level of abstraction, every app has at least one class and one method in the class that contains the code. This method is called when the app is started by the user. That method then creates what the user sees, i.e. it arranges text, buttons and other things on the display. If things start to get complicated a good approach is to put parts of the code into other methods which are then called by the main method. These methods then do their specific work and then return to the original method with a result that can be further processed.

The question that arises at this point is how Android knows which method to call when the App is launched. This can be answered by looking at the second idea of object orientation. Classes are a kind of blueprint if you will, and to make them come alive, they have to be instantiated. Think of the abstract term “car” as an example and what it represents. Your own (physical) car is an instantiation of the abstract term car. There can be several instances of a car, like for example, your car and my car. In object orientation, an instance is called an object. And to bring the three words together: An object is an instance of a class. What Android does with object orientation is describing the basic principles of how an app is supposed to work and defines the names and parameters of the methods that are called by the OS when specific things happen.

When the app is started, a specific method of an object is called. To make this approach useful the app uses the method definition, i.e. how the method looks to the outside but defines what is inside the method itself. This is called “overriding”. So if there are two apps running they both have the same method that is called by the OS when the app is launched. The content of that method, however, is defined by the programmer of each app.

The method that is called when the app is started is only one of many that are already contained in the basic app class and the application programmer is free to either use methods and variables as they are or override them and do their own things with it. What remains the same in all apps are the method names and the parameters the method exchanges with the external word. Thus, there is a uniform way for the OS to interact with an app as will be discussed in the next paragraph.

Object orientation is a means to an end. How the app interacts with the world is a different matter. For that purpose, the OS needs to provide an Application Programming Interface, an API. Apple’s iOS also offers an object oriented interface to programming but the API is quite different to that of Android. If you want to display an “OK” button on the screen for example, an object of the type “button” is instantiated from the button class. The text displayed on the button and many other things are then defined by the app by calling methods of that object that then do their job inside the class to bring the button to live.

The second major concept of Android app programming is call back methods. Whenever something happens that the app should become aware of, such as for example the user clicking on a button on the screen, the user pressing a hardware button, the app being sent to the background because the user starts another app, data arriving from the network for the app, etc., a callback method is called by the OS. But how can the OS know which method of the app to call? If the callback method is part of the general app class described above then there is nothing special to do because the callback methods are predefined and the programmer can simply override the existing methods for the different events. Most elements a user interacts with such as buttons for example are not part of the general Android app class. As described above, the user instantiates a button object from the button class and then the app object contains a button object. To be informed about the user clicking on the button, the programmer needs to define a method in the app class to receive the event. A reference to that method is then given to the button object. When the user then clicks on the button, the button object calls the given method.

Most apps that interact with the user are fully call-back controlled. When the app starts, everything is put on the screen and callback methods are put in place. Then, while nothing more happens for the moment, no further processing power is needed for the app and no code is executed. Only once the user interacts with the app by, for example, clicking on a button, a callback method is called. The callback method can then perform an action that is supposed to happen when the button is clicked, e.g. a calculation is made and an output is made to the screen, and then go back to sleep until a new event arrives.

And finally, in addition to call-back methods, an app can also spawn background threads for actions that are continuously performed without user interaction or for actions that take a long time to complete. A separate execution thread has to be used for this so the main thread with the callback methods can be called by the OS at any time the user interacts with the app.

There we go, so much for the theory. In part 3, I’ll put the stuff described above into practice.

The Verizon Thunderbolt manufactured by HTC is one of the early CDMA/LTE mobile devices on the market. An interesting question in this regard is whether it has a SIM card or not. Remember, CDMA devices usually do not have a SIM card. But LTE is a 3GPP technology just like GSM and UMTS where SIM cards are part of every device. So what about the Thunderbolt which includes both technology branches!? I would have speculated it doesn't have one. Why bother, Verizon has its own LTE band so the device will only run on Verizon's network!?

But strangely enough, the Thunderbolt does have a SIM card as shown in this Youtube video. While showing the SIM card the reviewer mentions that CDMA service is still available when the SIM card is removed. In other words, the SIM is only used for the LTE part of the device.

Very interesting indeed.

The Comodo SSL hack last month has shown quite dramatically that SSL is prone to man-in-the-middle attack if you live or use SSL protected websites and services in places that make it easy for attackers to spy-on and divert IP packets. The way the attack works is that the data traffic to an SSL protected site is redirected to another server that then poses as the original server by sending a fraudulent SSL certificate. Out of the box, web browsers today don't indicate this to the user if the fraudulent SSL certificate was issued by a trusted but compromised certificate authority. For the technical details, see the excellent article on Ars Technica.

So is there anything that can be done to protect yourself against it? Two things come to mind:

First, whenever in a non trusted part of the Internet, a VPN tunnel can be established to an endpoint that lies somewhere where a man-in-the-middle has no access to. Many VPNs use certificates, too but since they don't rely on certificate authorities, man-in-the-middle attacks with bogous certificates won't work. The only solution for an attacker is to block VPNs from being established, and that the user notices immediately.

The second way to detect against potential fraudulent SSL certificates is to be informed if a different certificate is presented to the web browser for a website than at a previous visit to the same site. There are valid reasons for this such as the old certificate being close to its expiry date but such certificate changes are very rate. The issue here is that web browsers do not show such a certificate change. For Firefox, however, there are add-ons that do just this. An easy and straight forward one is Certificate Patrol.

The problem with both solutions is that the ordinary user without a technical background is unlikely to use either one.

On mobile platforms, using a VPN is not quite as straight forward, as keep-alive packets will drain the battery very quickly. Let's at least hope Firefox mobile and other mobile browsers get a similar add-on soon. However, that still leaves data transfers vulnerable from other apps such as email programs that use SSL to potect SMTP, POP3 and IMAP connections as well as apps that use HTTPS for data exchange.

I agree with Ars Technica, the security architecture of the Internet needs a serious overhaul.

As expressed in a previous post I'm quite happy about the improvements of Firefox 4 even at the expense of not being able to run a few add-on's which have not yet been upgraded to run in this version. After a bit of research, however, I found out that what keeps add-on's from installing in FF 4 is just the highest supported version information in the add-on. However, that can be changed easily. And here's how:

Download the add-on to the desktop with a right-click and then "save as" instead of trying to install it. You should then have an .xpi file. Rename it to .zip, because that's basically what it is and open it. You'll find a directory structure in which root there are two files, one of them being called "install.rdf". Open it with a text editor and modify the following line to say "4.0":

<em:maxVersion>4.0</em:maxVersion>

Then save the file and make sure it ends up in the .zip file again. Next, rename .zip back to .xpi and open the file in Firefox. This will start the add-on installer. And that's it. Of course there is no guarantee the add-on will work flawlessly as there is always a chance it uses features that were changed or removed between versions. But at least for the add-on I tried this was not the case and things work flawlessly.

I've recently been in Taiwan for a couple of days and obviously I had to check out the local networks here. The first thing I noticed is that Taiwan Mobile (TWM) doesn't let my German SIM card roam on their 3G network. I get a nice and clean mm reject cause 15 (no suitable cells in this location area) together with a gmm reject cause 9 (MS identity can't be derived from the network) so the mobile gives up on 3G and re-selects to GSM. How interesting, haven't seen that anywhere in the world yet. Either there was not 2G and 3G roaming agreement at  all or I could roam in a 3G network of a network operator if it was available. O.k. no roaming business from me then for TWM, Chunghwa's 3G networks has no problem with me 🙂 And I guess other smartphone users will just do the same when coming to Taiwan when they experience this. Not good for TWM…