Tag Archives: WebView

Increasing trust for embedded media

Posted by the Android team

Android WebView is a powerful and flexible API that Android developers can use to embed media in their apps, and continually improving its security and privacy protections is a top priority for our team. For example, embedded media providers should be able to verify that their media is playing in a trusted and safe environment. Android app developers and SDK providers already have solutions for this, including attestation services like the Play Integrity API and Firebase App Check, which preserve user privacy while enabling developers to verify their apps’ server requests. Today, app developers are able to pass information from these attestation services to embedded content providers; however, the current process is neither simple nor scalable. That’s why we’re piloting an experimental Android WebView Media Integrity API with select embedded media providers early next year.

How does this relate to the Web Environment Integrity API proposal?

We’ve heard your feedback, and the Web Environment Integrity proposal is no longer being considered by the Chrome team. In contrast, the Android WebView Media Integrity API is narrowly scoped, and only targets WebViews embedded in apps. It simply extends existing functionality on Android devices that have Google Mobile Services (GMS) and there are no plans to offer it beyond embedded media, such as streaming video and audio, or beyond Android WebViews.

What is the challenge with Android WebViews?

The Android WebView API lets app developers display web pages which embed media, with increased control over the UI and advanced configuration options to allow a seamless integration in the app. This brings a lot of flexibility, but it can be used as a means for fraud and abuse, because it allows app developers to access web content, and intercept or modify user interactions with it. While this has its benefits when apps embed their own web content, it does not prohibit bad actors from modifying content and, by proxy, misrepresenting its source.

What functionality are we bringing to embedded Android WebView media?

This sequence diagram shows a user requesting media in an Android app and the Android app returning the media in a manipulated WebView that could be used to alter the media and defraud the user.

The new Android WebView Media Integrity API will give embedded media providers access to a tailored integrity response that contains a device and app integrity verdict so that they can ensure their streams are running in a safe and trusted environment, regardless of which app store the embedding app was installed from. These verdicts are simple, low entropy metadata about the app and device and don’t contain any user or device identifiers. Unlike apps and games using Play Integrity API, media providers will not obtain the app’s Play licensing status and apps will also be able to exclude their package name from the verdict if they choose. Our goal for the API is to help sustain a thriving and diverse ecosystem of media content in Android apps, and we’re inviting media content providers to express interest in joining an early access program early next year.

Improving user privacy by requiring opt-in to send X-Requested-With header from WebView

Posted by Peter Birk Pakkenberg, Software Engineer

X-Requested-With (XRW) is a nonstandard header.

When a user installs and runs an application that uses a WebView to embed web content, the WebView will add the X-Requested-With header on every request sent to servers, with a value of the application APK name. It is then left to the receiving web server to determine if and how to use this information.

We want to protect the user's privacy by only sending this header on requests if the app developer explicitly opts-in to share with services embedded within the WebView. We are introducing new and purpose-built methods of client attestation that solve important safety use cases in a privacy-sensitive manner.

To let current online services that depend on this header migrate away from using it, we will run a Deprecation Origin Trial, while removing the header for general traffic.

Why are we making this change?

In early use cases, the X-Requested-With header was used to detect click fraud from malicious apps. It was also used to let a server know it's interacting with AJAX requests and needn't reply with HTML. The header was quickly adopted by common frameworks (jQuery, Dojo, Django) as a defense against CSRF attacks. However, several vulnerabilities (such as browser extensions impersonating websites) appeared around its use.

Android WebView adopted the X-Requested-Header with the application name as the value, as a way to allow online services to detect deceptive apps that were using hidden webviews to generate fake traffic. While this problem still exists today, the header as it is currently implemented does not fully solve the problem, as apps can easily change the value being sent on some requests in later Android versions.

The header, as currently implemented by default in Android WebView, does not follow the principle of meaningful consent of all parties exchanging the information and the Android Platform Security Model’s definition of multi-party consent.

APK name also contains specific information about the context in which the user is consuming the web content, and can leak the identity of the app to the online service.

How does this proposal affect the header?

It's important to note that the non-WebView use cases will not change because of this proposal, as clients and servers still can and will set the header in normal JavaScript environments.

Even today, WebView will not overwrite the header if the header has already been set on an AJAX request by a JavaScript framework.

This removal only targets the WebView use case, which adds the header to every HTTP request made by the browser (that is, not the XMLHttpRequest use case).

What is the impact of removing this feature?

Today content owners may decide to rely on X-Requested-With to attribute traffic and control access without employing their own authentication. Other services use it for reporting of aggregate patterns about their user base.

All of these use cases will be affected by the removal of the header on requests, and in the majority of cases where the header is not modified by dishonest apps, it provides useful information to online services.

Given this, we plan to limit disruption during the deprecation and transition to purpose-built replacement signals by offering a Deprecation Origin Trial to maintain the existing behavior.

We ask for feedback on existing use cases that currently rely on and may be impacted by these changes.

Next steps and the future of XRW

As we gradually roll out the removal, origins participating in the trial will be exempted (that is, WebView will continue to send the header to these origins for as long as the trial lasts). The deprecation trial is expected to remain active for at least a year to give partners time to adjust for the change.

