Privacy Browser

Privacy Browser 2.8.1

Privacy Browser 2.8.1 has been released. This is a bug fix release to work around a problem in recent versions of WebView that made it so that cookies were not consistently flushed to permanent storage. This broke functionality for users who needed to permanently save cookies to make certain websites work as desired.

Privacy Browser


I receive questions about WebRTC (Web Real-Time Communication) frequently enough that I thought it would be worthwhile to write a post about it.

First, a little bit of background about WebRTC for those who might not be familiar with it. It is a web standard for enabling video and audio chat in the browser. WebRTC connections are typically brokered by a server, but to enable efficient communication of audio and video, the clients exchange their IP information so they can communicate directly. Depending on the configuration of the software involved, if a user is trying to mask their IP address, WebRTC can be used by a server to discover their true IP addresses (both private and public IPv4 addresses as well as the IPv6 address).

WebRTC requires JavaScript to function. By default, JavaScript is disabled in Privacy Browser. So, those who use Privacy Browser with the default settings do not need to be worried about WebRTC leaking their IP addresses.

Some users have Tor Orbot proxy enabled or are otherwise using a VPN to mask their IP address but also need to have JavaScript enabled for some websites. By default, Orbot runs in proxy mode. The proxy controls in Android’s WebView allow proxying of general HTTP and HTTPS data but not WebRTC. In this configuration Privacy Browser will leak IP addresses through WebRTC when connected to Orbot. However, Orbot can also run in VPN mode, which will force all traffic from the device over Orbot.

When Orbot is in VPN mode, Privacy Browser does not leak any IP address information via WebRTC as demonstrated by this screenshot from Browser Leaks. The key in the status bar at the top of the screen indicates that VPN mode is enabled. The local IP address listed is not the local IP address of the device, but rather the local IP address assigned by Tor, which in this case is

Other VPN services will also mask the WebRTC IP address if they are configured correctly. Of course, the downside to using a VPN service is that then they can spy on everything you do and sell the information to the highest bidders.

There are some browsers that have support for disabling WebRTC completely, so that it can’t leak IP address information under any circumstances. Orfox and Fire.onion are two examples. Both of these browsers are modified versions of Firefox, and, as such, are able to disable WebRTC in the Gecko rendering engine. Privacy Browser currently uses Android’s built-in WebView as the rendering engine. Google does not provide a mechanism to disable WebRTC in WebView. However, in the 4.x series, I intend to create a rolling fork of WebView called Privacy WebView that will allow WebRTC to be completely disabled even when JavaScript is enabled.

To round out this conversation, I think it is important to point out that masking one’s IP address does not provide as much privacy as many people assume. The large technology companies have spent a lot of money building massive profiles of users, even those who are not their customers. These profiles contain much more detailed location information than an IP address discloses. And these systems are specifically designed to track users across IP addresses, because they want to track people from their homes, to their work, and across cell phone networks. Many of the technologies that companies use to track users are dependent on client devices running JavaScript. Blocklists like EasyPrivacy, which are included in Privacy Browser, are able to block some of this tracking, but they are not perfect. For users that need real privacy, the best defense is to browse the internet with JavaScript disabled.

Privacy Browser Roadmap

February 2018 Roadmap

It isn’t my intention to publish an update to the roadmap every February. Rather, it just so happens that the project has crossed a major milestone and it is appropriate to update everyone on what to expect next. And it also just so happens that it is February again.

With the release of Privacy Browser 2.8, work will now begin on the second half of the 2.x series. This will include features like a public download location, file upload, and import and export of settings and bookmarks that are dependent on the dangerous READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE file permissions. These permissions have been part of the roadmap of Privacy Browser since the beginning of the project. But I have delayed their implementation at the request of users because of potential security implications on devices running versions of Android older than Marshmallow (API < 23). No other permissions are planned to be added to Privacy Browser in the future (and any new addition would only be considered if the benefit were great and there were no negative privacy implications).

