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.