Web Apps Getting Deeper Integration into Android

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.

DroidCon NYC 2015 and Rendering HTML

droidconnycThe 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 the WebView is that is that it’s very inefficient and hence very slow if you have lots of pieces of html in a view or even worse, in a ListView or RecyclerView of views containing HTML. Basically, it’s impractical to mix WebViews with native components to create a complex view. Even if your view is just one WebView, the base styles and scroll performance end up being those dictated by the WebView. All these concerns are before we even think about how different WebView implementations render things differently, how to control when embedded images are fetched, when/where css/javascript comes from and the security implications of using a WebView.

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.

The Future of the Web from a Mobile Perspective

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?

Insecurity of Mobile Banking Apps

esieaTwo 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…

“Almost all (banking) applications dynamically load the graphical content of their pages from a remote server. The possibility offered by mobile development to execute html and Javascript is pushing companies to outsource the application content: what has been done for a web site can be copied almost unchanged for an application”

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.

Android Click on Web Link to Run Arbitrary Code

tancentIn 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.

Older WebViews Not Being Updated

securitystreet.pngIf you have been following my posts on Android WebView security concerns then you might be interested to know that Google No Longer Provides Patches for WebView Jelly Bean and Prior. However, as one of the post comments points out "Even if Google does continue support, would the devices even get it?". Learn more about Android WebView vulnerabilities

Web Access From Devices

scientiamobile.pngScientiamobile has a new free MOVR report (PDF) for Q3 2014 showing device usage trends, particularly related to web access from mobiles. There’s lots of data on form factors, top smartphones, top tablets, top OSs for browsing across different continents. A chart that caught my attention was one that showed the use of WebViews within apps to view web pages…


Why does Android have a much higher proportion of web page views from WebViews? I’ll be contentious and guess it’s because developers put in less effort on Android. WebViews are the quick and easy route to getting an Android app with the compromise of poorer usability. I guess it’s because companies/developers tend put less effort into Android apps than iOS apps.

On a recent project, I argued (unsuccessfully as they are still there) that WebViews make a very poor substitute for real screens (Android Activities). Without a lot of effort creating a responsive server-side, the web pages don’t look like app screens, the app vs web navigation breaks down, you get links rather than buttons/list items, you open up many complex security vulnerabilities and content authors end up thinking it’s ok to add arbitrary server-side content. For example, I saw content being included that had sharing buttons and feedback forms that looked alien in the app and didn’t work well. It made me uncomfortable that the app I had written had become something I wasn’t proud of.

Meanwhile, Google are trying their best to make Chrome and by implication, WebViews feel more like the platform you are running on. This started with Material Design which they hope will unify the look and feel cross platform. Google are pushing to reduce the distinction between app screens and web screens. The Lollipop Launcher (Home screen) includes cards that can be web pages. Chrome Developers Tweeted from the Chrome dev summit yesterday…


Google are also working on Chrome rendering performance, push messaging, Bluetooth, notifications, access to camera, geofencing and background sync as well as corresponding web site permissions to control access to these new features. All these things will eventually help the web become more like an app.

However, all this is very Chrome centric. Consistent design and available functionality will only work if you use Chrome and implement Material Design cross platform and even if you did, Material Design web pages aren’t going to look good on iOS. Even the example in the above tweet shows a Navigation Drawer (hamburger menu) on the right hand side in the wrong place. In reality, Android Chrome users are more likely encounter iOS idiom-based web pages with disclosures than Material Design web pages. I anticipate the web and WebView content/functionality will continue to be an idiomatic mess. 

WebView Unbundling

arstechnica.gifThere’s an interesting post on ars technica on "Unwrapping Lollipop" talking to "high ranking members of the Android team" about changes to the OS. It includes a very useful breakdown of what’s now in the Android OS, what’s in Play services and what’s distributed via the Play Store.


Of particular interest is that WebView has been unbundled and now comes from the Play Store. The idea is to be able to more-easily (auto) update WebView for performance and security reasons. However, this won’t be for pre-Lollipop devices. In the near-term, there will still be a large number of old devices on old and varied versions of WebView. Also, unbundling has the side-effect that, going forward, non-Google sanctioned, AOSP-derived devices won’t have the latest WebView. Google will obviously care less about this but it will affect the 20% of developers on those platforms.