Further, during the deprecation origin trial, we will be developing new privacy-preserving APIs to match the use cases where the XRW header is being used today, such as client attestation APIs.

Separately from the deprecation trial, we will provide an opt-in API for application developers. This API will allow individual apps to selectively send the header to chosen origins, which can be used to maintain functionality of legacy sites that are not migrating, and the API will remain after the deprecation trial has finished.

Helpful resources

Key areas where we are seeking feedback

  • Key use cases for the XRW header today (e.g., payment authentication, account takeover fraud)
  • How important the XRW header is for each of these use cases
  • Desired capabilities that any new privacy-preserving alternatives would ideally have

Developer tools to debug WebView in Beta

Posted by Nate Fischer, Software Engineer, WebView team

Since 2014, Android WebView has paved the way as an updateable system component, delivering stability and performance improvements, modern web platform features, and security patches to Android apps and users. However, updates can be a double edged sword: as much as we strive for stability and backward compatibility, new crashes and breaking changes occasionally slip through. To solve these issues faster, today we're announcing WebView DevTools, a new set of on-device debugging tools to diagnose WebView-caused crashes and misbehaving web platform features.

For your convenience, WebView DevTools comes included as part of WebView itself. The easiest way to launch WebView Devtools is to try out WebView Beta. WebView's beta program is a way for app developers to get WebView several weeks before they reach users, for extra lead time to report compatibility bugs to our team. Starting with today's release (M83), WebView Beta includes a launcher icon for WebView DevTools. Just look for the blue and gray WebView gear icon to get started debugging WebView in your app.

Inspecting a crash in WebView DevTools.

Inspecting a crash in WebView DevTools.

No software is bug-free and loading web content can be challenging, so it's no surprise WebView crashes are a pain point for apps. Worse yet, these crashes are difficult to debug because WebView's Java and C++ stack traces are obfuscated (to minimize APK size for Android users). To help make these crashes more actionable, we're exposing first-class access to WebView's built-in crash reporter. Just open WebView DevTools, tap on "crashes," and you'll see a list of recent WebView-caused crashes from apps on your device. You can use this tool to see if the crash report has been uploaded to our servers, force-upload it if necessary, and subsequently file a bug. This ensures our team has all the information we need to swiftly resolve these crashes and ensure a smoother user experience in your app.

IUsing flags to highlight WebView usage in Android apps.

Using flags to highlight WebView usage in Android apps.

However, not all bugs cause crashes. A handful of past WebView releases have broken Android apps due to behavior changes caused by new features. While our team's policy is to roll back features which break compatibility, the chromium team launches several features for WebView in each release, and we often need time to identify the offending feature. WebView DevTools can help here too. Inspired by Google Chrome's chrome://flags tool, which enables compatibility testing with web platform features, we're offering app developers similar controls for experimental features. To get started, open WebView DevTools, tap on "flags," enable or disable any available features, then kill and restart the WebView-based app you're testing. Using WebView DevTools will help us work together to pin down the culprit so we can roll it back. We've also included flags for features slated for upcoming releases, so you can test compatibility even earlier by enabling these features on your test device.

We hope you find WebView DevTools helpful for reporting crashes and testing against new WebView features. Install WebView Beta today to get started with WebView DevTools, and check out the user guide for more tips and tricks.

Protecting WebView with Safe Browsing

Posted by Nate Fischer, Software Engineer

Since 2007, Google Safe Browsing has been protecting users across the web from phishing and malware attacks. It protects over three billion devices from an increasing number of threats, now also including unwanted software across desktop and mobile platforms. Today, we're announcing that Google Play Protect is bringing Safe Browsing to WebView by default, starting in April 2018 with the release of WebView 66.

Developers of Android apps using WebView no longer have to make any changes to benefit from this protection. Safe Browsing in WebView has been available since Android 8.0 (API level 26), using the same underlying technology as Chrome on Android. When Safe Browsing is triggered, the app will present a warning and receive a network error. Apps built for API level 27 and above can customize this behavior with new APIs for Safe Browsing.

An example of a warning shown when Safe Browsing detects a dangerous site. The style and content of the warning will vary depending on the size of the WebView.

You can learn more about customizing and controlling Safe Browsing in the Android API documentation, and you can test your application today by visiting the Safe Browsing test URL (chrome://safe-browsing/match?type=malware) while using the current WebView beta.

Beta Channel for the Android WebView

Posted by Richard Coles, Software Engineer, Google London

Many Android apps use a WebView for displaying HTML content. In Android 5.0 Lollipop, Google has the ability to update WebView independently of the Android platform. Beginning today, developers can use a new beta channel to test the latest version of WebView and provide feedback.

WebView updates bring numerous bug fixes, new web platform APIs and updates from Chromium. If you’re making use of the WebView in your app, becoming a beta channel tester will give you an early start with new APIs as well as the chance to test your app before the WebView rolls out to your users.

The first version offered in the beta channel will be based on Chrome 40 and you can find a full list of changes on the chromium blog entry.

To become a beta tester, join the community which will enable you to sign up for the Beta program; you’ll then be able to install the beta version of the WebView via the Play Store. If you find any bugs, please file them on the Chromium issue tracker.