Privacy Browser

Privacy Browser 3.0

Privacy Browser 3.0 has been released. The major feature is the long awaited tabbed browsing.

Beautiful tabs!

Using a tab layout generally works well, and in some cases is even better than I imagined it would be. The favorite icon has been moved from the URL bar down to the left of each tab. This helps with identifying tabs and also frees up valuable space in the URL bar. Adding a new tab is accomplished by tapping the + icon. Closing a tab can be done from the first item in the navigation menu. I considered placing a close icon on each tab, but I was concerned that it would be too easy to accidentally close a tab when trying to switch between them. (For consistency and ease of access, Clear and Exit was also moved up to the top of the navigation menu.)

Updated navigation menu.

One of the things I discovered is that Android’s WebView only allows enabling and disabling first-party cookies by app, not by WebView (as is the case with third-party cookies). This limitation will be removed in the 4.x series with Privacy WebView, but until then I have added a warning to the first-party cookies setting.

First-party cookies warning.

Because some people don’t like links littering their browser with excess tabs, I created a setting to disable the opening of intents in new tabs. Intents are URLs that are sent from other apps. For example, if an email contains a URL, tapping on it in the email app sends an intent to the browser requesting that it load the URL.

Open intents in new tab.

I moved the URL loading progress bar from the bottom of the app bar to the top of the WebView. Otherwise, the progress bar would not be visible when the app bar is scrolled off the screen or when full screen browsing mode is enabled with the app bar hidden.

A bug was fixed that caused Privacy Browser to restart every time a Bluetooth keyboard was connected/disconnected (including when a Bluetooth keyboard would enter/exit power saving mode). It turns out that this, for some crazy reason, is the default Android behavior for all apps. Luckily, there is a fairly simple way to disable it.

Another bug was fixed that caused the bottom of the WebView to be cutoff when scrolling of the app bar was disabled. This was caused because the WebView was adjusting the layout assuming the app bar could scroll, which made a section of the bottom of the WebView equal to the height of the app bar not accessible if the app bar did not get out of the way.

This release includes the first full German translation in a while, kindly provided by Bernhard G. Keller. The Italian translation was updated by Francesco Buratti; the Spanish translation was updated by Jose A León; the Russian translation was updated; and the Turkish translation was partially updated.

The next release of Privacy Browser will focus on speeding up the loading time of the app, which currently is hampered by the synchronous loading of the blocklists on the main thread from an inefficient text format that requires extensive parsing.

Privacy Browser

Problems with Redmine

March 14 Update: Redmine is working again.

There is a bug in the current Debian Redmine package that prevents users from being able to log into the site. I have reported the bug to the package maintainers, but it is uncertain how long it will take them to upload a fixed version. Currently we can view the status of existing bugs and feature requests but not make any changes. Until Redmine is fixed, users may submit bug reports in the comments to this post or by emailing them to me.

Privacy Browser

Privacy Browser 2.17.1

Privacy Browser 2.17.1 has been released to address a bug that caused Privacy Browser to crash if a bookmark was created with a very large favorite icon. This bug has existed ever since bookmarks were added to Privacy Browser in version 1.8, but nobody ever noticed until now because most websites are polite enough not to post full size photographs as their favorite icons.

This release also adds a line to the manifest that allows the user to move the APK to the SD card. By default, the OS does not allow apps to be moved. But I am all in favor of users having the choice to do so if they desire.

Privacy Browser Roadmap

3.x Series Roadmap

The release of Privacy Browser 2.17 marks the end of the 2.x series (unless a serious bug is discovered that needs to be addressed). The 3.0 release will implement the long awaited tabbed browsing. Following that, all other features that can be implemented without Privacy WebView will makeup the body of the 3.x series. At any time, users can see which features are planned for the next release and the list of all remaining features for the 3.x series.

With the 4.x series, the plan is to create a rolling fork of Android’s WebView, called Privacy WebView, that will add missing privacy features. Once the 4.x series is implemented, I plan to start working on Privacy Browser for other platforms. My initial thought is that I can develop it using the Qt framework and QtWebEngine, which will allow me to use one code base for Linux, Windows, and macOS. However, I will do a deeper investigation of the options and make a final decision when we get closer to that point.

Privacy Browser

Privacy Browser 2.17

Privacy Browser 2.17 has been released. The app bar now scrolls off the screen when the WebView is scrolled down and reappears when the WebView is scrolled up. This was an important prerequisite in preparation for tabbed browsing, as the tab interface will take additional screen real estate that would be bothersome if it couldn’t be hidden by scrolling. App bar scrolling can be disabled in the settings for those who do not want it. The full screen browsing options were simplified to work with app bar scrolling.

There is a new Logcat Activity. This displays the logs that Privacy Browser can collect about itself without needing any special permissions. It is useful for figuring out what caused a crash. Depending on the cause and the permissions needed to see the information, not all crashes will be displayed in the Logcat. The screenshot below shows a crash caused because Android’s over-aggressive memory management decided to wipe out one of the blocklists while it was being used.

Users can now specify the URL and which browser to open when creating a desktop shortcut.

The link and image context menus now have options to open directly with an app or another browser.

