Google is Integrating Progressive Web Apps more deeply into Android. This will make web apps 1st class Android citizens in that they will be able to be shown in the app drawer and receive incoming intents.
If you are a long time reader of this site, you will know I am not a great fan of hybrid web apps masquerading as ‘native’ apps. They are usually less secure, have significantly less technical capability, have UI performance problems and don’t tend to use the Android OS look and feel. Allowing web apps into the app drawer is a backward step in my opinion.
The Droidcon NYC 2015 video presentations have become available offering 48 sessions covering a wide range of topics. What I like about this and other Droidcons is that presenters come with no hidden agenda. There’s usually very little promoting of their respective companies or products and instead it’s all about advice gained through experience. It’s also great to compare how others have solved problems that you have experienced yourself.
For me, one such problem is described in the Beautiful Typography on Android (or close enough) session presented by Lisa Wray of Genius. On multiple projects I have had the problem of having to render server sourced, sometimes human created, HTML in Android. As Lisa explains, there are two ways to do this. The first way is to use a WebView and the other is to use a TextView with fromHtml() which converts the HTML to lots of Spanned text.
The problem with TextView.fromHtml() is that the result is often incomplete and lacks the fidelity of the original HTML. Lisa Wray’s presentation shows how to modify the Spanned text created by fromHtml() to make it, as she says, “Beautiful (or close enough)”.
Stepping back, this situation pinpoints something that should probably be avoided at the architecture stage anyway – the app displaying arbitrary HTML from the server. Managing this so that it renders well in an app and across mobile OS platforms can be very difficult. This is because you are trying to mix web and app display paradigms. While HTML might look like being convenient, it’s not usually well suited to consistent display in apps. If you can, it’s better to store and communicate content as text and meta data.
Last month Peter-Paul Koch (PPK) of quirksmode published a contentious post asking if it was time to stop pushing the web forward. His argument was that “cramming in more copies of native functionality at breakneck speed” is futile and native apps will always be better. Instead, the web should concentrate on its strengths: simplicity, URLs and reach. There has now been a newer post, stop pushing redux, on the mixed reactions to the original post.
I think what web developers are coming up against is what I described in 2007:
“Once we try to write real applications within the browser we will be exposed to similar issues that make native development difficult”
Even though the web now is still nowhere near feature parity with native in 2007, web developers are having a hard time developing for it. As I mentioned recently, the web vs apps outcome has resulted in the (mobile) web platform having security and fragmentation headaches.
The web still has a possible alternate successful future and I agree with PPK that it’s time to play on its strengths… and particularly it’s strengths over apps. Maybe new features should be those that native apps don’t have?
Two days ago I repeated my advice on having to be careful when using WebViews in security sensitive applications. Yesterday, I happened to come across a research paper (pdf) (and presentation) “Insecurity of Mobile Banking… and of other apps” by Eric Filiol and Paul Irolla of ESIEA Operational Cryptology and Virology Lab that recently became available at blackhat Asia 2015. In the research paper it says…
The authors are French so we can excuse them that the above doesn’t read that well but I think what they are saying is that because banks already have a secure web site accessible via the browser most are re-using it for use within their mobile apps.
I guess the assumption banks are making is that any checking such as login, intrusion detection etc is already there and proven it’s best to re-use these mechanisms as they are considered to be secure. Unfortunately, that assumption is very wrong. In using WebViews to render server side screens they have opened themselves up to the area of the phone software that has the most (and most complex) vulnerabilities. For example, the login might be on a web page on some server but by rendering a remote page there’s the possibility of extra unwanted things being loaded that might do literally anything such as log keys and read data in files or memory. I have also yet to see a reliable implementation of certificate pinning that works with webviews.
The authors also claim…
“Furthermore, there is at least one vulnerability affecting webview. This vulnerability has not been disclosed by Google and consequently Google will not publish any security patch to correct it for version 4.3 and prior versions. It is therefore a major vulnerability which allows a third party to take control over the phone.”
You can read the paper (pdf), slides (pdf) and a similar presentation (video) from December that analyses some well-known banking apps to show they aren’t that secure. If you really must use WebViews, you might also read my guidelines on how to be careful with WebViews on Android. If you are concerned using a banking app yourself then you can read my basic advice of consumers.
In the past I have mentioned the need to be careful about using WebViews in apps, particularly apps that are security sensitive. The number and complexity of WebView vulnerabilities are such that a pragmatic approach might be to not use WebViews in security sensitive apps. Recent news has shown that the same vulnerabilities can be a security problem for the Chrome web browser app itself.
If you have been following the IT news, particularly the security news, you will know that the Italian spyware company Hacking Team recently got hacked themselves and their source code was posted on the Internet.
It turns out they developed an Android ‘remote2local‘ exploit that cleverly combines three known Chrome vulnerabilities and the root-enabling put_user or TowelRoot vulnerabilities to allow pre-defined code to be executed as root from the user simply clicking on a link in the browser. The details are on the Tancent blog (Google translated).
How bad is this? The Hacking Team have a compatibility file that says it covers Android 4.0 to 4.3 and lists some tested devices…
One of the vulnerabilities, CVE-2012-2825 Arbitrary memory read, was fixed in June 2012 and another, CVE-2012-2871 Heap-buffer-overflow was fixed in August 2012 so end users allowing Chrome and WebView to update via the Play Store will have had these vulnerabilities fixed a long time ago.
However, this demonstrates how vulnerabilities can be combined to run code as root without the user even knowing. The Hacking Team compatibility file and subsequent vulnerability fixes show that in some ways, Android’s fragmentation aids security. It’s difficult for exploits to cover all types of Android OS and device and they usually only work on smaller subset of devices. As I previously mentioned, this won’t be much consolation to large companies with thousands of employees or customers which greatly factor up the chances of encountering exploits that might end up accessing sensitive company information.