WirelessMoves

Looking through various log files for suspicious activities in my home cloud is part of my security routine. Recently, I found some interesting entries in the Apache web server log file on the server I run Owncloud and Selfoss, my RSS server. Every 7 days I get a couple of http requests from China. What!?

O.k. I am in China every now and then but not every 7 days. So since it's my private server and runs on a non-standard tcp port to keep crawlers and script kiddies away that is quite suspicious. Digging a bit deeper and having had a look at the requests before and after the requests coming from China I finally found the reason for those requests: On my mobile devices I use “Opera Mobile” for web browsing which includes accessing my RSS feed aggregated by Selfoss. For quick access I've added a shortcut to the speed dial screen. On this screen, shortcuts are represented with a thumbnail of the web page. It seems the thumbnails are updated every 7 days but the thumbnail is not created by the smartphone itself but by a server on the Opera backend that tries to fetch the webpage, creates a new thumbnail, which is then downloaded to the phone. And it seems that this server is in China as the requests are always coinciding with me accessing my Selfoss RSS web page via Opera from my smartphone. How interesting! The picture on the left shows the temporal correlation.

In my case the web page is http digest password protected so there is no real thumbnail. And that's a good thing because if there were that would mean that Opera would send my password to their backend. But they don't so that's at least something.

And just to make sure the IP address reported by the tool being in China really is in China, I ran a traceroute:

[…]

 5  80.157.129.186 (80.157.129.186)  32.988 ms  33.312 ms  33.885 ms
 6  202.97.58.53 (202.97.58.53)  233.826 ms  223.837 ms  223.892 ms
 7  202.97.53.241 (202.97.53.241)  222.172 ms  219.059 ms  240.293 ms
 8  202.97.53.109 (202.97.53.109)  243.943 ms  249.146 ms  250.505 ms
 9  * * *
10  bj141-130-74.bjtelecom.net (219.141.130.74)  301.600 ms * *
11  bj141-147-82.bjtelecom.net (219.141.147.82)  320.768 ms bj141-131-162.bjtelecom.net (219.141.131.162)  320.731 ms bj141-147-82.bjtelecom.net (219.141.147.82)  320.721 ms
12  242.88.202.1.static.bjtelecom.net (1.202.88.242)  306.327 ms  320.606 ms  320.585 ms
13  211.151.224.194 (211.151.224.194)  325.090 ms 211.151.224.106 (211.151.224.106)  221.285 ms  223.845 ms
14  59.151.96.162 (59.151.96.162)  228.515 ms  268.986 ms  270.306 ms
15  59.151.99.90 (59.151.99.90)  270.648 ms  273.096 ms  275.106 ms
16  59.151.106.247 (59.151.106.247)  274.853 ms  287.711 ms  292.621 ms

Hop 5 is the last leg of the route to the destination IP address in Europe before the packets hop into a transit link to China. The delay of hop 6 already shows the other end of the tunnel is quite far away and a Whois lookup reveals that this is a transit link of China Telecom. Hop 16 is the IP address from which Opera's requests have originated and Whois reveals that the IP address is assigned to 21ViaNet in Beijing.

After the recent terrorist attacks in Paris a lot of high government officials and even prime ministers are calling for new laws to allow them to decrypt any kind of communication if it is deemed necessary. That makes me wonder if we are headed for another crypto war!?

I find it highly disconcerting that governments of liberal and democratic countries are seriously considering to outlaw private communication, a basic human right in a feeble attempt to improve security. Perhaps this thinking still comes from the days when wire tapping was the main means to intercept communication. Still today, a court order can get you a tap on anyone's phone line or mobile phone in the country and conversations can be recorded and listened to in real time. It was a different world then. No mobile computers, dumb 'terminals', you had to use the fixed infrastructure that was in place, encryption systems for the masses were none existent. From that point of view I can understand the push to get the same means for other forms of communication that have sprung up in recent years, too. But the world has changed dramatically over the past decades. Networks and services have split, dump 'terminals' for fixed line networks with voice only capabilities have become smartphones and strong encryption is used everywhere and is the foundation for our global economy today. Applying the principle of wire taping to other forms of communication would effectively spell the end of free and democratic societies as we know them today and would have a profound impact on everybody's lives, whether, even for those who claim that they have nothing to hide. So here are a couple of points why attempts to increase security by requiring a second key for governments is hoplessly useless and has become impossible to implement:

