Phones Show Chat 347 Notes on Smartphone, Mobile and IT Security

I recently had the pleasure of being a guest on Steve Litchfield and Ted Salmon's Phones Show Chat podcast for episode 347, which was published on 19th June 2016. I've been a regular guest on the podcast over the years, and I've worked in the IT information security industry for 13 years (you can find me here and here for more details) which is probably why Steve and Ted asked me to discuss the topic in detail during the show.

We covered a lot of ground around mobile and IT security, with a lot of terminology and acronyms, so this blog post is designed to be a companion or reference to the podcast episode.

Let's start with some terminology:

• Vulnerability. The bug, hole or weakness in the software or operating system, usual unintentional, sometimes maliciously inserted (aka the backdoor). This can lead to the ability to, for example, execute code or escalate privileges (obtain root or administrator rights) either locally on the device, or even more scary, remotely from afar. When there is a way to use the vulnerability to do such a thing, we have an...
• Exploit. This is taking advantage of the vulnerability to mount a successful attack. A vulnerability can be known, and there may not necessarily be an exploit in the wild. Once there is a working exploit, we get even more concerned about a vulnerability, as before that point, threat is only theoretical.
• Patching. This is basically updating software or operating systems, and should be done regularly. It will ensure that you receive fixes developed for known vulnerabilities. In the mobile world, this will come through your OEM/carrier for the phone OS itself, and the app store should be the mechanism for keeping apps up-to-date.
• Zero Day. This refers to the scenario where a vulnerability exists but has not been publicly disclosed to the vendor. This is dangerous because the vulnerability could be abused and exploited by attackers, but if the developers don't know about it, they can't write and distribute a patch or update to close the hole. Zero day vulnerabilities with working exploits, especially for highly used systems like Windows, Android and iOS, can trade hands for hundreds of thousands of dollars on the 'dark web'. This ties in with...
• Responsible disclosure. Where if you find a vulnerability, you should inform the developers privately, so they can fix the hole or weakness in the system. Not sell it on the dark web. Also, should you choose to publicise the vulnerability first, you give attackers a window of opportunity to exploit the vulnerability before the developers have had chance to fix and update the software. Publicise your great work finding the vulnerability after the fix has been available for some time.
• Bug bounties. Companies will give money to people who find vulnerabilities in their products, systems and services and disclose them responsibly. This even includes The Pentagon! In the last year, Google paid out more than $500,000 in these types of rewards. This type of scheme hopes to make hackers disclose responsibly rather than trade on the 'dark web'.
• CVE (Common Vulnerabilities and Exposures). This is the industry standard library of vulnerabilities, and gives us a uniform and standardised way to refer to vulnerabilities in precise language, rather than using common language which can get mangled, abbreviated, or otherwise abused or confused. Some vulnerabilities are so serious that the industry also gives them nicknames, like Heartbleed, Shellshock, and most recently Badlock. Sometimes these are justified to get publicity so we all make sure we patch our systems. Other times it is research organisation trying to publicise themselves.
• CVSS (Common Vulnerability Scoring System). This it the industry standard way of rating the severity of a vulnerability. It uses factors like the vector used (is it local and I have to get on the system first, or can I perform an attack remotely), complexity of the potential exploit, authentication required, and impact to the CIA of data (confidentiality, integrity, availability).

At the end of day, security is about minimising risk to an acceptable level, and this is no different with our smartphones. Risk is classically defined as "impact x probability". The impact of the thing happening could be anything from an app crashing, to your whole phone and digital identity being stolen or abused. The probability of the thing happening depends on how easy it is for the attacker. Many attacks require users to be in one of 3 scenarios: installing apps from 3rd party app stores, to have rooted or jailbroken your device, or they require the attacker to be between your phone and the Internet, to have somehow got inside the flow of the network traffic (called "man in the middle", or MiTM). Classic MiTM is achieved with the public wifi scenario, where you think you are connecting to a safe wifi provided by a venue, but you are actually connecting to a wifi network created someone with a wifi pineapple or similar, and they're going to snoop into your data and try to attack you. Seriously, don't use public wifi unless you really need to, you just can't trust it.

