Intent to Extend Deprecation Trial: Removal of X-Requested-With in WebView
Peter Birk Pakkenberg
Hello Blink-dev.
I would like to extend the ‘X-Requested-With in WebView Deprecation’ trial until M138 in line with the premise made below in the Summary below. I am asking for an extension of 12 milestones instead of the customary 6 to avoid undue churn for the almost 100 origins that have signed up for the trial, as we expect that it will take at least another year to address the remaining use cases.
The feature is currently disabled on 5% of stable traffic, and we have developed the Android WebView Media Integrity API as a solution for uses of the header for media content providers. We have also launched an Android API for app developers to enable the header for select origins which has been adopted by almost 10k applications so far. This is an alternative available to Android apps that only display Web content they trust. We are still looking to address further use cases in the anti-abuse and anti-fraud space before we can fully disable the header.
Contact emails
Explainer
None
Specification
None
Summary
Removes the default X-Requested-With header from HTTP requests made by WebView.
The X-Requested-With header is set by WebView, with the package name of the embedding apk as the value. This use of the header will be discontinued.
Developers who rely on this header can sign up for a deprecation origin trial [1] to continue to receive the header during the deprecation period.
The deprecation origin trial will be extended until replacement APIs are available to address use cases of the header, as explained in this Android Developer Blog Post [2]
[1]: https://developer.chrome.com/origintrials/#/view_trial/1390486384950640641
Blink component
Search tags
TAG review
TAG review status
Not applicable
Chromium Trial Name
WebViewXRequestedWithDeprecation
Link to origin trial feedback summary
Origin Trial documentation link
Risks
Interoperability and Compatibility
Gecko: N/A
WebKit: N/A
Web developers: The X-Requested-With header is widely used for both anti-fraud and application allowlisting use cases, despite its inherent unreliability. These web services are concerned about the removal of the header without replacement technologies to facilitate their current reasons for consuming the header.
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
This feature removes a header sent by default by WebView. It should have no direct impact on applications using WebViews, but sites loaded in the WebView will no longer receive the X-Requested-With header unless the app explicitly allowlist the site[1] to receive the header or the site participates in the deprecation trial.
Debuggability
Is this feature fully tested by web-platform-tests?
No
Flag name on chrome://flags
None
Finch feature name
WebViewXRequestedWithHeaderControl
Non-finch justification
None
Requires code in //chrome?
False
Tracking bug
Launch bug
https://launch.corp.google.com/launch/4136516
Estimated milestones
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5160086884843520
Links to previous Intent discussions
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/k9HL9muJPxs
This intent message was generated by Chrome Platform Status.
 |
| ||||||
Daniel Bratell
This being beyond the normal scope of an extension will require three LGTMS so here is the first one:
LGTM1
I appreciate that it's not optimal in any way to have something like this running this long, but I sympathize with the end result and understand that App developers can need both longer to develop and especially longer to deploy to all users. That as many as 10k applications have adapted the new API is a good sign too.
If I were going to ask for anything else (which might make it easier for others to approve it), it would be proof that usage is dropping so that we won't have to extend it again.
/Daniel
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvTYjsq%2BesCrmUEmo5%2BzSUMGw81WmbnoFeL85ajGq2xz5PBGw%40mail.gmail.com.
Yoav Weiss (@Shopify)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e0b42f5f-2d8e-4955-bfc7-e3c7173e35ca%40gmail.com.
Peter Birk Pakkenberg
Hi Yoav,
A number of large websites are working on adopting the new WebView Media Integrity API as an alternative, however, that said, other websites have expressed hesitancy to move away from using the header, citing the lack of alternative signals that solve their more precise use cases.
Looking at the signed up origins, it appears that the usage of the header is quite unevenly distributed, and we are working directly with the largest users to reduce usage.
|
| ||||||
Yoav Weiss (@Shopify)
Hi Yoav,
A number of large websites are working on adopting the new WebView Media Integrity API as an alternative
, however, that said, other websites have expressed hesitancy to move away from using the header, citing the lack of alternative signals that solve their more precise use cases.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvTYjsq%2BesCrmUEmo5%2BzSUMGw81WmbnoFeL85ajGq2xz5PBGw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Peter Birk Pakkenberg
The X-Requested-With header exposes the app package name of the embedding application on all HTTP requests made from WebView. The header value is not signed, and can be changed either by web content loaded in the WebView, or by the host app, through various well known methods.
Media content providers have been using this information in an effort to help identify abuse and fraud, and the WebView Media Integrity API has been developed to be a more direct fit for these use cases.
We are working with the remaining OT participants to determine what, if any, further solutions are needed for their use cases of the header.
|
| ||||||
Yoav Weiss (@Shopify)
Mike Taylor
LGTM3
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJ0S5u80FXvDZtN5Gvi1hAfRk8S%3Dvf7Z2yXO0gDW8FULg%40mail.gmail.com.