Classic Wire Tapping And Crypto Phones

To stay with the classic wire tapping example there's nothing to stop people from using crypto-phones today to encrypt a phone conversation. This is very different from 30 years ago when such technology was simply not available to everyone. Government officials have a need for this today to keep their conversations private, people working for companies around the world have a need for this today because they have a need to keep sensitive information private. As a consequence, people like you and me who are no less important and who have the same rights should therefore also have the right to encrypt their phone calls without anyone being able to tap in somewhere in between, not in the least because privacy is a basic human right. The proposals above would mean that such crypto-systems have to have a second key that the government can get access to. So who produces crypto equipment and software and how do you ensure no foreign governments and other entities eventually get the key? That makes me actually wonder which government should get the key? And what if I travel abroad with my mobile phone, should the government of the country I travel to get the key as well? If not, how could you stop to foreigners in a country to call each other and use cryptography which has a second key for their home country but not for the country they have traveled to?

Instant Messaging

Let's venture a bit further out to instant messaging. Let's say Google, Apple, Microsoft, Facebook and all others are suddenly required by law to give governments (plural!) access to private conversations and to prevent people from using end to end encryption. But how would they stop people from using a further layer of encryption over their government pseudo-crypto? They can't. Governments could outlaw such overlays but that again would violate my human rights for privacy.

Next example: Today, I'm using a private instant messaging server at home and end to end encryption for communication with close relatives and friends. With a crypto-intercept law in place, would I have to give a second key from all clients to the government? Or would there be an exception because I'm not a commercial service provider? And if so, what keeps the bad guys from just not being a commercial service provider themselves? And further along those lines what keeps anyone from using an instant messaging service for which the server is located in a country that is not on good terms with the government of the country you currently reside in? Does that mean that ISPs will be required to block their users from using such services? And how exactly should that work, clever protocols would just look for a way around.

Secure HTTP

Another example: I have a web server at home and access it using https. On my devices I use Certificate Patrol to ensure that a certificate change required for interception is indicated and communication is aborted. Would crypto-intercept mean that programs like Certificate Patrol are outlawed? And if so what keeps me from installing it anyway? As it's a passive method to ensure privacy there's not even a way to detect it from the outside. Or would such a law require me to give my private SSL key to the government? And what if I travel from Germany to Austria, would that mean that I had to send my private SSL key to the Austrian government as well? Doing so would require an encrypted connection. But then the German government needs to listen in. So would the Austrian government thus have a second key for the German government and for all other governments of nations from which people come to visit Austria? and what about the transit countries over which the encrypted communication flow is transported? It's getting absurd pretty quickly

Secure Shell

Yet another example: To administer my servers at home I use the Secure Shell Protocol (SSH) like millions of other system administrators. It uses perfect forward secrecy and certificates for the server and the client and strong public/private keys. Unlike secure http where man in the middle attacks with government signed certificates are possible, SSH is bullet proof in this respect. Does that mean that I have to give the government a second key whenever I set up a new server or change my certificates? What happens when I travel to France or Russia? Do I have to give those governments my keys in advance? Or maybe a law should be in place to require ISPs to block all ciphered communication over country borders for which no second key is available to all the governments over who's territories the data packets are sent!? Good luck working out a mechanism for that.

The only way to enforce this is to ban the use of any crypto-system that does not contain a second key for the government of the country you currently reside in. That will make traveling with computing equipment across national borders pretty difficult to impossible unless you come up with a system where governments around the world can get a key for your communication. Does anyone really want that!? Would it even be possible?

Would 2-nd Keys To Intercept Traffic of Large Internet Companies Change Anything For The Bad Guy?

These are just a couple of thoughts that show how ridiculous it would be to require big Internet companies to give second keys to governments. The overhead to play this game with 200 countries is ridiculous, the potential for fraud enormous and instead of 1.000.000.000 ways to communicate securely, bad guys would be left with only 999.999.999.

