October 23rd, 2014
There’s an anonymous single-post blog at blogger.com that takes a look at Samsung’s Knox. Surprisingly, Knox relies on security by obscurity to hide the encryption key, the method of generation of which is now public information. It’s now known that it’s generated using the device’s Android ID and a hardcoded string.
As the author states, a stronger key should be derived using Password-Based Key Derivation Function 2(PBKDF2), from the user’s password, that shouldn’t be stored on the device.
Related to this, if you are instead relying on Android OS disk encryption, you might like to read how this has changed over time. Prior to Android 4.4 it was based on a PBKDF2 with only 2000 iterations, using the lockscreen PIN or password which tends to be short and more amenable to brute force attack.
October 21st, 2014
There’s an upbeat article at Business Insider that says that Android is suddenly growing massively as an e-commerce, advertising and app platform. It says…
"Too many analysts remain attached to an outdated idea of Google’s mobile operating system as fragmented, malware-ridden, and low-end. They believe Android users don’t spend money on mobile and lack lifetime value. This is no longer true."
One of the report’s takeaways, that "mobile business models that neglect or ignore Android risk severely limiting their market potential" reflects some US conversations I have had where it has been said that Android is a blind-spot for many California tech companies.
The report also covers how Android’s ad traffic and revenue share is rising fast and is producing healthy mobile commerce orders for companies. It also explains why Android’s fragmentation problem is overblown.
Negatives include feature creep and bloatware added by carriers and OEMs. I’d also say security is an issue, especially for security sensitive apps that need to make use of payments. Such apps need to take extra measures to protect themselves.
October 13th, 2014
Most Android apps are created by a single developer or a team of a few developers. However, what happens in a large company where potentially hundreds of developers each want to add their small feature? There’s a new video, from DroidCon Paris, on how Twitter went from a few developers up to of the order of 100.
The video shows how Twitter developers, who were more used to working on the Twitter Web site, had to adapt to working on Android. For example, their ‘web brain’ that previously allowed bugs in the web site to exist, because they could be reverted, had to be modified for Android where a crash usually means the user will install and might not re-engage with the app for another month. Also apps have a longer lifetime until upgrade and Twitter has up to 60 versions of the Android app running at any one time due to people delaying upgrading.
The session shows 50% of Android Twitter users will upgrade within 3 days if no extra permissions are required. 75% will upgrade within 14 days. When new permissions are required manual upgrade can typically take a month.
There’s also useful information on large scale training, test devices, code style wars, testing tools, emulator vs device, remote feature on/off and toolchains.