Category: Uncategorized

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!

Until December 2014 I thought that the UMTS air interface was secure. After all, the air interface is much more complex than the GSM air interface and strong authentication and encryption is used. It felt good. And then, a few days before 31C3, news broke that security researches will demonstrate a way to passively intercept SMS messages sent over the UMTS air interface with cheap equipment if the attacker has access to the signaling network used by wireless networks, known as SS7 (Signaling System No. 7), anywhere in the world. And the scenario is only the tip of the iceberg as it turned out only a few days later.

Attacking UMTS Ciphering From The Inside

I never thought about such a scenario before but with the clues given in the article it only took me 5 minutes to figure out the details by having a closer look at the MAP (Mobile Application Part) specification in TS 3GPP TS 29.002. When a subscriber moves from one MSC area to another, the MSCs need to exchange subscriber information and chapter 8.1.4 details the Send Identification service which transfers, among other things, the current ciphering keys from one MSC to another. These ciphering keys can then be used to decrypt transmissions on the UMTS air interface to and from a particular subscriber. The presentation at 31C3 by Karsten Nohl of Security Research Labs a few days later then proved that my assumptions were correct. The slides can be found here and a video of the talk has been posted here.

From a psychological point I found this quick discovery quite interesting. While the message is necessary for proper mobility management in a network and I've known about it from my days as a core network programmer, it never crossed my mind before that this could be exploitable if such messages are routed across network and country borders. But when looking at this from a different angle it becomes immediately obvious. And it seems I was not the only one not to see this because it was reported that all four German cellular networks had no filters in place at network boundaries to prevent such queries. Fortunately, all four reacted quickly and put message filters in place to stop the abuse.

Re-routing Attacks

Unfortunately, the filter just stops this particular exploit. A further talk at 31C3 by Tobias Engel and a presentation by 'Positive Technologies' given earlier in 2014 at a conference in Moscow reveal several other possibilities to exploit the implicit trust between cellular networks to enable roaming between country borders. With access to the global SS7 network anywhere in the world an attacker has several ways to re-route a call to a subscriber somewhere else to record it and then forward it again to the destination. This can be done by sending fake USSD (Unstructured Supplementary Service Data) messages to the HLR (Home Location Register) to activate and deactivate immediate call forwarding. This way an incoming call can automatically be forwarded to a recording station. Once it arrives there the call forwarding is removed and another call is made from the recording station back to the subscriber. Another way described in the presentations linked above is to use the SS7 based CAMEL protocol to change the destination of a call during the establishment process without the need of changing the call forwarding settings in the HLR.

While call re-routing is probably most interesting for spy agencies for political and industrial espionage, researchers have also shown how it is possible redirect SMS messages by sending fake subscriber registration messages across international SS7 links. This way a mobile device is deregistered at its current location and seems to have traveled across international borders. Any incoming calls and SMS messages are thus re-routed to the attacker who can sit anywhere in the world. The subscriber doesn't notice the deregistration as his mobile device continues to show that it is connected to the network. This won't work for long as sooner or later the device will make a periodic location update at its current location or tries to access the Internet and as a consequence the fake registration is deleted. When timed correctly, the temporary redirection can be used for fraud. In combination with banking Trojans that collect banking website login PINs and the knowledge of a user's phone number a confirmation SMS for a transaction triggered by the fraudsters can be redirected into their lap without the user even noticing it. A scary scenario.

Ways To Stop It

The only good news is that these attacks are not passive as they leave traces in the logs of network operators. But that's about it then. In practice it is probably difficult but not impossible to get access to the international SS7 network. For intelligence 'services' around the world it should be no problem whatsoever. So what can be done?

• The first step has already been taken by some network operators by blocking requests for the current ciphering keys from outside their networks.

• Some of the re-routing attacks, e.g. changing call forwarding settings from abroad via USSD can be prevented by plausibility checks, i.e. the HLR or a box in front of it has to verify that the USSD message comes from the Mobile Switching Center to which the subscriber is currently attached to. To prevent spoofing of the sender's SS7 point code, a network operator's international SS7 gateway has to ensure that only messages with international point codes are allowed into the local network.

• Check CAMEL modification messages: The service logic in MSCs must ensure that only Service Control Points (SCPs) from a predefined list of Global Titles can be informed about call establishments and other operations.

• Encryption of national SS7 links: To prevent foreign intelligence services to tap SS7 links in other countries, all SS7 traffic between locations must be encrypted and integrity checked.

