WirelessMoves

Several news portals report today (see here, here and here) that the first network operator has disabled MMS delivery temporarily due to most Android mobiles in the wild today being vulnerable to the Stagefright that can be exploited by sending videos by MMS and other means. Instead, an SMS is sent to customers with a link to view the MMS contents in a browser. Quite a responsible step and I wonder if or how many network operators will follow the example.

This announcement is quite something! I have never heard that a network operator has disabled one of its own services because of a mobile device vulnerability. As the articles linked-to above point out, it's no secret in the mobile industry that Whatsapp and other services are now much preferred over expensive MMS messaging, so perhaps little revenue is lost by this step.

In the announcement the carrier said that this is only a temporary solution until a fix has been found. That makes me wonder how that fix could look like and how long this temporary solution remains in place!? It's unlikely that the threat will go away anytime soon as it will take quite some time for devices to get patched as an Android OS patch is required. That means the update can't be delivered via Google's app store but needs to be incorporated by device manufacturers in their builds for each device. Good luck with that. Also, I guess there will be many devices that will never get updated as device manufacturers have already lost interest in providing OS updates for devices that are somewhat older.

Another solution I can imagine would be to put a "virus scanner" in place on the MMS server in the network to filter out malicious videos. But that will cost time and money not only initially but also to keep the signatures up to date. That makes me wonder if the service still makes enough money to justify such a measure!? On this account I wouldn't be surprised if Facebook, Google and others are already scrambling to put scanners in place to make sure videos that are put on their services by users do not contains malicious content.

No matter how I look at it, I can't help but feel that we've just reached a tipping point when it comes to mobile security. Google and device manufacturers need to do something radical and drastic NOW to make sure that future Android devices can be patched in a timely manner (i.e. in a matter of hours just like what is possible for desktop operating systems) rather than having to wait for device manufacturers to come up with new builds or, even worse, not being able to patch Android devices at all anymore due to lack of manufacturer support.

One thing I've been hoping for years now is for someone to come up with an easy to install remote smartphone help function to see and control the screen remotely. On the desktop VNC has existed in various flavors almost since the beginning of desktop GUIs. On all mobile operating systems, even on the open source Android, there is no good and simple solution. Yes, there are some solutions that have been started and abandoned again like the droid VNC server project but nothing that just works out of the box and across different devices and Android versions. I have to admit I'm a bit frustrated because I could use a remote help function at least once a week.

A couple of years ago I was extremely thankful to Google for bringing Wi-Fi tethering to the masses when it was still perceived as something "terrible" by most network operators. But for a remote screen implementation I personally can't count on Google because I'm sure that should they come up with such a thing they would put one of their servers between the smartphone and the helping hand. No thanks, I need something more direct, private and secure. But Android is open and I would accept something that requires a rooted phone and I can't but wonder why nobody has come up with a good, simple and interoperable solution so far!?

P.S. Cyanogen, hello!?

The vast majority of Internet traffic is still over IPv4 and when I look at all the different kinds of connectivity I use for connecting my PC and smartphone to the Internet, there isn't a single scenario in which I have a public IPv4 address for those devices. Instead, I am behind at least one Network Address Translation (NAT) gateway, that translates a private IPv4 address into another IPv4 address, either a public IPv4 or another private one in case several NATs are cascaded. While that usually works well, every now and then one of those NATs change their IP address on their WAN interface which creates trouble in some use cases.

Applications that use the TCP transport protocol quickly notice this as their TCP link gets broken by the process. Higher layers are notified that the TCP link is broken and apps can reestablish communication to their counterpart. Apps using UDP as a transport protocol, however, have a somewhat harder time. UDP keep-alive packets sent in one direction to keep NAT translations in place are not enough as they just end up in nirvana. Bi-directional UDP keep alive packets also end up in nirvana without the application on top ever being notified about it. The only chance they have is to implement a periodic keep-alive 'ping' and a timeout after which the connection is to be considered broken.

Recently I had to simulate such behavior and wondered how to best do that. Again a Raspberry Pi acting as a Wi-Fi access point, NAT and Ethernet backhaul served as a great tool. Three shell commands are enough to simulate an IP-address change on the WAN-interface:

Do a 'sudo nano /etc/dhcp/dhclient.conf' and insert the following line:

    send dhcp-requested-address 10.10.6.92;

The IP address needs to be replaced with an IP-address of the subnet of the WAN interface but different from the one currently used. Obviously that IP address must not be used by any other device on the WAN subnet which can be checked by pinging the IP address before changing the configuration file.

Next, disable the dhcp client on the WAN interface with

   dhclient -r -v

The interface itself remains up so Wireshark does not stop an ongoing trace but IP-connectivity is removed. If the scenario to be simulated requires a certain time before a new IP address is available, just pause before inputting the next command.

A new IP address can then be requested with

   dhclient -v eth0

The result returned by the command shows if the requested IP has been granted or if the DHCP server has assigned the previous IP address again or perhaps even an entirely different one. If the DHCP server has assigned the old IP address, changing the MAC address after disabling the dhcp client will probably help.