The potential security implications are as follows. A malicious entity discovers a bug in Android’s WebView that allows them to run arbitrary code in the context of Privacy Browser. This has happened with WebView in the past and is why, beginning with Privacy Browser 1.7, the minimum supported version of Android was bumped to KitKat. It is likely that taking advantage of any such flaw would require JavaScript to be enabled, which is one of the reasons that browsing with JavaScript disabled is so important for user privacy. It is also likely that a malicious actor could keep knowledge of an exploit hidden for a significant amount of time, as has happened with the NSA and their exploit of the Tor Browser. A successful exploit of WebView would gain full access to all of Privacy Browser’s permissions. If Privacy Browser has READ_EXTERNAL_STORAGE permissions, they could read any public file from the device.  If it has WRITE_EXTERNAL_STORAGE permissions, they could modify any public file on the device.

On devices prior to Android Marshmallow, if a permission is listed in the manifest, the user has no way to disable it. Beginning with Android Marshmallow, permissions that Google considers dangerous require the user to manually enable them on a per-app basis after the app is installed. Users that suspect they may be directly targeted by a government actor or someone else with similar resources (hopefully a minority of users) would be advised to not enable these permissions.

In July 2016, according to Google Play only 16.9% of Privacy Browser’s users were running devices with Android Marshmallow (API 23). As of 21 February 2018, 86.4% are running Android Marshmallow or newer. These stats only show devices that have downloaded the paid version of Privacy Browser from Google Play and still have it installed, but I would imagine that those who got it from F-Droid and XDA Labs are running a comparable set of devices. For those still on older versions of Android, Privacy Browser can continue to provide a more private and secure browsing experience than most other browsers.

After dealing with the surprising difficulty in integrating EasyList into Privacy Browser, I am a little hesitant in forecasting how long it will take to finish the 2.x series. However, I would like to have it done and begin working on tabbed browsing in the 3.x series this year. Privacy WebView and the 4.x series will follow.

Privacy Browser

Privacy Browser 2.8

Privacy Browser 2.8 has been released. EasyList, EasyPrivacy, Fanboy’s Annoyance List, and Fanboy’s Social Blocking List are now used for ad and tracker blocking. This was a significant transition that required much more time than I had anticipated going into it. But the results in terms of user privacy are significant.

The previous ad blocking list, provided by, only checked the domain name to decide if a request should be blocked. EasyList uses the Ad Block Plus syntax, which blocks against patterns in the entire URL. This provides significant privacy protection against tracking even when JavaScript is enabled, as shown by the Panopticlick screenshot below (although, for maximum protection, I would still recommend disabling JavaScript except for trusted websites).

In the future, I am planning to add the option to manage the block lists in domain settings, see details about the resource requests that were blocked, allow users to update the block lists from EasyList directly without waiting for an update to Privacy Browser, allow users to load other block lists that use the Ad Block Plus format, and create a custom block list that overrides entries in the other block lists.

As part of Panopticlick, the EFF has a check for unblocking third-parties that promise to honor Do Not Track. I have written before about how I believe Do Not Track is privacy theater. Instead of automatically unblocking websites that promise not to track users, I would rather that the users makes a conscious decision to unblock the website based on their personal trust of the organization that runs it. This will be possible with the upcoming controls to manage the block lists in domain settings and use a custom user block list.

Advanced controls for browser fingerprinting will become available in the 4.x series with the release of Privacy WebView. Until then, browsing the internet with JavaScript disabled mitigates a significant portion of browser fingerprinting technology.

Part of what made integrating EasyList difficult was figuring out a way to do so that didn’t significantly degrade performance. For those who are interested, I have written an extensive description of how the block lists are parsed and processed. The performance takeaway is that on a Nexus 6P loading the block lists adds about 3 seconds to the launch time of Privacy Browser. This delay happens every time Privacy Browser is launched from scratch, like after selecting Clear and Exit or rebooting the device. It doesn’t happen when switching between Privacy Browser and other apps. I do not consider this to be an acceptable delay, but I have not yet found a way around it. On the other hand, checking a resource request against the block lists only takes about 20-30 milliseconds, which meets my expectations and is fast enough to not be noticeable.

There is also a new View Source activity. It is launched from the options menu.

Android’s WebView makes it difficult to access this information, so for right now this is an imperfect implementation. This should be resolved in the 4.x series with the release of Privacy WebView.