Less Is More

In the end, the only way is to tap the bad guys at the source before data is encrypted. That is not trivial but it shouldn't be anyway as otherwise governments would just spy on anyone. After the Snowden revelations there is little if any doubt on that. When looking at terrorist incidents I can't find a single one after which it is discovered that the terrorists were already known by the authorities but manpower was missing to have a closer look. There is no need to ban encryption to get even more data, police can't even handle the data they already have access to. So in my opinion they should even be required to collect less data rather than more for their own sake.

These days I seem to experience Youtube issues more and more frequently when I'm at home, especially in the evenings. Sometimes, some videos just don't stream very well while others work o.k. It seems this is related to the content distribution server Youtube selects for my location or the link to it which seem to be overloaded from time to time. The proof in point is that I can get around the issue by opening a VPN tunnel to a VPN gateway located in another country. When doing that, the video that I just had problems with just plays fine after re-opening the browser and going back to the video that I had problems with just seconds before. While this work around is certainly far from ideal, I've just found another use for my VPN.

I'm always a bit shocked when I hear people saying that “Google and others track you anyway on your smartphone and there is nothing that can be done about it”. I sense a certain frustration not only on the side of the person who's made the statement. But I obviously beg to differ. As this comes up quite frequently I decided to put together a blog post that I can then refer to with the things that I do on my Android based device to keep my private data as private as possible.

The Three Cornerstones to Privacy

In essence, my efforts to keep my private data private is based on three cornerstones:

• As few apps on the device as possible that communicate with servers on the Internet without my consent.

• Allowing access to private information such as location, calendar entries, the address book, etc. to specific apps while blocking access for all others by default.

• Preventing communication of apps with servers on the Internet that I would like to use. Amazon's Kindle reader app is a prime example. It's a good app for reading books but if left on it's own it's far too chatty for my taste.

In some cases, implementing these cornerstones in practice is straight forward while other things require a more technical approach. The rest of this blog entry now looks at how I implement these cornerstones in practice.

CyanogenMod

For a number of blocking and monitoring approaches described below it's necessary to get root rights on the device. This is nothing bad and there's a difference between rooting and jail breaking as I described in this blog post. One way to conveniently get root rights is to install an alternative Android OS on the device. CyanogenMod is my distribution of choice as it is mainstream enough for good support and stability and has no Google apps installed by default. As a user, I can then decide to install only those Google apps I require such as the Google Play store. Apart from the app store, the Play Services framework and the Google keyboard there's little else Google specific I have installed. Sure, there's additional stuff in the basic OS that wants to talk to Google servers but these parts can also be silenced as shown below.

Privacy Guard

By default, CyanogenMod is shipped with the 'Privacy Guard' feature that allows to restrict access on a per app basis to lots of different sources of private information such as the calender and address book, the GPS receiver, etc. So even if an app requires access to the address book to install properly, access can still be removed later on. A good example is the app of the German railway company which wants to have access to my address book and my location so it can help me to find nearby stations easier. It's a noble goal but I don't want to it to have access to my private data. With Privacy Guard restricting access the app still works but only sees an empty address book, doesn't get a position fix when it asks for it without crashing or acting up in strange ways. In practice I've configured Privacy Guard to ask me when newly installed apps want to access any kind of private information so I can either allow or deny it temporarily or permanently so I won't be bothered by requests anymore in the future.  Also, I went through the list of already installed apps and removed access rights for many of them to information sources I don't want those apps to have access to.

Using an Alternative Web Browser

Most people just use Google's default Chrome browser on an Android device and are thus freely sharing everything they do on the web from their mobile device with Google. And yet is is so easy to install an alternative browser such as Opera or Firefox. Personally I prefer Opera even though it is not open source. But at least it does not talk to Google all the time and it has a great text-reflow feature that I personally miss in all other alternatives I tried so far.

Using an Alternative Search Engine

Most web browsers, even alternative one's use Google for web searches by default, giving Google yet another way to collect private information about users.  But it's easy to use other search engines such as DuckDuckGo, Yahoo/Bing etc., I'm still giving away private information through my search queries but at least it ends up in other hands.