And that's all there is to it except for one 'little' thing: If the Raspberry Pi or other Linux device you perform these actions on are yet again behind another NAT, the server on the Internet will not see an IP address change but just a different TCP or UDP port for an incoming packet. So while in some scenarios the connection will still break there are potentially scenarios in which a connection can survive. One example is an ongoing conversation over UDP. If the NATs assign the same UDP port translations on all interfaces again, which can but does not necessarily have to happen and the first UDP packet is sent from the NATed network, the connection might just survive. I can imagine some TCP survival scenarios as well so don't assume but check carefully if the exercise produces the expected changes in IP address and port nubmers for your network setup.

Have fun!

For the last couple of years a number of companies have been trying to find a way to converge the operating system and user interfaces of mobile and desktop devices. Perhaps time is getting a bit scarce now as smartphone processors come pretty close to the computational power, memory size and graphics capabilities as full grown desktop PCs. Sure their screen and battery is smaller but at some point it will be trivial to interconnect them with a bigger screen, keyboard and mouse and ask them to be the 'desktop'. Perhaps we reach this point with tablets first? But what kind of operating system will run on it?

With almost the screen size of a small notebook the only things thet are missing in a tablet product we use today is a hardware keyboard and a mouse. Apple is getting closer and closer to this point with the latest Macbook 2015. Running a full iOS, it nevertheless is pretty much a tablet with a keyboard attached due to its thinness and use of only a single USB 3.1 connector. Unlike a tablet however, it runs full iOS. But the keyboard is attached to the screen and the graphical user interface is still geared towards keyboard and touchpad.

Microsoft is also on it's way with the Surface line of notebook / tablet hybrids, even though commercial success is nowhere to be seen yet. Their Surface notebooks / tablets are now also running a full Windows operating system on a tablet sized device with removable keyboard with an x86 processor, so that is perhaps even closer to a converged device than the Macbook desribed above. I don't like the Windows 8 style graphical user interface and closed source is not my piece of cake either but they are definitely innovating in this space.

The third player in the desktop/mobile space is Google with Android and Chromebooks. While I like the fact that Chrome OS runs on Linux, the idea that everything is in the Google cloud makes their vision of a combined mobile/desktop future not very appealing to me. I can imagine my data to be stored on my own cloud server at home but I'm not yet willing to give up the huge advantages of on-device data and application storage when it comes to speed, security and being able to get work done in places where Internet connectivity is not present or too slow.

So perhaps it's time now to get hold of a 'Surface' and install Ubuntu on it to see how usable the Unity graphical user interface or perhaps KDE or something else is on a tablet once keyboard and mouse are removed!?

<sarcasm on> I'm sure lots of people are looking forward these days to upgrade to Windows 10 <sarcasm off>. Personally, the only reason why I'm even writing about it is the new Wi-Fi Sense feature that has jumped over from Windows Phone to the desktop to freely share Wi-Fi passwords with your contacts in Outlook, Hotmail, Skype and Facebook. Great for convenience, bad for security, bad for me.

Bad for me because in the past I let friends access my Wi-Fi network at home. I'm sure I haven't changed my Wi-Fi password since because it's a pain to change it on all of my devices that use the network, especially printers and other devices that don't offer an easy way to change the password. But I guess I have to do it now because Windows PCs of friends with whom I've shared my password in the past that upgrade can now freely share it with their friends, i.e. people I don't even know, with a simple tick in a check box. Obviously, Microsoft get's to see and store it, too.

Fortunately it's not as bad as it sounds at first as users still have to tick a check box per Wi-Fi network they want to share credentials for. Ars Technica has a detailed description of how the feature works if you are interested in the details. Still, I think it's time for a password change at home.

Yes, I know, giving out my Wi-Fi password was never secure to begin with. This is why I have a guest Wi-Fi SSID and password for quite some time now that I can quickly switch-on and off as required. Another benefit of this solution is that I can change the SSID and/or the password every now and then so things don't get out of hand. This way even if friends decide to or accidentally share my guest Wi-Fi credentials with Microsoft and the world it's of little use to anyone as the guest Wi-Fi SSID is automatically shut down after a pre-configured time after the last user has left.

And that by the way also limits the damage done by those automatic 'backups' of private data to Google Servers that Android based devices perform every now and then.

This week, another network operator in Germany announced that they will start LTE data roaming on 1 August. For two reasons, however, the announcement is more than a little bit strange.

First, they are not only a year late to the game but they will only start with three foreign networks while their competition already have roaming agreements with several dozen networks around the globe. The second restriction is even weirder: LTE Roaming data speeds are limited to 1 Mbit/s and nobody knows what that is good for!? While my LTE data roaming speeds easily surpass 20 Mbit/s they want to limit their customers to 1/20 of that. No way this would work for me because I regularly use LTE data roaming for notebook tethering.

Hm, that makes me wonder if they are bundling a couple of old E-1 lines to connect to their roaming hub and are afraid of massive overload if customers want to use the technology as it was designed!? 😉 Sorry, an announcement like that needs to be ridiculed.