Problems with Orbot

There is a bug with the most current version of Orbot (16.0.2-RC-1) that causes HTTP proxying to fail (HTTPS proxying works just fine). That means that webpages that begin with https:// will load just fine but webpages that begin with http:// will not.

I have filed a bug report with the developers of Orbot.

There are two workaround you can use until they release an update that fixes the problem.

  1. Downgrade to version 16.0.0-RC-2 of Orbot, which works fine.
  2. Enable Orbot’s VPN mode and disable Privacy Browser’s Orbot proxy setting.  Privacy Browser’s URL bar background will not be blue, but all traffic will be routed through Tor because of the OS level VPN. The potential downside to this workaround is that all the device’s traffic is being forced through Tor, which may not be desired.

Note that there was a separate bug that was fixed in Privacy Browser 2.11 that related to using Orbot.

Privacy Browser 2.11

Privacy Browser 2.11 has been released. The major new feature is a Requests activity that shows how many requests were made and how many were blocked.

Tapping on an individual request displays further details.

The Requests entry in the navigation menu displays the number of blocked requests.

I have written some information about how the blocklists work. The next release will include a Guide tab that explains each of the items in the request details. Note that in the future it will be possible to create custom user blocklists and load any blocklist that use the AdBlock syntax.

A bug, introduced by a change in a recent update of WebView that prevented proxying through Orbot, was fixed. This bug caused proxying to silently fail. The URL bar background would turn blue, Orbot would launch, but unless Orbot was functioning in VPN mode, WebView would send all requests directly to the internet.

Screenshots, video recording, and viewing on non-secure displays are now disabled by default. For those who need it, this functionality can be enabled in settings. Note that because of limitations in Android, some information, including menus and the keyboard, can be captured by screen recordings even when this setting is disabled.

Swipe to refresh is now available in domain and on-the-fly settings.  Additionally, if “display additional app bar icons” is enabled in settings, the refresh button is now displayed in the app bar.

Beginning in Android Oreo (API 26), form data support has been removed from WebView. It has been replaced by the Android OS autofill functionality. As such, the form data controls no longer appear in Privacy Browser when running on Android Oreo or newer. They will continue to function on older versions of Android.

A crash was fixed that was caused by viewing or loading domain settings for an empty URL.

The major feature of the next release will be the ability to block all third-party requests.

Privacy Browser 2.10

Privacy Browser 2.10 has been released. Uploading of files is now enabled for Lollipop and newer (API >= 21). Initially I thought this would require the Read Storage permission, but it turns out that beginning in Android Lollipop (API 21) Google added a system file chooser API to WebKit. This allows the browser to request the OS to display a file chooser, which has the Read Storage permission. The file chooser hands the file back to WebKit for upload. This is different than granting Read Storage permission to Privacy Browser because the user must explicitly select a file from the list; it does not allow Privacy Browser to access files in the background without user interaction.

Note that there are other planned features in the 2.x series that will probably require Read Storage permissions, like the import and export of settings and the import of bookmarks from other browsers. But I am not going to add it until it is needed. Also, note that many interfaces report the Privacy Browser has the Read Storage permission when it doesn’t. I am not certain why that happens, but it may be because the Read Storage and Write Storage permissions are linked under the Storage dangerous permission. Such that if a user grants the storage permission for Write Storage and later the app adds the Read Storage permission to the manifest it will be granted without further user interaction or notification.

As a personal milestone, the feature request to add file uploads was the first issue entered into Redmine. When I setup Redmine on 2 March 2016 Privacy Browser 1.0 had just been released. I created 15 feature requests that day to track items I knew I wanted to add. They weren’t entered in any particular order, but it turns out that the uploading of files was number 1. The oldest issue still open is number 5, fine-grained cookie controls, which, because of limitations in WebView, will have to wait until the 4.x series to be implemented.

This update changes the way user agents are stored and updated. In the past, when a user agent was set to mimic a different browser, it was for a specific version, like Firefox 56 on Windows 10. When the sample user agents were updated in a later release of Privacy Browser, the selection would remain Firefox 56 on Windows 10. This sort of defeated the purpose of making Privacy Browser mimic another browser because repeated user intervention was required to keep it updated.

With the new design, the user will select a generic setting, like Firefox on Windows. A separate list is maintained with the current user agent that matches this selection. When the list is updated with a new release, it will automatically be applied. For users who have already selected an older style user agent, it will stay that way until they select one from the new list.