These three scenarios (3rd party app stores, root/jailbreak, MiTM) are for most normal users, and even you technically savvy PSC listeners, quite unlikely. This is why my main conclusion on the podcast was that yes, it is shame that many Android phones are behind on OS updates and security updates/patches; it would be better if they weren't, but the risk to users is low. This is because whilst the impact or an attack could be very high, the probability is low, so referring the impact x probability calculation, the inference is that the risk is low.

It gets more interesting when we have vulnerabilities with higher probability...

• Stagefright (a collection of at least 8 individual vulnerabilities, each with their own CVE number) made lots of news, partly because one exploit involved simply sending an MMS to an Android device, which by default will retrieve the multimedia content referred to in the message, and then execute code and escalate privileges. You don't need to use 3rd party app stores, be rooted, or have a MiTM.
• XcodeGhost also made lots of news, based on the potential risk. A modified version of Xcode, the development kit for Apple apps, had been distributed in the Far East, and developers were using that version instead of downloading it from Apple, because it was quicker to download from the Internet than from Apple's servers in USA, so the theory went. This modified Xcode was then inserting malware into apps constructed with the development kit. Again, no 3rd party app store required, no jailbreak required, no MiTM required.

These two issues show examples where the probability is higher, principally because the user does not need to do something silly or out of their way to make the device more vulnerable. If impact is high and probability is high, suddenly that's a big risk. However, these are the exception when you look through all the mobile-related headlines about security issues or potential for attacks.

It might be easier for me to see through the headlines because I work in IT security, but if you read some of the following headlines, they sound very serious! I've listed each one along with the source of the headlines (generally IT security companies publishing things they've found, to flex their muscles publicly or show they have great threat research capability in order to help win business from enterprise organisations) and the methodology needed, to show that there's little here to be massively worried about for 99.9% of users...

• "87% of Android devices insecure" (link)
• Press release for research org, most need 3rd party app stores
• "New type of auto-rooting Android adware is nearly impossible to remove" (link)
• Security company research, 3rd party app store
• "Devastating Vulnerability Affects 66 Percent of Android Phones" (link)
• Security company research, 3rd party app store
• "Critical Vulnerability Plagues 60% of Android Devices" (link)
• Security company research, requires root
• "More than a Billion Snapdragon-based Android Phones Vulnerable to Hacking" (link/link)
• Security company research, 3rd party app store
• “Android Installer Hijacking estimated to impact 49.5 percent of all current Android users" (link)
• Security company research, 3rd party app store

Some 'news stories' are worse than others. Take this analysis of one such news story: “Our Symantec pals wax poetic for a whopping 750 words before mentioning a teensy, weensy asterisk to all of this: The malicious app is not found on Google Play and may be downloaded from third-party app stores, forums, or torrent sites. Users who have Google Play installed are protected from this app by Verify Apps even when downloading it outside of Google Play."

Here's a tongue in cheek summary from a well-known blogger in the IT security industry, he's worth subscribing to on YouTube as his videos are very entertaining... https://www.youtube.com/watch?v=W5gdAxAGRyo

Here's a summary and some closing thoughts and recommendations for mobile and IT security:

• Software will always have vulnerabilities, software engineering is not 100% science (unlike some other engineering disciplines)
• Remember, enterprises (£Ms of budget) are getting successfuly attacked, the attackers are very clever. However, mobile phones have a much smaller "attack surface" than enterprises with 1000s of Windows desktop PCs, so the odds or more in our faviour when considering smartphones alone
• Best practices: never re-use passwords, use a password manager if it makes it easier; never open attachments unless you need to or were 100% expecting the attachment form someone; only use 1st party app stores; always accept updates for the OS and apps; avoid public wifi where possible.
• Don’t confuse vulnerability with exploit. This might help you wade through the nonsense and sensationalist headlines.
• Be annoyed that Android has a big problem with getting updates to users (through OEMs, carriers and many other obstacles) but also realise that you are far more likely to be exploited through your PC or laptop through things like malvertising via Flash, ransomware via attachments
• You're also more likely to have digital accounts compromised through the services themselves getting hacked, like LinkedIn for example. By the way, did I mention...
• Don't re-use passwords!
• And please uninstall Flash on all your PCs and laptops as soon as possible, thank you!

DIY Sony Xperia Z1 Compact Refurbishment

Somehow, on 29th and 30th of October 2015, I managed to crack the screens of two phones in two successive days.