The Clear Data options menu items have been moved to a submenu. The motivation for this change was that the options menu is getting full, the three clear data entries all relate to the same general action, and my guess is they are not used as often as some of the other entries. Instead, I think the majority of people use the Clear and Exit navigation menu entry.

The Add to Home Screen options entry has been updated to work with Android Oreo. A bug with the color formatting of the URL text box was fixed. The privacy policy was updating to clarify the wording of when Stoutner may shared information. The updated section now reads, “Stoutner may use this information to assist in the development of Privacy Browser and communicate the status of the project to users.”

Privacy Browser now includes a partial Russian translation provided by someone who prefers to remain anonymous. The strings have all be translated. The Guide and About activities will be translated in a future release.

As usual, Francesco Buratti provided an updated Italian translation and Jose A. León provided an updated Spanish translation.

This is the last release in the first half of the 2.x series. Beginning with Privacy Browser 2.9, permissions for reading and writing to external storage will be added. I anticipate that the next release will add controls for block lists to domain settings and make the default download location public.

Privacy Browser Security and Privacy Canary

2017 Security and Privacy Canary


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

During 2017, Stoutner inserted 0 backdoors into Privacy Browser.


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

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

Legal Requests for Information

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

During 2017, 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.7.2

Privacy Browser 2.7.2 has been released. The impetus for this release is a fix for a problem that prevented 2.7 and 2.7.1 from being built on F-Droid. Slightly before the release of 2.7, Android Studio was upgraded from 2.x to 3.0. This upgrade changed the way the Gradle build system plugins integrate with Android Studio. Previously, the build plugins were downloaded manually using the SDK download manager. With the release of 3.0 this was switched to using a Maven repository specified in the Gradle build files that pulled the necessary files from Google’s server at build time. The instructions on some of Google’s websites were incomplete, resulting in a build.gradle file that worked for my local build system but didn’t work for the F-Droid server.

Two features that were planned for the 2.8 release are included in 2.7.2 as they are already complete and there is no reason to make people wait. The first feature is an options menu item for adding/editing the domain settings for the current domain. This option is placed at the top of the menu.

The second feature is support for opening telephone links in the system dialer. The number is passed to the Android OS with a request that whatever app is the default dialer receive it. The dialer displays the telephone number on the screen but does not call it until the user presses a button. Previously, tapping on telephone number links in Privacy Browser would produce an error.

Privacy Browser

Privacy Browser 2.7.1

Privacy Browser 2.7.1 has been released. It fixes a crash in version 2.7 when editing a bookmark in the new bookmarks drawer. This crash was introduced late in the development cycle after I had finished testing this feature. It was kindly pointed out by a user shortly after 2.7 was released.

Privacy Browser

Privacy Browser 2.7

Privacy Browser 2.7 has been released. The bookmarks are now accessible from a DrawerLayout on the right of the screen:

Tapping on a bookmark will load it. Long-pressing on a bookmark will open an edit dialog. As can be seen from the screenshot, there is now a create folder floating action button above the create bookmark button. The top floating action button opens the bookmarks activity.

A number of improvements have been made to the bookmarks activity. Moving bookmarks is now much more efficient, which should remove the delay that was previously experienced. The bookmarks display order is now updated upon deletion of a bookmark, which keeps new bookmarks from being created in the middle of the list after a number of bookmarks have been deleted. A number of action buttons in the dialog boxes are now disabled if there is no action for them to perform.

The “move to folder” icon is now an arrow inside of a folder. Previously it was a star inside of a folder.

Deleting bookmarks rapidly used to confuse Privacy Browser (because it waits until the Snackbar is dismissed before processing the delete). The delete menu item is now momentarily disabled until the previous delete has processed. When bookmarks are deleted and then undeleted, they are now reselected. Privacy Browser is now more sophisticated about scrolling the screen when moving bookmarks. Previously it would lock the bookmark being scrolled five items from the top of the screen. Now it lets the bookmark float naturally through the screen and scrolls when the bookmark reaches the top or bottom.

