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

Leave a Reply

Your email address will not be published. Required fields are marked *