• First, my primary device at the time, the Sony Z3 Compact. Not only did the screen crack, but the digitiser failed too, I couldn't even unlock the device. I moved to an old backup device, the Sony Z1 Compact.
• A day later, I cracked the screen on the Z1 Compact! I was clearing out some dirt from the earpiece with the pointed end of a safety pin. Innocuous! Same result, cracked screen and the digitiser failed so I was unable to unlock the device.

Unlucky? Careless? Either way, the devices had not been subject to any unusual conditions, heat or cold. It's not really surprising that they failed in the same way given they were made by the same manufacturer, but plenty of phone screens crack and leave the digitiser operational, giving you a 'grace period' to get a replacement sorted! I must also add that these phones between them have had around 3 years of daily use, but the digitisers still seem fragile in my opinion.

This all happened 4 days after I was a guest on the Phones Show Chat podcast, where I was complementing the Sony Compact range in general, and confirming I was really looking forward to the Z5 Compact! Timing...

Following a successful Nexus 4 screen replacement last year, and yet-to-be-blogged iPhone 5 screen replacement a few months later, I confidently ordered replacement parts to fix both phones. Here's the Z1 Compact screen replacement.

WARNING: This is not a "how to", should not be mistaken for step-by-step guide, and contains very mediocre photography...

A broken screen and knackered digitiser too:

The screen and digitiser came as a single unit, but did not include the adhesive, so I ended up ordering this separately which set me back a few days:

Removal of the old broken screen is as simple as applying heat (YouTube videos will say use a heat gun, I find a hair dryer works fine), then lifting the screen with plastic tools. The one supplied here looks suspiciously like a guitar plectrum:

Here you can see Sony's factory-fitted screen protector getting in the way; peel this off then get on with removing the actual screen:

Here you can see the adhesive clinging on as the screen is lifted from the chassis:

Having disconnected it, the old screen lies next to the chassis. It's best to remove and clean up as much of the old adhesive as possible, to ensure maximum effectiveness of the new assembly:

Attaching the new screen and doing a power-on and touch test before is always a good idea before fully sealing it to the phone...success:

Having peeled away the film on one side of the adhesive, you can see where it will line-up inside the chassis, around the front-facing camera and earpiece:

Adhesive applied to the chassis, now peel off the blue film, then connect and place the new screen into the chassis:

All done! There is one more step advised, which is to either place the device in a clamp, or between heavy books, to ensure the adhesive gets to work properly. I did the latter, overnight, and it has worked perfectly:

From a stint being lent to a less-then-careful family member, the back of the Z1 Compact was pretty knackered as well, so I'd also ordered a new back cover. You'll find straight replacements made of glass, but also polycarbonate plastic back options too, which I opted for due to cost and durability.

Here's the old beaten-up back cover:

Same as the front of the device, heat up and pry the back cover from the chassis, then remove all the old adhesive and clean up the surfaces:

Then place the adhesive and the back cover onto the chassis. As with the front screen, some pressure from a clamp or heavy books for a few hours helps the adhesive get to work properly:

The total cost was £32, and 50 minutes of my own time to do the whole job, including the screen and the back cover. It was nowhere near as complex at the Nexus 4 or iPhone screen replacements; no screws, no removing components to gain access to remove the screen or back cover, just heating up to loosen old adhesive, and put new adhesive and new parts onto the chassis!


Photos taken with Nokia Lumia 930, a long-term loan courtesy of Steve Litchfield.

Android Updates with New Permissions

Permissions, the system by which apps declare which hardware or special functions they wish to use, are getting a huge overhaul in the next version of Android, codenamed 'M'. Full details can be found here, with a slightly more palatable version here. This may or may not make developers more aware of the impact of the APIs they use, declare, and how users view, care or don't care about how apps use the hardware and special functions of their Android devices. Certainly a recent published vulnerability within Stagefright (an Android component) has given Android security the unwanted spotlight yet again, so both enterprise and home users alike may be getting more wary, we can only hope. I wrote about the need for a better security patching system for Android 15 months ago, and nothing has changed, it is still a problem given the Stagefright vulnerability.

However, with the current system of permissions declaration in play for a number of months yet before 'M' is released, and perhaps even longer given the slow roll-out of new versions of Android across manufacture and carrier variants, here's some examples of how permissions should and shouldn't be dealt with! Android users will know that in some app updates, developers add features which require them to use extra permissions, and these are displayed to the user at update time.