• Monitor changing call forwarding settings: Most people don't change their call forwarding settings regularly. I'm probably an exception. A box in the network could watch out for frequent and thus  suspicious call forwarding changes and warn the operator and subscriber.

• Plausibility check international requests for authentication material: Even after barring the exchange of the current ciphering key, networks can still request authentication and ciphering material for subscribers of other networks. This is the basis for international roaming but may also allows those with access to UMTS IMSI catchers to get valid keys. The only way to counter this is to check if an authentication vector request is likely to be valid. If a request comes in from abroad while the mobile just recently made a location update in the home country, it's unlikely that the request was valid. Exceptions are border areas to neighboring countries. That makes plausibility checks not impossible but quite complicated in practice.

• Check international registration requests: The same checks as described in the bullet point above have to be applied to registration requests to prevent enhanced re-routing attacks. As above, preventing such fraud is not impossible but not straight forward to implement in practice.

• Allow subscribers to toggle a "Home Network" lock: If bad comes to worse this would stop any kind of foreign attack if such a lock would block all requests for ciphering material, registrations, etc. etc. from international SS7 links. I'm sure a lot of politicians and high value espionage targets would sleep easier. I'm not sure if this is the same as just deactivating international roaming like it can be done already today… And by the way, such an approach is not novel. Some credit card companies, for example, restrict the use of their cards to countries in which EMV chip/pin authentication is used and require their customers to temporarily unlock their cards if they travel to parts of the world where the magnetic stripe is still used.

• Name, shame and ban: Networks from which illegal SS7 messages are sent should be made public so other network operators can react and also put counter measures in place. If I were a network operator I would also think about terminating my business with that network and blocking all traffic from there. Some examples made public would probably work wonders to convince network operators to keep their back yards clean.

This list is by no means complete and just a result from some initial thinking. I'm sure there is a lot more that can and should be done. Perhaps some of these things are already done by some network operators today but I have no insight into this so I can't say.

So far, nobody has spoken about how to compromise LTE security over international links. This is probably because international LTE roaming is not based on SS7 but on the IP based DIAMETER protocol. The issues are similar however, because the principle is the same: Cellular networks have to trust each other for international roaming to work.

And finally, it's important to understand that none of the SS7 issues discovered by researches and described above require to break any kind of ciphering, to exploit implementation flaws, generate stack overflows to insert malicious code or to apply social engineering to trick someone to do something. Instead they just make use of the protocol in ways it was never intended to be used. In other words, the only way to fix this is to move away from totally trusting external networks and put checks in place that detect and prevent such attacks. Now that things are in the open I guess the industry has some work set out for it to do.

2015 is going to be another interesting year in wireless in Germany as another spectrum auction will perhaps again significantly influence the wireless landscape in the center of Europe.

There's lots of different angles to look at this spectrum auction, including competitive aspects, how much of the spectrum that companies already use today they want to re-acquire, whether it will be a real auction or just an amicable get together now that only three network operators are left, what will be done with the auction result, i.e. reinvested in telecoms, and if so how, or whether the money is funneled into other channels like in the past, etc. etc.

But no, I don't want to look at any of these aspects. Instead, let's have a look at the 2015 spectrum auction from a technology point of view: In addition to re-auctioning spectrum assignments in currently used bands such as the 900 and 1800 MHz bands that expire in 2016, two additional bands will be part of the action as reported by Teltarif and Heise:

Digital Dividend 2 in 700 MHz

The first new band is comprised of 2×30 MHz blocks (one for the uplink and one for the downlink) in the 700 MHz region currently used for TV broadcasting. This part of the spectrum has to be freed up first as part of the "Digital Dividend II" program which foresees terrestrial TV broadcasting to move from DVB-T to the more efficient DVB-T2 standard. The two 30 MHz blocks are between 703 and 733 MHz and from 758 MHz to 788 MHz. That's a subset of the already standardized LTE band 28, which, according to Wikipedia, has been a result of the Asia Pacific Band Plan (APT). In other words it has the same size as the Digital Dividend band (LTE band 20) already used today in the 800 MHz band.

A First in 1400 MHz

The second new band is foreseen for downlink only use between 1452 to 1492 MHz, i.e. 40 MHz. That's a subset of LTE band 32 (1452 to 1496 MHz). As it is uni-directional, it must be used as part of an LTE Carrier Aggregation setup together with another bi-directional band.

And that's it as far as new spectrum is concerned. Making a chunk of uni-directional 40 MHz spectrum available shows how little spectrum there's still available in the area below 3 GHz. Anything above is unlikely to be of much use in a macro cell network setup (i.e. a cell site covering a radius of several hundred meters to a few kilometers).

