Intent to Deprecate: X-Requested-With in WebView
Peter Birk Pakkenberg
Contact emails
Explainer
None
Specification
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.
Blink component
Motivation
The header as implemented in WebView does not follow the principle of meaningful consent of all parties exchanging the information[1]. Developer can utilize unreliable and undocumented methods to opt-out.
Users are not provided with an opt-out option. The content owner is the only party with full control over the information provided in the header.
APK name is also an abundant source of passive fingerprinting information about the users. It contains specific information about the browsing context. When the application is not omnipresent (i.e. has a relatively small user base), together with other information (e.g. approx. geolocation based on an IP address), it can provide a fairly unique identifier of a user.
On top of those privacy issues, the header is undocumented, used in non-WebView context for a completely different purpose, notoriously misunderstood, and causing security issues since its introduction.
[1]: https://w3ctag.github.io/design-principles/#consent
Initial public proposal
Search tags
TAG review
TAG review status
Not applicable
Risks
Interoperability and Compatibility
Gecko: N/A
WebKit: N/A
Web developers: No signals
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
WebViewXRequestedWithHeaderControl
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
This intent message was generated by Chrome Platform Status.
 |
| ||||||||
Rick Byers
--
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/CACvTYjv0PC76S%3DZkg66V_KCPfrb3tAnryWGnA6TfQz-ay2yXKA%40mail.gmail.com.
Peter Birk Pakkenberg
Mike Taylor
Mike
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvTYjuZy4SeHwVCJ%2BGvawdGrAR6myzAJEwZEX6Jmymii6wxDg%40mail.gmail.com.
Peter Birk Pakkenberg
To clarify my last statement, here is our proposed plan:
We intend to start a deprecation trial, which will retain the current behaviour of sending the X-Requested-With header from WebView clients, however, as an opt-in rather than default behaviour. This trial is planned to run for at least one year, but we’d only like it to end once we have a replacement solution.
Simultaneously, we’re working on gathering requirements and designing replacement APIs for the key use cases, in a secure and privacy-conscious manner.
Right now we are looking for approval to start the deprecation trial and change the header to become opt-in for non-trial-participants, with the understanding that this will be an ongoing trial with no set end-date.
We will also publish a blog post in January to further lay out the reasons behind this change, and the timeline for the deprecation.
Rick Byers
Mike Taylor
Peter Birk Pakkenberg
Mike Taylor
Hi Mike,
We plan to open the deprecation trial for sign-up in January.
We’re planning to roll out the change in behaviour in M110 Canary/Dev/Beta, and hopefully a small percentage of Stable in M111. The exact ramp-up schedule after that will depend on feedback, and is something we’re still figuring out together with other stakeholders, but we plan to take a careful approach.
Assuming the blog post goes out soon, that gives ~2 months for developers to notice and implement any necessary changes. It feels a little bit on the short side. But I'm glad to hear you're working out the ramp-up details with caution in mind.
If the Deprecation Trial is valid beginning with M110, when does
it end? I don't know that we've shipped "never expires" origin
trials before (to my knowledge they require an expiration date
encoded in the token?).
Peter Birk Pakkenberg
Peter Birk Pakkenberg
Hi blink-dev@
I wanted to update you on the deprecation trial for the X-Requested-With header deprecation, as we are planning to change the trial to allow third-party enablement.
We have received developer feedback that it should be possible to be able to re-enable the X-Requested-With header on cross-origin requests, where a service that relies on the header is being called without the option to respond with an Origin-Trial HTTP header on a navigation request, or by running a script of its own. An example of this is a web service which simply provides an JSON endpoint.
Because the trial changes request header behaviour, we think that this feature request is reasonable. We want to provide a solution where the deprecation of the header can still be impactful, while services that rely on it can retain it during the deprecation period.
To solve this use case, we propose that the trial can be enabled on behalf of the service, by letting the calling script provide a third-party origin trial token on behalf of the service it wishes to call.
Third-party origin trial tokens is an existing mechanism for trial enablement. By supplying a token for the target origin, a script can signal that it wishes to enable a trial for a particular service, without re-enabling the X-Requested-With header for the whole frame.
Aside from these changes, the plan or purpose for the trial has not changed.
Peter Birk Pakkenberg
Hey there,I understand the conversation is focusing on the trial, but I'm still very confused about the removal of X-Requested-With header itself.That header is still sent even on the current bleeding-edge webview (v113.0.5637).When can we expect to see it disappear for certain ?Thanks in advance for your reply,Best regards,-Robb
