I suspect that your average Android user has no idea about the browser on their phone. These are the users who are most at risk.

Also, correct me if I am wrong, but app-based webviews (or app actions that spawn a browser instance) would defer to the default browser, ignoring any installed 3rd party browser. So i believe that the "install chrome" solution does not actually resolve the problem.

> Also, correct me if I am wrong, but app-based webviews (or app actions that spawn a browser instance) would defer to the default browser [...]

I think that is wrong, based on my phone's behaviour. Still with you, though; neglecting to fix this leaves the most vulnerable users open to attack.

That's wrong for some versions of Android, but if you have, for example, a Web wrapper around a Web app in an older version of Android that uses WebView, it's only a risk if the app somehow displays a link to an exploit. A properly designed Web wrapper uses techniques to avoid this risk: filtering urls to stay in the app's domain and, for, e.g., ads that jump outside that domain, to launch a browser.

>A properly designed Web wrapper uses techniques to avoid this risk: filtering urls to stay in the app's domain

So you are saying the WebView on Android is unsafe to use for rendering untrusted content. That's a pretty serious limitation and certainly not made clear in the documentation[1]. Infact the first line of the docs suggest that a WebView is suitable to "roll your own web browser" with…

Something is seriously wrong with Google's attitude to security if they are happy to document a class that's totally unsafe for use with untrusted data as being safe. Knowing this is enough to put me off ever using Android again to be honest.

https://developer.android.com/reference/android/webkit/WebVi...

> That's a pretty serious limitation and certainly not made clear in the documentation

Having engineered Web wrappers for a few clients, I would not have let them out the door without url filtering, and not just for security. A wild url could mess up the UX way before it becomes a security issue. Any sane "kiosk" style software should behave that way.

As for the documentation, when it was written, those statements were true. Now, with Chrome implementing WebView, that documentation is once more true. And I would STILL include url filtering in a Web wrapper.

WebView is embedded in many apps so using Chrome, or Firefox, won't help.

Correct. At present the only solution for pre-4.4 devices is to avoid using WebView to display untrusted content. If you're an app developer using WebView you should make sure it's only displaying trusted content which means either local content or remote content from trusted sites with non-broken SSL. I recommend using Google's recently-released nogotofail toolkit to test for SSL breakage (https://github.com/google/nogotofail).

The ideal fix for this problem is for OEMs to update devices to 4.4.

That doesn't help with apps that use WebView to render web content.