Google Smart Lock Working Properly After All

One of the features which Android offers, is called “Smart Lock”. It means that as soon as some trust condition is met – in my case, as long as I am at home – I can bypass the default unlock method, and just swipe to unlock my phone.

But there was a time, when I thought this feature was not working properly. This idea was due to a simple user error on my part.

When Android shows us its swipe-to-unlock screen, it has animated ripples of water seemingly flowing along it, and in the case of my phone, displays 3 small icons along the bottom. Two of those are features which I can generally use without unlocking the phone, while the one in the middle is just a ‘lock-icon’.

What I did not know until recently, was the fact that it is a mistake, if we try to drag that lock-icon in the middle away from itself, to unlock the phone. That exact motion is acknowledged by a growing, light semicircle which appears around the lock-icon, and acts to lock the phone.

In order to unlock this screen, we need to start at a random position – such as where the animated ripples show – and just swipe straight upward.

I guess that it was silly of me, not to know how to work the standard swipe-to-unlock screen of Android. But if I am going to make mistakes, those will be stupid ones. I think that any phone thief, would already know how this screen works…

And my Smart Lock feature was always ready and willing to work with me, even though I had actually disabled it at one point in time.

Dirk

 

Wake On LAN (WoL)

Some time ago, a hardware capability named “Wake On LAN”, or ‘WoL’ was explained to me, which was based on an Ethernet network. According to that explanation, a number of computers at a workplace could be powered down – shut down – but their Ethernet cards would still be receiving a trickle of current from their power supplies. And then, just before the workforce would show up to begin their day, their switches and routers would send out a so-called “Magic Packet”, which would cause all the computers to boot up, and then to be ready for the workforce when it arrives for work.

Well I was recently surprised – though pleasantly surprised – to find out that a homologous feature does after all exist for WiFi, which has also been referred to as Wake On LAN, or WoL, even though the WiFi version of it does not work exactly the same way. For our WiFi-connected phones and tablets, when they are in standby, their WiFi antennae are typically still powered up, and when those receive their magic packet, it wakes them up from standby.

This is a hardware capability, which also explains why such devices are really able to receive push notifications.

I had previously explained to my friends, that with Android or iOS, instead of each app listening forever on a port number for a push notification, this capability has been centralized into the Application Framework, as part of the O/S effectively. But this being centralized to one port number for the device, would still not have been completely enough to explain push notifications.

Well apparently, in the WiFi version of this feature, the magic packet is also sent to a specific port number, which means that it can wake up a device which is behind a firewall.

And then that way, cell phones on their broadband data instead of on WiFi, also retain their IP numbers, and can thus also receive push notifications easily.

Dirk

 

VPN Server Test Completed Today

Just this evening, I went to my neighborhood Tim Hortons, to order some food, but also to use their public WiFi hot-spot, in order to log in a session with the VPN server I have on my LAN, that uses the ‘OpenVPN’ protocol. This is a type of test which I perform periodically, just to make sure that the server does work, after certain upgrades. The test was a success.

But I would like to point out several things which this action does not imply.

In the world of today, many people pay money to rent a VPN server, the only purpose of which is to fool the geo-blocking of certain services offered in the USA. In this context, they may expect that to install ‘OpenVPN’ on their clients, will give them free access to a VPN.

This would be False.

The way I have OpenVPN set up on my LAN, I can use the compatible Android client, named “OpenVPN For Android”, to make my computers behave as though my tablet was physically on my LAN. From there, I can ping computers on my LAN. This could be useful to me if I need to access certain resources that specifically exist on my LAN here at home.

In general, I do not use this service to redirect any Internet traffic through my VPN, so that Internet traffic continues to flow directly from the tablet which is my client, through the WiFi that I have used separately, to gain access to my OpenVPN server.

Some people have suggested that I may be taking quite a chance with my data, by connecting to my VPN from within a WiFi hot-spot. But contrarily to what the name of this protocol may suggest to some minds, this protocol has robust encryption techniques in place, in addition to password challenges, which will not only prevent unauthorized access, but also prevent any data from being gleaned from the connection, in the event that the entire session might be monitored.

My main fear in this scenario tends to be, that certain hot-spot operators may not differentiate, between a person who connects to his VPN at home, and one who connects to a VPN across the border, simply because either type of session typically uses the same port numbers, only on different servers. If they did not differentiate, my access to any VPN might be blocked regardless. It was not blocked this evening.

There is an observation about Tim Horton WiFi however, which I may mention. I pinged another computer tonight, which was physically on my LAN. This represents a low-bandwidth scenario. The ping times were slower than before, averaging maybe 200ms. In the past I sometimes obtained ping times of 30-50ms. Yet, if I was to do the same thing from a non-public WiFi hot-spot, my ping times should also be back to normal…

Dirk

 

Android Permissions Control

One fact which I had written about before, was that Android differs from Linux, in that under Android, every installed app has its own username. Also, because different users installed a different set of apps in different order, the UID – an actual number – for any given username will be different from one device to the next. And then I also wrote, that a username belonging to a group or not so, can be used to manage access control, just like under Linux.

There is a reason for which things are not so simple with Android. Most Android apps are written in a language named “Dalvik”, the source code of which has syntax identical to “Java”, and which must be compiled into “Bytecode”. The bytecode in turn runs on a bytecode interpreter, which is also referred to as a Virtual Machine.

The reason for which this affects permissions, is because as far as the kernel can see, this VM itself runs under one username. This is similar to how a Java VM would run under one username. And so a much more complex security model is put in place by the VM itself, because presumably this VM’s username has far-reaching capabilities on the device.

The actual use of groups to control access under Android is simpler, and applies at first glance to processes which have been compiled with the ‘NDK’ – with the “Native Development Kit” – and which therefore run directly, say from C++ source code.

Further, the Dalvik VM is capable of reading the permissions of actual files, and is capable of applying its own security model, in a way that takes the permission bits into account, that have been assigned to the files by the Linux kernel. So for most purposes, the security model on the VM is more important than the actual permission bits, as assigned and implemented by the kernel, because most Android source code is effectively written in a Java-like language.

Dirk