Blocking Unwanted Communication

Despite using Privacy Guard, alternative web browsers and search engines there's still a lot of communication going on between apps and servers of Google, Amazon and others. The only way to control these short of not installing them is to block communication to those servers. A way to conveniently do this is to block communication to them via the 'hosts' file. Modifying the 'hosts' file requires a terminal program and root access, both of which come packaged with CyanogenMod. I've put my hosts file and scripts to activate and deactivate blocking on Github so you don't have to start from scratch. Have a look at this blog post for details. With this in place there's very little traffic going to servers I don't like it to go and further down in the post I describe how I occasionally check that this is still the case.

GPS-only Location

While it is admittedly convenient to send information about Wi-Fi networks at my location and the current Cell ID to Google's location services for a quick location fix it also allows Google to track me. Yes, they say the data is processed anonymously but I still don't like it. And I don't have to because GPS-only location provides a quick location fix as well these days. Unfortunately, some devices use Google's Secure User Plane Location (SUPL) server and include my subscriber id (IMSI) and location information in the request. Many devices, however, use other services to help the GPS chip to find the satellites more quickly which seem to be less nosy. For details have a look at the the blog posts here and here.

Owncloud for Synchronization

Naturally I don't want to share my address book and calendar with Google, Microsoft or any other big company for that matter. As a consequence I only used a non-synchronized calendar on my PC and an address book on a smartphone. And then Owncloud came along and made me make peace with 'the cloud', as my cloud services are at home. Since having an Owncloud server at home I enjoy calendar and address book synchronization between all my devices without the need to share my data with a cloud service provider.

Open Street Maps

Yes, and you might have guessed by now I also don't want Google to know where I'm going. I thus do not use Google Maps for street or car navigation. Instead I use Open Street Maps for Android (Osmand). It's a great app and I used it for car navigation for the past two years now. Better still, all maps are on the device so my smartphone doesn't have to frequently download maps data from the web while driving. The downside is that I don't have traffic jam notifications but I'm willing to trade that for my privacy.

Mobile eMail

Needless to say that Google is not my email provider either. Instead I use a medium sized German company for the purpose and Thunderbird on the PC. On my Android smartphone I use the open source K9 email program to manage my emails. It's forked from Google's email program and works pretty much the same way, except it's not talking to Google of course.

Music and Videos On My Mobile

Again, I prefer the open source VLC player to other pre-installed products, even to CyanogenMod's Apollo. It plays just about any audio and video format I throw at it without the need to talk to anyone on the web.

Seeing is Believing

And finally, it's important to check what kind of unwanted communication is still going on in the background after having taken the steps above. This can then be used to update the 'hosts' file or take some further measures. Tracing IP traffic to and from the device can be done in several ways. One way is to use a Wi-Fi access point and connect it to the Internet via the Ethernet socket of a PC which is configured for Internet sharing. With Wireshark on the PC, all traffic from the smartphone via the Wi-Fi access point can then be monitored. Another approach is to use a Raspberry Pi as a Wi-Fi access point and then use tcpdump running on the Pi and Wireshark running on a PC that is also connected to the network to inspect the phone's data exchange. Another interestion option is to run tcpdump directly on the smartphone and inspect the resulting dump file with Wireshark on a PC. This way, one can even collect IP packets that are transferred over the cellular interface.

Final Words

Purists will argue now that even when all measures are taken things are far from perfect. I tend to agree but there far less of my private data being extracted from my smartphone without my consent or, at least, without my awareness.

When it comes to spectrum, current cellular networks that are designed well can still keep up with the ever rising demand for bandwidth. In addition, not all of the spectrum below 3 GHz that has been assigned to cellular operators is used so capacity can be further increased by adding additional carriers per base station for a few years. In addition, there is still spectrum below 3 GHz that could be assigned to cellular networks in the future but compared to what's already assigned it is not that much. So sooner or later, alternatives are required to keep up should bandwidth demands continue to grow at current rates of 50-80% per year.

Small Cells to Escape The Bandwidth Crunch On High Frequencies