In the bookmarks database view, it is now possible to filter the bookmarks by folder. The database view will become more important when bookmarks can be imported and exported. Although there should never be any problems® with the bookmarks database, the database view provides a powerful repair tool when they do happen.

It is now also possible to edit bookmarks from the database view.

Some improvements were made to Night Mode to eliminate the white flash that sometimes occurred when a new page was loaded. They keyboard is now hidden every time a new webpage is loaded.  Previously it was only hidden if the webpage was loaded from the URL box. The target API has been bumped to 26 (Android Oreo, 8.0.0) and the user agents have been updated. Konqueror was removed as one of the pre-configured user agents, as it is being discontinued and its replacement, Falkon, is not yet ready. The fastlane screenshots have been adjusted, so that hopefully they will finally work on F-Droid with this release.

The paragraph about Verizon’s tracking header has been removed from the Tracking IDs section of the Guide because, due to public pressure, Verizon no longer abuses their customers in this manner.

As usual, Francesco Buratti provided an updated Italian translation and Jose A. León provided an updated Spanish translation.

The next release will likely be the last in the first half of the 2.x series. The major planned feature is to switch the ad blocker to use EasyList.

Privacy Browser

Privacy Browser 2.6

Privacy Browser 2.6 has been released. There is a new night mode for rendering web pages. The night mode overrides certain CSS layout options to create an experience that works well on the majority of websites, especially when paired with the dark theme.

Injecting the custom CSS currently requires JavaScript to be enabled (obviously not desirable from a privacy perspective). When Privacy WebView is released as part of the 4.x series, it will become possible to modify the CSS of the website without enabling JavaScript.

While the website is loading, it is hidden and a dark gray background is displayed. The following CSS code is applied to the website after it has finished loading.

* {
    background-color: #212121 !important;
    color: #BDBDBD !important;
    box-shadow: none !important;
    text-decoration: none !important;
    text-shadow: none !important;
    border: none !important;

a {
    color: #1565C0 !important;

* formats all elements with the following characteristics. background-color: #212121 sets a dark gray background. color: #BDBDBD sets the text to be a light gray. box-shadow: none removes a form of underline that some websites use for links. text-decoration: none removes the standard underline used for links. text-shadow: none removes text shadows (which don’t often match well against the dark background). border: none removes borders around text and other objects.

a formats links. color: #1565C0 sets the text color to be a dark blue.

!important overrides any more specific directives that may exist unless they also have the !important tag.

Feel free to contact me if there are other CSS attributes that would improve night mode. I am generally inclined to only include tags that work across a large range of websites. After the CSS is applied, there is a 500 millisecond delay before the WebView is displayed. In my testing that is sufficient time for the night mode CSS to be rendered and prevents the brief flashing of a white background when the site is first displayed. However, the time may need to be increased for some devices, especially those with slower processors.

The About and Guide activities have been reworked so that the dark theme displays them in the same way that night mode displays normal websites.

It is now possible to visit websites that require HTTP authentication.

The View SSL Certificate dialog now color codes the Domain and the Common Name. If they match the text will be blue. If they do not match it will be red.

Francesco Buratti provided an updated Italian translation and Jose A. León provided an updated Spanish translation.

The next release of Privacy Browser will feature several refinements to the bookmarks interface.


Privacy Browser

User Agent Problems

Some websites don’t work well if they don’t recognize the user agent. Much has been written about how browser detection is a flawed system, but some websites still do it. For Privacy Browser, this means that if the default user agent of PrivacyBrowser/1.0 is used, some aspects of certain websites won’t work because the web server doesn’t have PrivacyBrowser/1.0 on the list of user agents that it knows can run a specific feature, so the webserver doesn’t even try to do it, even though Privacy Browser is perfectly capable of handling the feature.

So, for example, doesn’t allow the user to log on if the user agent is PrivacyBrowser/1.0http://hss3uro2hsxfogfq.onion/ loads an entirely blank screen if it doesn’t recognize the user agent. Google doesn’t redirect from HTTP to HTTPS if it doesn’t recognize the user agent, and the Google Play Console doesn’t layout correctly.


WebView Default


WebView Default

Setting a user agent in domain settings that the website recognizes, like WebView Default, resolves the issue.