How can Google detect a request is from a WebView?

Question

Google announced that they "will no longer allow OAuth requests to Google in embedded browsers known as 'web-views'".

In Android, requests from WebViews get a header HTTP_X_REQUESTED_WITH which is set to the package name of the application. Although this can be overridden, so it would be possible to hide to the server that we are making request using a WebView. I don't know any other default way to make this.

Is there a way to detect, server side ― and no matter what the client does, that a request is from a Android WebView. How is this done by Google?

Answer 1

As others have said there is a range of Differences between the WebView and a normal browser but they are all in data sent in the headers from the browser so you can circumnavigate them.

however there is a libaray https://github.com/Valve/fingerprintjs2 so you could read though that to see the details of what they do. as it creates a device fingerprint so google could employ tack-ticks like this for there detection/

It is also possible that they could have there own Javascript running inside the WebView core code that you can't remove and they could detect it from that. so unless you wrap your own browser as a view you wont be able to circumnavigate the detection.

It is also possible like the above method that they could use the chrome:// system in hidden iframe and detect the content from it to identify E.G chrome://about-view/ and it print the hard coded User-Agent. again the only way to circumnavigate this would be to roll your own browser.

As @WilliamDenniss has said doing the header circumnavigation if they detect they could block your app and your account and as such all apps on your account and preventing you from ever publishing an app again from that account.

Answer 2

I don't think Google is planning to enforce any sort of violent detection of WebViews, I think the policy change is just meant to start a new norm. Google does not have to enforce it, if it becomes the norm, users will find it shady that an app proposes sign-in through an embedded browser---and users will require compliance. (I am not saying every user of an app has to make such requests, but I'm betting there is, for any app that matters at least one vocal one.)

Answer 3

Not answering your question directly (sorry), but regarding the deprecation of WebView for OAuth that you referenced: even if you find a way to avoid the WebView being detected during an OAuth flow, doing so may run contrary the Google API Services: User Data Policy, in particular the section "Do not mislead Google about an application's operating environment". So I wouldn't recommend that.

Typically using Custom Tabs for OAuth (such as via AppAuth for Android) results in a better user experiance anyway, as the user will likely already be signed-in to Google allowing them to review your request without needing to sign-in again. It's also more a more secure experiance. That's the goal of the migration – a more secure, more usable OAuth experiance for end-users :-)

Answer 4

You can differentiate via the user agent string. See https://mobiforge.com/research-analysis/webviews-and-user-agent-strings

e.g. default chrome browser contains the following "(KHTML, like Gecko) Chrome/xx.xx..." but default webviews are of the following pattern "(KHTML, like Gecko) Version/4.0 Chrome/xx.xx.." It seems webview has an extra version string.

Answer 5

All http requests sent through a webview have X-Requested-With header present which can be used to detect that the request is from webview.

X-Requested-With: the.app.packageName

Answer 6

Google is detecting user agent, I guess no deep check, because if you change the user agent string (like desktop mode in browsers), the authentication will work.

But here is quote from google (https://developers.google.com/terms/api-services-user-data-policy),

Do not mislead Google about an application's operating environment. You must accurately represent the environment in which the authentication page appears. For example, don't claim to be an Android application in the user agent header if your application is running on iOS, or represent that your application's authentication page is rendered in a desktop browser if instead the authentication page is rendered in an embedded web view.

Very interesting thing is some popular webview based browsers (Dolphin, Firefox Lite, etc) uses modified user agent string. No more 'disallowed_user_agent' error. They are in PlayStore for long time. @William Denniss is true, but these apps are not suspended. So I guess, there is a way to do it without violating google policies. But needs a James Bond to find it, lol...