Case 1

Here's an example from a voicemail app, which for some reason now wants extra permissions from no less than 9 different categories:

When developers publish app updates, they are encouraged to give proper release notes, explaining what has changed in the new version. Here is the accompanying text:

They seem like mainly fixes, improvements to existing features, and that's about it. So why all the new permissions? Why should I be happy, as a user, to suddenly allow this app to get much more of the content and functionality within my device? I contacted the developer, and the response below seems to suggest they were forced into declaring all these permissions just to add badge support for the app's icon in the various launchers.

"Unfortunately we had to add them in order to set the badge counters but they are ALL related to that and are specific to different launchers from various manufacturers and third parties."

This may or may not seem appropriate to you. most apps asking for further permissions are usually legitimate, and sometimes Android will put developers in a corner with certain APIs and permission. However, it would have been far better to include reference to this in the release notes.

Case 2

Here is an altogether better example. This is a password management app, which itself was in the news for a breach last month, but takes a different approach. Here's the app update, and the new permissions it wants to declare:

Not as many as the voicemail app, granted, but still permissions I might be interested in if the privacy of my location is very important to me. Let's see what the release notes say:

A full list of new features, with new permissions called out where they are needed. Much better, more transparent, and the users understands why they are required. Furthermore, for extra credit there is a link at the bottom which follows through to their website, where every single permission used by the app is described in detail, not just the new ones.

 

Now, if I didn't want the app to use the new permissions, I only have one choice; don't install the update. This becomes tricky if I want other new features of fixes, as a user I can't be granular. However, as previously described, the new version of Android, 'M', is due to make significant improvements to the granular control and to the user experience of being notified that apps are using certain hardware or software functions.

And finally...

Whilst we're on the topic of app updates, a special mention has to go to Shifty Jelly for their Pocket Casts release notes. They do the job of describing new features and permissions required, but also include some great humour at the same time, always amusing!

DIY Nexus 4 Refurbishment

At the time of writing my full-time device, for work and play combined, is a Moto G. There's nothing much to tempt me away at present, given my usual caveats about "phone-sized phones" and wanting decent value for money. My better half dropped her old Nexus 4, several times, until the digitiser finally gave up and she inherited my unloved Z1 Compact. Whilst I wait for my next phone to be announced (Moto X2? Moto G2?) I decided to refurbish the Nexus 4 myself, and here's how it went...

WARNING: This is not a "how to", should not be mistaken for step-by-step guide, and contains very mediocre photography...

I had nothing to loose. The back had been cracked and smashed for a while before the final accident which took out the screen glass and digitiser, leaving the touch screen completely dead. The phone was as good as useless, so I couldn't really make it less functional with my average DIY skills!

For less than £40 I was able to source a replacement screen/digitiser unit and a back glass panel from eBay. I opted for just the glass panel for fixing the back of the Nexus 4, although you can get the whole back case unit including (or excluding if you wish) the coils for wireless charging and NFC.

The screen/digitiser unit included a set of "handy tools". The Torx screwdriver was actually too small, so I ended up using my own.

The back cover is mostly cosmetic on the Nexus 4, so I opted to start with the more important screen/digitiser. A couple of Torx screws and some levering with the plastic tools and the back cover popped off. A further 11 or 12 small Philips screws later and the battery and plastic motherboard covers were free and removed. The battery in particular was held in place with strong adhesive, this took some encouragement to release from the case!

The links between the motherboard, daughter-board and other components like the rear-facing camera and 3.5mm jack were next to be disconnected, then each of those parts were removed from the device. Knowing I had to put this bunch of parts back together once the screen was replaced, I scored geek points by numbering the components as I pulled them out, making re-assembly much easier.

At this point "the device" was was just a screen/digitiser and some side buttons! This matched (almost) the state of the screen/digitiser unit I had been supplied. The compare and contrast was interesting, as the numbers of the parts didn't totally match from the original. I wasn't surprised, this would most likely be the evolution of the manufacturing process during the time the Nexus 4 was being manufactured, leading to different part numbers along the way.

