Stoutner

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 a WebView DevTools 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. Note that some of the options come with warnings that they are experimental, and, particularly for those that involve site isolation or partitioning, might result in buggy behavior. If you become aware of any option that ought to be added to this page, feel free to post a suggestion to the forum.

X-Requested-With Header

The first flag that most users want 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.

Site Isolation

The site-per-process flag enables site isolation.

Everybody keep your hands to yourself!

Site isolation adds an extra layer of protection against malicious JavaScript from one tab being able to steal data from another tab. It requires extra RAM to run each site in a separate tab, but in my testing it isn’t much of a noticeable difference.

Partitioned Cookies

PartitionedCookies is designed to protect against third-party cookie nonsense.

How is this not the default?
Don’t answer that. It is a rhetorical question. I already know the answer.

This shouldn’t ever be a problem with Privacy Browser because all third-party cookies are disabled. But it never hurts to have multiple layers of defense.

Third Party Storage Partitioning

Enabling ThirdPartyStoragePartitioning also requires enabling SupportPartionedBlogUrl, which are, combined, described as storage partitioning.

I wish they just had a Disable Third Party Storage option.

By default, Privacy Browser wipes all local storage every time Clear and Exit is run. But, if JavaScript is enabled on two tabs from different domains with a shared iframe that previously shared local storage, this will prevent one tab from tracking the other.

Last updated

Soren Stoutner

12 responses to “WebView DevTools”

  2. 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. It enables Google’s site-isolation feature, which is off by default (it seems for RAM reasons, but there might be some other reason). https://www.chromium.org/Home/chromium-security/site-isolation/ At some point this will likely become the default WebView behavior. I am not sure I would recommend it generally as Google lists it as highly experimental, but I personally have not yet had any problems enabling it.

      `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.

  3. 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.

    • Good catch. This change hit the stable release for me today, so I have updated the screenshot.

  5. […] After testing it for a while and finding no downsides besides a personally unnoticeable increase in RAM usage, I have decided to recommend that users enable the site-per-process WebView DevTools flag, which can increase security when malicious JavaScript compromises the rendering process. There are more details on the WebView DevTools page. […]

    • Thanks for the heads up. I will take a look when 115.x lands on my device.