But every MHz counts and it's going to be interesting to see how things develop in the months to come.

I like to have a plan B so I regularly backup my Owncloud document folder to an external storage device and, in addition, to another Owncloud installation running on a Raspberry Pi so I can active this instance should my main Owncloud installation ever fail while I'm not at home. So far, I've always copied over the complete document folder to the Raspi which takes quite a while as it contains several gigabytes of data. Recently, however, I decided to have a closer look at the rsync command and noticed that it would be ideal to speed up the process as it can compare source and destination and only copies the parts of files that have been modified. Here's the command I put together after reading a couple of "how to's" that exactly fits my needs:

rsync -avzh –rsync-path="sudo rsync" /media/owncloud-drive/data/ pi@192.168.42.3:/media/owncloud-drive/data/ –progress –delete

Looks a bit complicated but it's pretty much straight forward:

• -avzh are the default options to use rsync in "a" = archive mode which goes through the directory recursively and preserves permissions, time stamps and access rights. 'v' stands for verbose output, 'z' for compressing data before transmission, and 'h' for human readable format.

• –rsync-path is used to run the rsync instansce on the remote RaspberryPi with admin rights which are required to copy the owncloud folder that needs to be accessible from the "www-data" account that is used by the web server.

• /media/owncloud-drive/data/ is the path to the local owncloud data folder that is to be copied to the destination.

• pi@192.168.42.3:… is the account, IP address and path of the remote device to which the data shall be copied.

• –progress, as you might imagine gives more details while the command is running.

• –delete allows rsync to delete all files at the destination which no longer exist on the source.

One shouldn't be adventurous when it comes to backups but since this is still in the test phase I ran the rsync command with Apache being shut down on the target but not on the source server. So in theory Owncloud could write to the log or the sqlite database file just at the moment the modified part of the database file is copied over and thus corrupting the destination database file. I've ran the command many times over several days now, and so far I had no issues from not shutting down Owncloud on the source server during the process. Maybe I was just lucky so far or maybe it's no problem at all, I'm not sure yet. But I'll keep you posted.

Another year is drawing to a close and as in the years before I wondered what has happened during the year. And as always I was quite surprised when I went through my blog entries of the past 12 months about the amount. So here are my personal technology highlights of 2014:

LTE and Affordable Worldwide Internet access

Last year was the year when roaming in Europe finally became affordable. But that was nothing compared to what has happened in 2014. In July, I switched to a mobile contract that removed roaming charges for voice, data and SMS in Europe for 5 Euros extra a month. In addition, many network operators have now started to roll out LTE roaming and I had my first European and intercontinental LTE roaming experiences. And on top of that, my network operator of choice decided to apply the former EU data roaming rates to the rest of the world, thus enabling truly affordable global Internet access roaming. I've used it in China and the US during the year and it worked perfectly. On the technology side, I've also mused about data roaming costs from a technical point of view.

3rd Edition of my Book on Mobile Networks Gets Published

About 10 years ago the first edition of my book on mobile networks got published. Needless to say that over the years many things have changed and new technologies have appeared on the scene. I thus always kept updating the manuscript and 2014 saw the publication of the 3rd edition of 'From GSM to LTE-Advanced – An Introduction to Mobile Networks and Mobile Broadband'.

Network Function Virtualization

In the making for a number of years now, the standardization and discussion around Network Function Virtualization is taking on shape. Having used virtualization on the desktop for quite some time now to do things like locking up Windows in a virtual machine I decided it was time to write an NFV primer. You can find the result here.

CyanogenMod, Root Access and 'Smartphones are PCs now'

Last year came the end of Symbian for me and I've been struggling since then to get my privacy back, i.e. to make Android stop talking to Google and others all the time. A fist step to this goal was to switch to CyanogenMod which brought some disadvantages but opened up a whole new world for me. With CyanogenMod and root access, smartphones really started to feel like computers to me new and I wrote a long blog entry about the next revolution in computing based on those experiences. From a practical point of view I figured out how to stop my smartphone and other devices from contacting Google and advertisers all the time to regain my privacy and to bring pleasure back to web surfing on mobile. In September I automated the blocking list update process and put the details on Github so others could benefit as well.

Security and Privacy