There is now a Download URL entry in the context menu. This makes it possible to download files that Privacy Browser would otherwise display, like HTML or text files.

For those in Europe using Privacy Browser Free, a new ad consent dialog will display on first launch to comply with the GDPR. The dialog is also accessible from the options menu. There is an accompanying update to the privacy policy.

The GDPR has forced Google to create several privacy controls for their ad network that didn’t previously exist. I have used these controls to disable personalized ads and to disable tracking and remarketing for all users (by specifying that the user is under the age of consent, because maybe you are and it is better safe than sorry ).

A bug introduced in version 2.9 that prevented bookmarks from being loaded from the Bookmarks activity (but not from the bookmarks drawer) has been fixed. And a bug was fixed that caused some changes in domain settings to not be applied until after a reload. The workflow was also improved when adding or editing domain settings from the options menu.

Google’s Firebase library, used to display ads in Privacy Browser Free, keeps adding extra permissions at build time. The latest addition, READ_PHONE_STATE, is particularly annoying because it grants access to the phone number of the device, the current cellular network information, the status of any ongoing calls, and a list of any PhoneAccounts registered on the device. This is a dangerous permission, which requires explicit user interaction on Android Marshmallow and newer (API >= 23). In my testing I have not seen advertisements attempt to request or use this permission (I have seen them attempt to use the GPS permission, which is one of the reasons I am inclined to never add that one to Privacy Browser). I have considered getting rid of the Free version entirely, but I feel that it is a good way for many users to try out Privacy Browser before deciding if they want to commit to the paid version or learn how to use F-Droid.

Firebase has also added the com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE. There isn’t much information online about what this permission does, but it appears to be used to tell from which source an app is installed. So, an advertisement would be able to tell if Privacy Browser Free was installed from Google Play, XDA Labs, Amazon, or directly from Stoutner.com. There is some indication that this might be removed in the next version of Firebase (it has been removed in Google Play Services 15.0.2), but we will have to wait and see.

As usual, Francesco Buratti has provided an updated Italian translation and Jose A. León Becerra has provided an updated Spanish translation. There is also an anonymously updated Russian translation. This translation work takes a significant amount of effort and those who speak these languages should be grateful for their work.

The Block List activity was planned for the 2.10 release, but it was pushed off due to the need to release changes in time for the GDPR deadline. It will be the major feature in the next release.

Privacy Browser 2.9

Privacy Browser 2.9 has been released. The major change is that the write storage permission has been added as was previously announced in the roadmap. This allows downloads to be stored in the public download directory, and will also allow for a number of other planned features, like the import and export of settings.

It is now possible to control the block lists in domain settings. This allows a block list to be disabled if it there is a false positive on a particular domain or if the user wants to financially support the domain by viewing ads.

Custom URLs are now referred to a chooser to open in other apps. This allows, for example, market:// URLs to open an app store or oauth2redirect:// URLs to complete the Mastodon signup process.

A bookmarks tab has been added to the Guide. Some users, understandably, have difficulty finding the bookmarks. Hopefully, this will point them in the right direction.

Privacy Browser now has an adaptive icon. This is something I initially resisted doing, but it is the way everything is going on newer devices. It also allows me to replace the bitmap launcher icons with vector ones, which are smaller and allow for perfect layout on all devices.

There is now an explicit warning for users of Incognito Mode that forward and back do not work when it is enabled. Previously it wasn’t clear to many users that if the history was deleted forward and back would not work.

The favorite icon is now preserved when returning from the settings or domains activities. Cookies are now no longer erroneously deleted in Incognito Mode. And the webpage is no longer reloaded when restarting Privacy Browser from the launcher.

Privacy Browser 2.9 contains the first full Russian translation. Francesco Buratti provided an updated Italian translation and Jose A. León Becerra provided an updated Spanish translation. Stefan Erhardt provided a partially updated German translation. I am grateful for all their time and effort.

The next release of Privacy Browser will add the read storage permission which will allow for the uploading of files to websites. It will also have a block list activity that shows details about every request that is blocked. This will be useful for determining if a resource is incorrectly blocked, as well as for ascertaining what websites are doing to track users.

WebRTC

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 is always 10.10.10.1.

If a different VPN service is being used, setting it to run in full tunnel mode (as opposed to split tunnel) will have the same effect of masking the IP addresses.

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

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

Backdoors

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.

Privacy

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.