Default apps can now be set from the open with app chooser.

A bug was fixed that caused Privacy Browser to apply URL syntax highlighting to text a user was typing if they started typing it while a website was loading. Another bug was fixed that would display the pinned mismatch dialog if the IP addresses were pinned and they had not yet been acquired by Privacy Browser when the website finished loading. Because the IP addresses usually were populated by the time the dialog was fully displayed, this would show a pinned mismatch dialog with no mismatching information.

Google’s Android Support Library, which is no longer maintained, was replaced with the new and shiny AndroidX libraries. This is basically a rename on Google’s part. These libraries backport newer Android features so they work on older Android devices, as we all know how miserable most OEMs are at updating Android after a device is released.

We have a new German translator, Bernhard G. Keller, who updated all the German strings for this release and will be working on the Guide and About for the next release. Progress is also being made towards the first full Turkish translation. The Italian translation was updated by Francesco Buratti. The Spanish translation was updated by Jose A. León. And the Russian translation was updated.

Unless there is a critical bug that needs to be fixed, this is the last release in the 2.x series. The 3.x series will begin with the much anticipated addition of tabbed browsing.

Privacy Browser

Privacy Browser 2.16

The release of Privacy Browser happened earlier than I anticipated due to a need to fix an urgent bug, introduced in 2.15, that caused SSL certificate pinning to be ignored unless navigating history using the forward/back buttons or the history list. Not all of the planned features for 2.16 had been completed when this bug was discovered, but enough of them had been that I decided to release what was ready as 2.16 and push the rest off until the next release.

IP address pinning has been added to compliment SSL certificate pinning. This can provide protections against scenarios where DNS servers have been hijacked or redirected to provide bogus IP addresses. There have also been improvements to the layout of the SSL certificates in domain settings.

The current IP addresses are also now displayed in the View SSL Certificate dialog.

There are new menu items for opening a website with apps and other browsers. If an app is specified as the default for a particular schema it will be opened directly. Otherwise, the user will be presented with a list. If no app has specified an intent for the schema, it will reopen with Privacy Browser

These options are found under the new Share options menu.

The WebView night mode text selection color has been improved.

There have been various improvements to the bookmarks database view activity. There have also been some changes to some of the strings that reference numbers to make them easier to translate.

The Italian translation was updated by Francesco Buratti and the Spanish translation was updated by Jose A. León. The Russian translation was also updated and the partial Turkish translation is getting closer to being complete.

The next release of Privacy Browser will allow for scrolling the app bar and viewing crash logs, which should be a big help in troubleshooting problems. Baring unforeseen circumstances, I expect it to be the last release of the 2.x series.

Financial Reports Privacy Browser

2018 Financial Report

Going forward, I thought it would be helpful to post a yearly financial report on the growth of Privacy Browser.


  • Google Play: $344.09
  • Google AdMob: $101.57
  • PayPal: $39.06
  • Bitcoin: $24.10
  • Amazon: $1.37

Total Revenue: $510.19

Google Play revenue comes from selling the standard flavor on Google Play. Google AdMob revenue comes from the display of ads in the free flavor, regardless of the distribution method. PayPal revenue comes mostly from selling the standard flavor on XDA Labs, although sometimes I also receive PayPal donations. Bitcoin revenue comes mostly from donations, although it is possible to purchase the standard flavor on XDA Labs using bitcoin. Amazon revenue comes from selling the standard flavor on the Amazon Appstore.

Install Base