Like last year, security and privacy have remained important topics for me, as Edward Snowden's revelations on the scope and depth of mass surveillance continues to baffle me. 'Raising The Shields' has been my motto since and I've put together a number of things to encrypt as much of my communication as possible. With a Raspberry Pi I've put together a security gateway for VNC remote screen sessions and to encrypt both legs of the connection by using SSH tunnels. Another Raspberry Pi and a Banana Pi for performance reasons have since been put into use as OpenVPN servers. And to encrypt all my Internet traffic when I'm in public places such as hotels, I've put together scripts and configuration files to configure a Raspberry Pi as an OpenVPN client and Wi-Fi access point. The scripts and configuration files are on Github for those of you with similar needs.

2014 has also been the year of massive security issues.  Heartbleed is the one that will probably be remembered best and I had a posts about whether my Raspberry servers were vulnerable and the extend of just how bad this discovery was and wondered why nobody discussed the NSA's denial that it didn't know about this and what this would mean if it was actually true.

Over summer break, I decided to have a closer look at how assisted GPS works and found out that SUPL, one of the protocols used by some mobile chipsets reaveals my identity and location to Google every time I fire up the GPS chip. For those of you who care about the details I had a blog posts with further technical details here and how to trace a SUPL request here. But even if assisted GPS is switched off, it's still not easy to hide your location, even if a VPN is used as described here.

I was probably not the only one who was shocked to hear that whoever was behind Truecrypt decided to abandon the project as I've been using the software on many devices. Some projects followed to review the source code and to see if someone else could continue to maintain it. I'm not sure how that turned out because I decided to switch to dm-crypt (details here and here) which is truly open source and, from what I can tell, peer reviewed.

Owncloud and How to Enable Everyone

Last year I started to use Owncloud to host my own 'cloud services' at home and this has given rise to a number of interesting thoughts and projects. In 2014, I migrated my Owncloud installation to a NUC for higher performance. One problem with Owncloud is that it requires quite a bit of technical knowledge to get going. In other words, it's something for the nerds as setting up Dynamic DNS, configuring port forwarding, getting an SSL certificate and struggling with Internet lines at home without public IP addresses is not everybody's cup of tea. So over the course of the year I put together the pieces of the puzzle and came up with an idea of how to 'home cloud enable' everyone to keep private data private.

Open Source – The Joy of Fixing It Yourself

2014 was also the year I got rid of Windows at home. All computing devices in the household are running on a Linux distribution now and Windows is banned into Virtual Machines and as an alternate OS on a single machine for those very few occasions for which a Windows running on bare metal is required. Over the year I have booted to Windows at home perhaps twice.

Open source is great because you can fix things yourself. To that end I've reported a number of Owncloud issues on their Github presence, I supplied code to extend the Selfoss RSS Server/Reader platform with new functionality I wanted to have and I set up two projects on my own on Github (The VPN Wi-Fi Access Point and the stuff required for privacy on CyanogenMod described above).

And finally on the programming side, open source has helped me a lot to better understand the fabrics of the web. As part of this I worked through a book about PHP and mySQL as sometimes books still trump online research and implemented a private database application with a web frontend. As this was so much fun I used my new knowledge to put together an automated system for testing the reliability of the Wi-Fi and cellular connectivity of mobile devices with a web based interface.

Fiber Connectivity

A 25 Mbit/s downlink and 5 Mbit/s uplink at home is not bad but once you've seen what a Fiber To The Home (FTTH) connection can do it seems to be slow indeed. When I benchmarked that 1 Gbit/s FTTH connection in Paris I got a sustained 260 Mbit/s in the downlink direction. Technical details and images of the installation can be found here. But while this is all nice, I wonder if fiber will become the new monopoly and if perhaps G.fast will be a remedy!? Time will tell.

From the Terabyte SSD to Vintage Computing

That 500 GB SSD I bought last year is still brand new but I managed to use all it's capacity only a year later. So I had to upgrade my notebook once again and have ended up with a 1 TB SSD. Again, I used the disruptive occasion to get rid of a couple of other limitations by creating a separate OS partition from a dm-crypted data partition which allows me to backup and restore the OS partition in a few minutes compared to the several hours required before.

Going back in time was equally exciting. At the beginning of the year I was in Silicon Valley and had some time at last to go to the Computer History Museum. Later in the year I also visited to the Heinz Nixdorf museum in Paderborn, Germany, which declares itself as the biggest computer museum in the world. And indeed, it is a museum not to be missed if one has an interest in vintage computing.

And last but not least: This year was the 10th anniversary of my first 3G mobile. It's been only 10 years but the mobile landscape has changed dramatically during this time.

I can hardly believe all of this happened in 2014. After all, the year felt so short…