One genuine omission on the new screen/digitiser unit was a diffuser which should sit in front of the notification LED. On the left the original clearly has a white diffusing layer, which is actually secured between the screen and the casing. On the right, there is no diffusing layer, you can see straight through to the black outer casing, which is almost transparent when any amount of light is present. I added my own diffusing layer, made crudely from printer paper, but it seems to have done the job!

Re-assembly then began, starting with the side buttons, the camera, the 3.5mm jack, the daughter-board, the main motherboard, the plastic motherboard covers and the battery. I had a scary moment when the device didn't power up after re-assembly, but a few minutes on charge from a wall socket subsequently revealed the battery was flat. In hindsight this makes sense; with touch input not working, I was unable to actually turn off the Nexus 4 in its broken state, so I most likely left it in a corner somewhere where it would have drained entirely!

With the screen/digitiser replaced, I started work on the back cover. Having gone for the cheaper option of purchasing just the glass panel and not the entire casing unit, I had to remove the old glass panel fro the plastic outer case. The glass was already shattered in one corner, so starting there I began to pull apart and pick out the shards of glass. The NFC/wireless charging coils made this job trickier; they are on effectively a gold sticker, pressed onto the inside of the back cover. I had to peel this off the old back cover with some force due to the strong adhesive, but not so much force as to break or tear the coils!

The plastic table cloth was very useful, as at the end of this glass work I was able to round up and dispose of the large amount of small pieces of glass, not the kind of stuff you want to be on your kitchen floor when you're walking in barefoot to get your breakfast in the morning!

Having picked out all the glass pieces, the back cover was free of its original panel. Almost. There were still many bits and pieces of glass and other dust and grime, which would need to be removed to ensure a good adhesion with the new panel. Some rubbing/cleaning alcohol and cotton buds did the trick to clean up the plastic case ready for the new panel.

Before assembly, a compare and contrast was again interesting. The new glass panel did not include the speaker grill, or a small square rubber spacer around the rear-facing camera. They were relatively easy to transplant to the new glass panel however.

The last steps were the placement of the glass panel on the back cover case, and attaching the back cover to the device again. One more boot up confirmed that the back cover work had not broken anything, and the refurbishment was complete.

Whilst I've flashed more ROMs and rooted/jailbroken more phones than I'd care to mention, I've never attempted any hardware work on any smartphones, so I was chuffed that this one worked out well. Given this was a popular device, there were lots of helpful articles and videos on the Internet for reference, so I didn't have to do much brain work myself! I just has to ensure I wasn't too clumsy with the small components and delicate electronics! Having brought it back to life, I'm looking forward to using the Nexus 4 with its beefier specs compared to my Moto G, and hopefully it will tide me over until my next phone is announced and released!

EE Kestrel Mini-Review

As usual, this loan device came courtesy of Steve and Ted from Phones Show Chat, and is a curious one, something a little different to the flagship devices which get most of the attention of the technology press. I hesitated to title this as a mini-review, it's certainly not a full review, the reasons will become apparent. In the end it's more of a comparison to its nearest competitor and my current day-to-day phone, the Moto G.

The EE Kestrel has a 1.2Ghz quad-core SnapDragon 400 CPU, 1GB RAM, 4G connectivity, a micro SD card slot, 4.5” qHD screen, and a 5MP camera. The obvious comparison is against the Moto G, which now has a 4G model which also has a micro SD card slot. The Kestrel and Moto G share matching CPU, RAM, connectivity and micro SD specs. Their cameras are on par with each other, both pretty poor. Their speakers are similar, both distort at around 50-60% volume. They both have a notification light! Whilst being very similar, here is how they are different...

Kestrel Positives