There are a couple of options to escape the dilemma: Smaller cell sizes and spectrum in higher frequency bands. Smaller cell sizes and the use of licensed spectrum allow a higher re-use factor and hence increase the overall capacity of the network. There is also no way around very small cells when licensed or unlicensed spectrum beyond 3 GHz are considered for future use as the higher signal attenuation limit practical cell sizes to a few tens of meters from the cell's center. So one way or another, going beyond current network capacity by an order of magnitude requires smaller cells. How that can be done economically is a matter of debate and I won't dwell on this particular point in this blog post.

What I would like to take a closer look at today, however, is the potential use of the license free 5 GHz band which is pretty much exclusively used by Wi-Fi today. So while the Wi-Fi camp is probably not very happy about the LTE camp considering this band, it is a logical evolution of the LTE ecosystem  and the 300+ MHz of available spectrum in the band at zero cost is quite irresistible as well.

A number of industry players are doing quite a lot to push the idea in the media at the moment. Even 3GPP published an article back in September 2014 on their web site stating that LTE in the license free 5 GHz band, referred to as LAA-LTE (License Assisted Access LTE), is  seen as a major RAN feature for 3GPP Release 13. [http://www.3gpp.org/news-events/3gpp-news/1628-rel13].

What is License Assisted Access?

So why this strange name “License Assisted Access”? The 3GPP Study Item on the topic (see links below) is quite clear that the aim, at least initially, is not to have independent LTE cells in the 5 GHz band. Instead, a primary cell transmitting on a carrier in a licensed chunk of spectrum a network operator has paid for is complemented with an additional LTE carrier in the unlicensed 5 GHz band. The Study Item even goes as far as saying that in a first instance, the 5 GHz band shall only be used for downlink transmission, i.e. as a Secondary Cell (SCell) in a classic Carrier Aggregation (CA) configuration. All signaling and control information is only sent on the Primary Cell (PCell) which is operated in a licensed band. I'm not quite sure why that limitation has, at least for now, been put into place but it sounds like there is a fair amount of politics involved to appease some players with a vested interest in Wi-Fi. What such a setup would of course do is to keep a cellular signaling link in place all the time so an ongoing data transfer can quickly be pulled away from a LAA-LTE carrier back to the primary carrier that potentially covers a larger area when the signal deteriorates.

And this immediately brings us into the domain of the various HetNet (Heterogeneous Network) and CoMP (Coordinated Multipoint) features that have been specified in recent 3GPP releases but are not used in practice so far. So perhaps at the beginning small eNodeBs devices may transmit both the PCell and SCell parts. But I am sure at some point the industry might get more daring and also think about a split between the PCell being transmitted in licensed spectrum from an overlay macro cell while the SCell using unlicensed spectrum is transmitted from a small cell. An interesting aspect of such a scenario would be that a small cell that only uses unlicensed spectrum is easy to set-up as the site does not have to be registered as a cellular transmitter. After all, it's only using unlicensed spectrum and has to adhere to the same transmit power limitations and regulations as Wi-Fi access points.

Dealing with Interference and Being a Fair Player

Obviously as someone operating a Wi-Fi access point in the 5 GHz band at home for high bandwidth media streaming I'd be very unhappy if a nearby LAA-LTE cell would significantly interfere with my transmissions. Fortunately there is enough space in the 5 GHz band, at least until 160 MHz Wi-Fi channels defined by 802.11ac replace the 40 Mhz and 80 MHz channels used by 802.11n and 802.11ac products today, so networks can go out of each other's way. LAA-LTE carriers will be limited to 20 MHz channels but Carrier Aggregation (CA) would allow to bundle several channels in addition to the PCell channel in a licensed band. Today, 2×20 MHz Carrier Aggregation in licensed bands are used in practice and 3×20 MHz Carrier Aggregation is just around the corner. By the time LAA-LTE might be ready for deployment, perhaps in the 2018-2019 timeframe, it might be even more.

Also, the Study Item promises to have a close look at how a “Listen before Transmit” scheme can be implemented for the LAA-LTE cell so it can detect Wi-Fi networks in the same spectrum and either change to a different section of the band, reduce it's transmit power or to coordinate transmissions with the Wi-Fi networks it detects. The promise is that a LAA-LTE carrier would no more interfere with a Wi-Fi network than other Wi-Fi networks in the area. A nice promise but a heavily loaded nearby Wi-Fi network would interfere quite a lot with my own Wi-Fi network.

It's going to be interesting to see how this particular part will be standardized. Today, an LTE cell does not look out for interference and uses the licensed spectrum assigned to a carrier whenever it likes. Wi-Fi on the other hand has an interference and collision detection scheme with backoff times and retries. So if you will, LTE without any enhancements is not really a fair player when it comes to competing for the same spectrum with other transmitters in real time because it did not have to compete for access to a channel so far. Also a LAA-LTE cell has to take care that it doesn't interfere with a LAA-LTE cell in 5 GHz band of another network operator that has also decided to put a small cell in the area.

Why Compare Spectral Efficiency of LTE vs. WiFi?

Sure, one could use Wi-Fi access as part of a cellular network but there have been so many approaches to include Wi-Fi access into a cellular network infrastructure that have failed that it's not worth to think about yet another flavor. What makes LTE so attractive over Wi-Fi for cellular use is not its spectral efficiency but that LTE is a cellular technology while Wi-Fi is a hotspot technology without mobility in mind. So while Wi-Fi is great for homes, hotels and offices for stationary or nomadic Internet use, it can't compete with LTE in full mobility scenarios in which it is important to have automatic subscriber authentication, integrated backhaul and seamless mobility to and from larger macro cells. Also, Wi-Fi is not specified 3GPP so they have little influence over potential enhancements required to fully integrate it into an LTE network. As I said above, it's been tried before…

Timing

To make sure I still remember how it this activity started here are some dates. From what I can tell, the Study Item started in December 2014 and Ericsson envisages the study to be finished by mid-2015 with the specification to be finished mid 2016. Deployment usually takes 2-3 years after that.

Background Reading

And here are a number of great links to the details:

• Felllow blogger Zahid Ghadialy already picked up on the topic back in June 2014. Zahid also links to his blog posts on LTE-U (-Unlicensed) that show activity around using LTE in the 5 GHz unlicensed band as far back to December 2013.

• And here's a link to the report from the 3GPP workshop on 'LTE in Unlicensed Spectrum” held in June 2014 in Sophia Antipolis.

• The LAA-LTE Study Item description from September 2014, RAN#65, Edinburgh.

• And the final Study Item Description as approved in December 2014 in the 3GPP RAN#66 plenary meeting.

• The latest document is TR 36.889, created in December 2014 at RAN#66 that will be updated continuously to hold the result of the study item.

After updating an app recently on my CyanogenMod based Android device that requires GPS information I was surprised and admittedly also a bit annoyed that it wouldn't access the GPS receiver anymore. When looking at the release notes I saw that the app changed from Android's legacy GPS API to the Google Play GPS API but still offered an option in the settings to change back to the legacy API. And indeed, after switching to the legacy API everything worked again. But why wouldn't the Google Play location API work on my device?

It took me a while to figure it out but I finally realized that half a year ago I activated CyanogenMod's Privacy Guard features for the Google Play services app as at the time I had no idea what the app that appears in the app overview actually does and thus saw no need to let it have access to my private data. As it kept asking for permissions I set Privacy Guard to just block requests without user notifications. And since I use alternatives to most Google apps I haven't had a problem with that setting until today.

On the left are two screenshots that show CyanogenMod's Privacy Guard in action. The first one shows the check box to activate the protection mechanism on a per app basis. The second screenshot shows the top of the list of access permissions that can be granted on a per app basis either always, on request or never.

So while my experience was a bit unpleasant, the positive side is that is showed that Privacy Guard does what it is supposed to do.

When recently contemplating about the use of frequency bands for LTE in different parts of the world I realized that there have been different approaches: In the US, network operators opted for deploying LTE in the 700 MHz area and have only recently started to use higher bands such as the 1700/2100 MHz band for LTE services. In Europe most carriers started with the 1800/2600 MHz band but quickly also opted for the 800 MHz band to push nation wide coverage. When I was in China recently, I noticed that I could only trace deployments in the 1900+ MHz range (e.g. TDD bands 39-41 as described on Wikipedia) but nothing below that. In retrospect, I find it quite surprising that they haven't started their rollout on lower frequencies to get a large footprint in their not so small country.

Whenever I'm in the UK I can't help the feeling that the mobile networks are far away from the coverage and performance I've come to expect in Germany and Austria. But maybe it's just me?

No it's not as P3, who test the German, Austrian and Swiss networks for the 'Connect' magazine now also has results for the UK. For details see the PDF that can be download here. Looks like much hunch was indeed correct. While the winner in the UK would barely make it to the 3rd place in Germany, it would be the worst network by a wide margin in Austria and Switzerland. Datarates on average across the board are only a fraction what they are in other countries and voice call setup success rates are several percentage points away from those in other countries. Doesn't sound like much at first perhaps, but take it from me, network engineers are fighting for tenths of a percent in this area.

The report comes to the conclusion that there is a lot of room for improvement but at least the latest technology is already used, so if there is a will there is a way. That makes one wonder why the result is so different in the UK!? Many people attribute it to the cut throat pricing in the UK. While I'm convinced that this is part of the answer, it can't be the whole story as prices in Austria have been at very low levels for years now as well (take my recent experience in Austria as a good example) but network performance of all remaining network operators there is still excellent.

These days I often wished I could disable GSM in my phone and live with the occasional coverage hole rather than falling back to GSM for a while. I acutally have quite a number of reasons for that:

– HD-voice calls drop to narrow band when the network performs a handover to GSM as there is little support for HD-voice on 2G so far.

– Networks seem to be pretty cautious during voice calls and perform 3G to GSM handovers while there is still sufficient UMTS coverage. During lengthy phone calls this means that Internet connectivity is often needlesly lost, or, in the case of DTM, becomes unbearably slow for most things.

– Most network operators still use GSM A5/1 which is insecure. And even if they use better encryption, lots of organisations are using IMSI catchers and other equipment these days and can easily perform man in the middle attacks. Latest example: The government quarter in Norway.

So unless I'm really in territory which is only covered by GSM (or GSM and LTE), I really want to switch GSM off in my phone. While many 2G/3G devices still had the option to lock the device to 3G, GSM/UMTS/LTE devices usually don't have such an option anymore. Why confuse the user…!? But there's an app for that! Have a look at the "Network" app. It doesn't seem to work on all Android devices but on my Samsung S4 running CyanogenMod it works well indeed. The app is open source so I had a quick look and was surprised that it pretty much just invokes an internal configuration screen that is otherwise hidden.

Which is the best network in a country? There's several ways to answer this questions. A simple answer is that whichever network serves a customer best at a certain location wins at that location. But people are always on the move so in addition to a network serving particular areas individual subscribers are most of their time (i.e. their homes and offices) it is also important to have good coverage along their daily commute routes and also at the places where they spend their vacation, where they go and watch a game, etc. And now the answer to the question has become a lot more difficult. Network tests that published in German news papers are a good indications of how well network cover a country and the 2014 'Connect' magazine test has again undertaken to analyze the mobile networks in Germany, Austria and Switzerland. The report is available in English as a PDF file here and it makes for interesting reading.

Here are some of my findings:

• When comparing this year's results for Germany with those of last year the values have remained pretty much on the same level.

• The other networks in Germany have improved their performance quite significantly compared to last year.

• While the winner in Germany can certainly be proud of its performance, the winners in Austria and Switzerland still surpass it easily. Downlink data transmission rates for a 10 MB file in the Austrian A1 network are on average still significantly higher than in Germany.

• In my blog entry to last year's Connect test I hoped they would also include train tips in their measurements. To my pleasant surprise they have done so and conclude that Switzerland is a travelers dream when it comes to connectivity while especially Germany lacks behind. Time to catch up because I am well aware that the good coverage along the railway line I use a lot is an exception rather than the norm. So network operators in Germany, go have a look how they have done it in Switzerland and do the same!