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 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 pgl.yoyo.org, 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.

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


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, neweggbusiness.com 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.

Privacy Browser 2.5

Privacy Browser 2.5 has been released. It adds support for SSL certificate pinning in the domain settings. There is also a new Guide tab to explain the feature, which contains the following text:

When visiting an encrypted URL (one that begins with HTTPS), the webserver uses an SSL certificate to both encrypt the information sent to the browser and to identify the server. The purpose of the server identification is to prevent a machine located between the browser and the webserver from pretending to be the server and decrypting the information in transit. This type of attack is known as a Man In The Middle (MITM) attack. SSL certificates are generated by certificate authorities: companies that verify a server’s identity and produce a certificate for a fee. Android has a list of trusted certificate authorities, and will accept any of their certificates for any website. It isn’t supposed to be possible for an organization to acquire an SSL certificate for a domain they do not control, but in practice many governments and large corporations have been able to do so.

The purpose of SSL certificate pinning is to tell the browser that only one specific SSL certificate is to be trusted for a particular domain. Any other certificate, even if it is valid, will be rejected.

SSL certificates expire on a specified date, so even pinned SSL certificates will legitimately need to be updated from time to time. As a general rule, pinning SSL certificates probably isn’t needed in the majority of cases. But for those who suspect that powerful organizations may be targeting them, SSL certificate pinning can detect and thwart a MITM attack.

SSL certificates can be pinned in Domain Settings. Besides protecting against MITM attacks, pinning a self-signed certificate for a device like a wireless router or access point will remove the error message that is normally presented every time its website is loaded.

Searx.me was added to the list of default search engines, and the list was reorganized so that the privacy conscious search engines are listed before the others.

The default homepage has been updated to https://duckduckgo.com/?kao=-1&kak=-1, which works with both JavaScript enabled or disabled. This change will only affect new installations of Privacy Browser. Current users can chose to update their homepage if desired. The Onion site, https://3g2upl4pq6kufc4m.onion, is still broken when using the center search box unless JavaScript is enabled. Those who use this functionality might consider adding their voices to the Reddit thread on this topic.

A bug was fixed that caused the website title to be lost on rotate (and in some other circumstances). The website title is used when sharing a URL.

The options menu now indicates (via ghosting) if there is any DOM storage data that can be cleared. Previously, the entry was always enabled because WebView does not provide an easy way to tell if DOM storage data exists.

In the previous release, unencrypted websites were highlighted with a bold, red “http://” at the beginning of the URL. At the request of a user, the bold was removed and it is now just red text.

A bug was fixed that caused a URL to fail to load if a custom domain user agent was applied and the website performed a redirect on load. Another bug was fixed that caused changes a the website (like the sorting of a list) to be lost if Privacy Browser was moved to the background or otherwise restarted. Many small improvements were made to the Domains activity that should provide a smoother user experience.

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

The next release of Privacy Browser will enable HTTP authentication requests and implement a night mode.

DuckDuckGo Search Problems

There is currently a problem with searching using the search box in the center of the screen on both https://start.duckduckgo.com and https://3g2upl4pq6kufc4m.onion when JavaScript is disabled.

Searching from the URL bar works correctly. I have reported this bug to DuckDuckGo in two places. If they are not able to fix it soon I may have to do something different with the default homepage.

In the meantime, users can work around the problem by using https://duckduckgo.com as the homepage if JavaScript is disabled, or using a domain setting to enable JavaScript for *.duckduckgo.com or 3g2upl4pq6kufc4m.onion.

Update: the problems with https://start.duckduckgo.com have been resolved by switching the default homepage to https://duckduckgo.com/?kao=-1&kak=-1. The problems with https://3g2upl4pq6kufc4m.onion remain and DuckDuckGo seems uninterested in fixing them. For the time being I have left it as the default Tor homepage because it confirms that Tor is working when it loads, but if any of the other search engines produces a .onion search page that works with JavaScript disabled I will switch to them instead.