• Price: At £99 the Kestrel wins by between £20-£60 depending on where you buy your Moto G, and if you buy the 3G or 4G model.
• First impressions: The Kestrel feels snappy on first use, it doesn't feel like it weighs much either when you first pick it up.
• Capacitive buttons: Gives more screen space versus on-screen buttons.
• Connectivity: SIM unlocked it works with Three 4G perfectly, which is great given Three is most mobile geeks’ network of choice!
• Some genuinely very interesting OS additions on top of a base Android build, including:
• “Networked apps" - you can control access to wifi and mobile data per app.
• “Startup manager" - control which apps can or can't launch on device boot.
• “Notification manager" - control which apps can send push messages to the notification panel.
• "Do not disturb" - on a schedule, per contact restriction of ringing/vibrating.
• “Power saving" - including ability to select protected apps which are kept running no matter what, an analyser to let you know any power-intensive background apps, and another analyser telling you settings that may be adversely affecting battery life (GPS, screen brightness, etc).
• “App operations" - show how often each app calls APIs such as location services, personal data, messaging, and device hardware.
• Audio profiles (a la S60/S40 in the old Nokia days) and a nice easy way to change between them form the notification shade.
• Split screen for settings - with the "all" pane with the usual Android settings menu, and the "general" pane which has just commonly-used settings, not cluttered up by all the other million and one settings in the "all" pane.
• Two built-in launchers, although they’re called "home screen styles"...
• One for normal not tech-savvy folk, which has no app drawer, all icons are on the home screens (a la iOS).
• One for even less tech-savvy folk, with big easy tiles (a la Windows Phone) for apps and commonly used functions. This would be truly great for those with no interest in learning to use a smartphone, but who want a little more than a feature phone can offer. This home screen style also bumps up the system font, a giveaway that maybe this is aimed at the older person?!

  

Left: Choose your home screen style.

Middle: "Standard" style. No app drawer, just lots of icons like iOS.

Right: "Simple" style. Probably aimed at smartphone novices.

Kestrel Negatives

• The capacitive buttons aren't very responsive, and their lights turn-off too quickly (the only setting is auto-off and permanently off).
• The screen is pretty dull, and only qHD (even the Moto G has 720p).
• The charger (top) and headphone (bottom of left edge) ports are in unorthodox places, a little annoying.
• Whilst the built-in launchers have their use-cases, anyone reading this blog post would HAVE to install an alternative.
• In the capacitive buttons row the Kestrel has an old school menu button instead of a recent apps button.
• The OS is v4.3 and unlikely to be updated in a timely schedule, if at all... (a side effect from all the customisations which have been added?)
• And the deal breaker... 8GB internal storage. Not so bad given the presence of a micro SD card slot, but this 8GB is partitioned such that apps have less then 1GB. I couldn't even finish installing half of my usual apps. This is exacerbated by the presence of built-in apps like Facebook, Kindle, EE Film and more which you can’t uninstall.

Left: I didn't get to install even half of my usual apps when this happened.

Right: There's loads of space left, just not for apps.

I'd conclude that the storage partitioning is a complete deal breaker for me, so much so that I couldn’t use it as my full-time device to test it properly, and find out how good the battery life was for example.

Huawei/EE have put some very nice touches on top of Android. Some of these are available on other operating systems of course; on Android they may be available via a big bunch of third party apps, plus the need for root in some cases, but they are all here by default on the Kestrel. Whilst the built-in non-removable apps are a pain, the extras on top of a standard Android OS build are mostly commendable, usable, and designed fairly well. I think a lot of normal (non-geek) users would find them useful. To go a step further, the "simple” home screen and launcher could be the basis of the perfect smartphone for an older person or a complete smartphone novice. This is a great Android smartphone for a novice, as Android is still too complex for the average non-geek, and this device with all its customisations makes it much easier for the inexperienced user.


For the money, you would never expect a great camera, high-end CPU or great quality screen. It's great that the Kestrel does 4G at a cheaper price than the Moto G, but the Moto G has a better screen, doesn't suffer the app space partitioning, and is hugely more likely to be kept up-to-date. I would pick the Moto G over the Kestrel any day, though the Kestrel is a very, very interesting device with some very nice touches.

Feels Like a New Moto G

I factory reset my Moto G last night and set everything up from scratch. I'd not done this since I bought the phone 7 months ago. It took until past midnight, and I was short on sleep anyway!

However, battery life in the 48 hours since the reset has been much better, and the feel around the operating system is much quicker, along with only one app crashing where previously there would have been several. This is with the same set of apps and data as before the reset. To be complete in the detail here, that 7 months usage did include the update from Jelly Bean to KitKat. The conclusions are therefore:

