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.

Updated Priorities in the Issue Tracker

I updated the priorities of the issues in Redmine to match the February 2017 roadmap. The priorities carry the following meanings.

  • High applies to the first half of the 2.x series.  All these will be implemented (except for those waiting on a third-party fix) before the addition of the READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE dangerous permissions.
  • Medium applies to the second half of the 2.x series. All these depend on the addition of these dangerous storage permissions. I expect to begin work on these issues in the second half of 2017.
  • Low applies to the 3.x and 4.x series. I would expect 3.0 to be released sometime in 2018.

In general, my design philosophy is to polish off one set of features before moving on to the next set. This is why, for example, there are several issues relating to polishing the bookmarks and domain settings included in the high priority. Not taking time to polish existing features, but constantly rushing on to the next hot thing, is what leads to the morass of poor software that assaults us from almost all sides.

In deciding which order to implement features, I am guided by the following general principles.

  1. Implement privacy features first.
  2. Implement those that are quick and easy before those that will require significant investment.
  3. Prioritize items that are most important to users within the framework of 1 and 2.

From time to time I hear from users, including my wife, who wonder why tabbed browsing is pushed all the way back to version 3. The answer is that the tabbed browsing I intend to implement is quite complicated and will require a large amount of coding. It will also require a lot of work to make sure that the privacy features apply correctly to each of the tabs, especially when tabs have different settings. It makes sense to me to postpone it until after the privacy related features in the 2.x series, which are quicker to implement, have been completed.

February 2017 Roadmap

I thought it would be valuable to lay down a development roadmap.

When I first envisioned Privacy Browser, I thought of a browser that would make it easy to disable JavaScript and other privacy sensitive settings and turn them on only for websites I trusted. With automatic controls by domain, it feels that Privacy Browser will have matured sufficiently to bump the version number to 2.0.

Most Android browsers’ implementation of tabs are more like quick bookmarks with large thumbnails than real tabbed browsing. My plan is to use a TabView (similar to the Guide and About sections). There are several complexities with doing so, including managing separate privacy settings for each tab, that make this more difficult that might initially appear. That is why the implementation is pushed all the way to version 3.0. But the final result should be a fully usable tabbed interface that scales well from small phones all the way to laptops and desktops.