Google Play reports some fairly detailed statistics about installations. The other distribution methods (F-Droid, XDA-Labs, the Amazon Appstore, and direct downloads from either do not track this information or provide only vague information. The screenshot below shows the installs of the standard flavor on active devices, which is defined as the “Number of Android devices that have been active in the past 30 days with the application installed”.

Unsurprisingly, even though there are far more installs of the free flavor, there are fewer active devices. This is because most users either decide they don’t like Privacy Browser, or they switch to using the standard flavor.

Privacy Browser Security and Privacy Canary

2018 Security and Privacy Canary


During 2018, Stoutner received 0 requests from governments or organizations to insert backdoors into Privacy Browser.

During 2018, Stoutner inserted 0 backdoors into Privacy Browser.


During 2018, Stoutner received 0 requests from governments or organizations to weaken the privacy of Privacy Browser.

During 2018, Stoutner has made 0 changes to weaken the privacy of Privacy Browser.

Legal Requests for Information

During 2018, Stoutner receive 0 legal requests for information from government law enforcement organizations. These requests sought information for a total of 0 individuals.

During 2018, Stoutner provided information in response to 0 legal requests for information from government law enforcement organizations. These responses included information for a total of 0 individuals.

The types of information that Stoutner possesses and can disclose to legal requests from government law enforcement organizations are described in the privacy policy.

Privacy Browser

Privacy Browser 2.15.1

Privacy Browser 2.15.1 has been released. It is an emergency bug fix release that resolves a crash when opening a secondary activity on some devices.

Beginning with Privacy Browser 2.15, the drawer header padding is adjusted for phones with notches. The adjustment is calculated based on the height of the status bar every time the drawer moves (opens or closes). It turns out that on certain devices this creates a race condition where the new padding is applied to the header after the activity has been moved to the background and a new activity (like Settings, Guide, or About) has launched, causing a null object reference that crashes Privacy Browser. In my testing, this happens on certain devices running Android 5.0 and 5.1 (API 21 and 22) but not others, leading me to think the race condition might be caused by a combination of the OS settings and hardware speed.

The solution is to check that the views are not null before applying the new padding.

Privacy Browser


From time to time I receive suggestions from people that I change Privacy Browser to use Mozilla’s GeckoView instead of Android’s WebView to render pages. Instead of responding to each of these communications individually, I thought it helpful to write a general post covering this subject and explaining why I am not now considering doing so (although I am always open to it in the future if it becomes in the best interest of Privacy Browser to do so).

First, a little bit of background is necessary. The Android Open Source Project contains a standard system library called WebView that renders HTML content. It is programmatically similar to TextView, ImageView, EditText, or any of the other standard views that are included in Android. Many apps that users might not realize use this library to handle complex layouts. If WebView is removed from Android a large number of apps will crash unexpectedly.

In the open source world, there are two large pedigrees of code for rendering HTML content: WebKit (and its forks) and Gecko. Gecko is the engine developed by Mozilla and used in Firefox. Years ago, when Apple decided to make Safari they looked around at the existing code bases. They could have used Gecko, but they decided to fork KHTML and KJS (developed for KDE on Linux and used in Konqueror) and formed WebKit. When Google decided to get into the browser world they also built on WebKit instead of Gecko. Eventually they forked WebKit and created Blink. Opera used to have their own engine, but they eventually dropped it to use Blink (through a customized version of Chromium ). Edge recently did the same thing.

Android’s WebView was originally based on WebKit, but it switched to Blink beginning with Android 4.4 (KitKat, API 19). Originally, WebView was only updated with Android releases. But beginning with Android 5.0 (Lollipop, API 21), Google refactored the code so that WebView could be updated via an APK through the Play Store. Beginning with Android 7.0 (Nougat, API 24), Google allows different apps to provide the WebView library. Because the current WebView is built from the same code base as Chromium, by default the Chrome package provides Android’s WebView (if it is installed). Otherwise, the Android System WebView package provides it.

WebView is limited in the privacy controls it exposes to developers. For example, it isn’t possible to enable some JavaScript commands and disable others. It isn’t possible to disable WebRTC while JavaScript is enabled. It isn’t possible for some tabs to proxy through Orbot while other’s don’t. It isn’t possible to customize the CSS of a website without having JavaScript enabled. It isn’t possible to customize the user agent on resource requests. And it isn’t possible to spoof a large majority of fingerprinting information, like screen size, the system font list, and the canvas hash. Because of this, in the 4.x series of Privacy Browser I intend to create a rolling fork of WebView called Privacy WebView. This rolling fork will be composed of a set of minimally invasive patch files that add additional privacy controls without breaking API compatibility for existing commands. These patches will be rebased with each release of WebView. It is an ambitions project, and it will be quite time consuming, but it has a number of advantages.

  1. It is a lot simpler than creating an entirely new rendering engine.
  2. It will be API backwards compatible with Google’s WebView, which means that users can set it as the default WebView provider for all apps on their device.

Some people have suggested I consider using Bromite SystemWebView or GeckoView instead. Those who like GeckoView are usually primarily attracted to the idea of removing as much Google as they can from their lives. Although I am generally in favor of that idea, I do not feel that GeckoView is a good fit for Privacy Browser for the following reasons.

  1. GeckoView is not API compatible with WebView. This means a significant portion of Privacy Browser’s code would have to be rewritten (there are a lot of little bugs in getting a rendering engine to work correctly with things like domain settings). Not that I am opposed to refactoring code, but there has to be a significant benefit at the end of the tunnel to make it worth it.
  2. GeckoView does not expose a significantly greater portion of the privacy settings I need than Android’s WebView. As such, I would still be stuck creating a rolling fork of GeckoView with the same level of time commitment.
  3. Because GeckoView is not API compatible with WebView, a custom fork could not function as a drop-in replacement for Android’s WebView. Although this is not an absolute necessity, it is one of the nice things I am trying to accomplish with Privacy WebView.
  4. I don’t trust Mozilla much more than I trust Google. As a long time user of Firefox since the days it was called Phoenix, I have watched them go downhill and consistently make decisions that are not in the best privacy interests of their users. For example, if they really cared about user privacy they would incorporate their blocklists from Firefox Focus into the main Firefox product and apply them to all websites. But they won’t do this because they make hundreds of millions of dollars every years through their search contracts, and the search companies are not going to pay them that type of money if the tracking of users’ searches are blocked.
  5. I have significant concerns about Mozilla’s commitment to the Android ecosystem. If I rebase Privacy Browser on GeckoView, and down the road they decide it isn’t in their strategic interests to maintain it, I’ll be up the proverbial creek without the proverbial paddle.

As I mentioned at the top of this post, I am open to changing my mind about GeckoView (or any future rendering engine). But it doesn’t currently look like a good match for Privacy Browser.