• Android now behaves like Windows, in that users who consume lots of software/apps/services will accumulate crud, which over time slow the device down and make random things (crashes, force closes) happen, and only a fresh install gets you back to the speed and stability you know the hardware is capable of.
• Major version updates of the operating system should always be followed by a factory reset where possible.
• Android's native backup and restore of apps and app data is still pathetic, and very rarely restores a complete set of apps or app data, if it starts at all. There’s very little control of how it happens, and no web portal to see the apps Google has linked to your account, such that you know the apps it will restore, and have a choice to prune the list. Android is far, far behind iOS in this area, which has had flawless back and restore for years.
• The Moto G really is a brilliant device, especially given the context that this (albeit non-4G variant) 16GB model cost me £81 brand new from Tesco with ClubCard vouchers plus £3 for a SIM unlock.

None of this is news par se, but as one of those annoying folks who wants his phones to be "phone sized" (that's around 130mm x 65mm for me) it does justify my feeling that there isn't a better phone out there for me right now, over 7 months after the Moto G originally 

I've been tempted by a Moto X, the natural migration path in some ways from the Moto G, but as it is now a year old, a successor is likely around the corner. Given the Samsung Galaxy S5 Mini and HTC One Mini 2 were both disappointing and overpriced, my hopes for a new phone-sized phone to purchase seem to rest on rumoured devices such as:

• Sony Z2 Compact, where they'll hopefully have fixed the Z1 Compact's problems like the under-performing camera, the nasty factory-fitted screen protectors, and the chassis design that makes it feel larger than it is.
• Moto X2, where they'll have a much better camera in than that on the Moto X, and release it in the UK promptly (versus 6-7 months delay on the Moto X after it launched in the US)
• Some other thing that's a bit off piste and will surprise me into a purchase (a small Xiaomi device, a OnePlus One Mini, etc)

That list doesn't include anything too concrete, or even anything likely to be released in the near future. It's just as well this feels like new Moto G since the factory reset, as I seemingly won't be buying anything actually new any time soon...

Android Needs A Better Security Update System

Recent security issues such as Heartbleed, which reportedly affects Android 4.1.1 (http://googleonlinesecurity.blogspot.co.uk/2014/04/google-services-updated-to-address.html), and permissions being a bit too permissive (http://www.fireeye.com/blog/uncategorized/2014/04/occupy_your_icons_silently_on_android.html) have both apparently resulted in Google releasing fixes to their partners. We all know that their partners, the device manufacturers, have a poor history at updating devices, especially those devices which are more than a year or so old. In some countries, mobile network operators add a significant delay to the update process, sometimes many weeks or months.

It must therefore be time for Google to implement a direct system for applying security updates to devices, which does not rely on device manufacturers or mobile network operators. Sure it's not the ideal scenario; both device manufacturers and mobile network operators would much prefer to test the updates before releasing them into the wild. However, the direct system is surely better than having many hundreds of thousands of devices stuck on vulnerable versions of an operating system? Depending on which set of statistics that you look at, there could be anywhere from 10% to 34% of Android devices in use today on the 4.1.1 version that is vulnerable to Heartbleed.

Somewhat ironically, Microsoft's Windows operating system, which is not usually held up as a shining light for security best practice, has had a direct system for updates for many years. It's not perfect or 100% interoperable in every scenario, due to the massive array of both operating system customisations and end user software on the market for Windows. However, it does give Microsoft a direct route to deliver security patches, a route which isn't dependant on anybody else (outside of the corporate environment anyway, where rolling out updates is typically managed by the organisation centrally in a controlled manner).

Apple has the klout to do system updates direct for its iOS devices, but having control of the hardware and operating system stack end-to-end means there are less integration risks than the plethora of Android-based devices in the wild. Maybe that appeases the concerns of the mobile network operators. Apple also control app releases in their App Store much more than Google do in the Play Store, and the apps themselves have far less access to the operating system, with much fewer and wider ranging APIs available to app developers. Maybe that too reduces the risk of interoperability failures when updates are rolled out without mobile network operators having their testing time.

Google Play Services, a set of core modules responsible for providing the majority of APIs to non-system apps (amongst other things), are already updated directly from Google without any middlemen and without a user having to visit the Play Store, tick any boxes, or even "accept" the update. This system works already, and is responsible for bringing some new features to devices without them needing an operating version upgrade or a firmware upgrade from the device manufacturer. It would therefore not sound inconceivable that the next major version of Android, be it numbered 4.5 or 5.0, should include some form of device update system, similar to that used for Google Play Services, to bring security updates to users in a timely manner, for the good of everyone.