Programs that respect your privacy

WebView DevTools

Privacy Browser Android uses Android’s WebView to render web pages. WebView provides fairly limited controls compared to the upstream Chromium source. However, there are small set of user-configurable controls that Google has baked into WebView. Users can tweak these controls using WebView DevTools. If you are using a pre-stable channel (Beta, Dev, or Canary) there is a launcher icon for WebView DevTools. Users on the stable release of WebView are not provided with such a launcher, but it is possible for another program, like Privacy Browser, to include an intent that does launch it. Beginning with the 3.12 release, Privacy Browser has such a launcher in the navigation drawer.

Open to me the secrets of the WebView!

By default, if you change any of the WebView flags, a persistent notification will be displayed in the status bar to warn you of how dangerous your life is. But that can be disabled if desired.

Begone!

It is important to note that any changes made to WebView DevTools affects the way WebView works in all the apps on your device. These are not Privacy Browser specific settings. As such, it will affect any other browser based on WebView, like Lightning and FOSS Browser, as well as any other app that uses WebView to display documentation and information or interact with the internet (there are a number of apps that use WebView to handle logins). Privacy Browser will need to be restarted for any changes made in WebView DevTools to take effect. In addition, changes to WebView DevTools will need to be made on each of your devices and will not be carried over with an import of Privacy Browser’s settings to a new device.

The purpose of this page is to document any options in WebView that are likely to be of interest to Privacy Browser’s users. The available options can change with each WebView release. If you become aware of any option that ought to be added to this page, feel free to leave a comment at the bottom or to post a suggestion to the forum.

X-Requested-With Header

Currently, the only flag that most users would like to alter is WebViewXRequestedWithHeaderControl.

That doesn’t even sound grammatically correct.

The X-Requested-With header is discussed in some depth in a separate post. Needless to say, Google is highly incentivized to make it easy to track you around the web, and adding this to Android’s WebView makes it easier to do so. I have found that companies like Google, who have such conflicts of interest, often have a very hard time setting defaults that are in the best interest of their users.


7 responses to “WebView DevTools”

  1. Dear Mr. Stoutner.
    Thank you for implementing access to the DevTools on WebView Stable! Other interesting flags and my settings for those are:

    site-per-process -> ENABLED

    This helps against side-channel attacks at the cost of increased RAM-usage.

    WebViewLegacyTlsSupport -> DISABLED

    (see https://en.m.wikipedia.org/wiki/Transport_Layer_Security)

    WebViewBrotliSupport -> ENABLED

    Mainly useful if you want PrivacyBrowser to more closely mimic a Desktop Browser (e.g. with the “Chromium on linux” User Agent template) for sites which behave problematic with the original “PrivacyBrowser/1.0” agent.

    To anyone who wishes to experiment with the above (or any other flags in the DevTools) please be aware that activating JavaScript still makes it relatively easy for sites to fingerprint you, e.g. via canvas. (See https://browserleaks.com)

    • `site-per-process` is an interesting option. Reading over the description it doesn’t look like it would make much difference in Privacy Browser unless you were visiting a website that used iframes to display something from another domain. As it is currently listed as highly experimental I probably wouldn’t add it as a general recommendation, but I would revisit that when Google considers it to be better tested.

      `WebViewLegacyTlsSupport` is a very interesting option, and I was originally going to include it as a recommendation. However, testing showed that the default behavior on all supported versions of Android is already the same as setting this to be `disabled` (at least on on all the devices I tested). Basically, at the current time, this feature only still exists in case you want to enable it. However, if you are using a custom ROM that for some reason enabled older TLS protocols that have been disabled in AOSP, then it would be helpful.

      `WebViewBrotliSupport` enables the Brotli compression algorithm. By default, WebView advertises that it accepts `gzip` and `deflate` encryption. Enabling Brotli is an option that some people may prefer, but I can’t think of any way that it would improve the security or privacy of Privacy Browser.

  2. Yes, in the end it seems there aren’t any other privacy enhancing flags in the DevTools and current ones are getting renamed and/or obsoleted at a rather fast pace, e.g. in the 108.x.x.x (Beta) Version of the WebView the “WebViewXRequestedWithHeader”-flag is now called “WebViewXRequestedWithHeaderControl” and, if i understood it’s meaning correctly, will then need to be ENABLED to disable it.

Leave a Reply

Your email address will not be published.