Categories
Privacy Browser

Problems with Redmine

March 14 Update: Redmine is working again.

There is a bug in the current Debian Redmine package that prevents users from being able to log into the site. I have reported the bug to the package maintainers, but it is uncertain how long it will take them to upload a fixed version. Currently we can view the status of existing bugs and feature requests but not make any changes. Until Redmine is fixed, users may submit bug reports in the comments to this post or by emailing them to me.

Categories
Privacy Browser

Privacy Browser 2.17.1

Privacy Browser 2.17.1 has been released to address a bug that caused Privacy Browser to crash if a bookmark was created with a very large favorite icon. This bug has existed ever since bookmarks were added to Privacy Browser in version 1.8, but nobody ever noticed until now because most websites are polite enough not to post full size photographs as their favorite icons.

This release also adds a line to the manifest that allows the user to move the APK to the SD card. By default, the OS does not allow apps to be moved. But I am all in favor of users having the choice to do so if they desire.

Categories
Privacy Browser Roadmap

3.x Series Roadmap

The release of Privacy Browser 2.17 marks the end of the 2.x series (unless a serious bug is discovered that needs to be addressed). The 3.0 release will implement the long awaited tabbed browsing. Following that, all other features that can be implemented without Privacy WebView will makeup the body of the 3.x series. At any time, users can see which features are planned for the next release and the list of all remaining features for the 3.x series.

With the 4.x series, the plan is to create a rolling fork of Android’s WebView, called Privacy WebView, that will add missing privacy features. Once the 4.x series is implemented, I plan to start working on Privacy Browser for other platforms. My initial thought is that I can develop it using the Qt framework and QtWebEngine, which will allow me to use one code base for Linux, Windows, and macOS. However, I will do a deeper investigation of the options and make a final decision when we get closer to that point.

Categories
Privacy Browser

Privacy Browser 2.17

Privacy Browser 2.17 has been released. The app bar now scrolls off the screen when the WebView is scrolled down and reappears when the WebView is scrolled up. This was an important prerequisite in preparation for tabbed browsing, as the tab interface will take additional screen real estate that would be bothersome if it couldn’t be hidden by scrolling. App bar scrolling can be disabled in the settings for those who do not want it. The full screen browsing options were simplified to work with app bar scrolling.

There is a new Logcat Activity. This displays the logs that Privacy Browser can collect about itself without needing any special permissions. It is useful for figuring out what caused a crash. Depending on the cause and the permissions needed to see the information, not all crashes will be displayed in the Logcat. The screenshot below shows a crash caused because Android’s over-aggressive memory management decided to wipe out one of the blocklists while it was being used.

Users can now specify the URL and which browser to open when creating a desktop shortcut.

The link and image context menus now have options to open directly with an app or another browser.

Default apps can now be set from the open with app chooser.

A bug was fixed that caused Privacy Browser to apply URL syntax highlighting to text a user was typing if they started typing it while a website was loading. Another bug was fixed that would display the pinned mismatch dialog if the IP addresses were pinned and they had not yet been acquired by Privacy Browser when the website finished loading. Because the IP addresses usually were populated by the time the dialog was fully displayed, this would show a pinned mismatch dialog with no mismatching information.

Google’s Android Support Library, which is no longer maintained, was replaced with the new and shiny AndroidX libraries. This is basically a rename on Google’s part. These libraries backport newer Android features so they work on older Android devices, as we all know how miserable most OEMs are at updating Android after a device is released.

We have a new German translator, Bernhard G. Keller, who updated all the German strings for this release and will be working on the Guide and About for the next release. Progress is also being made towards the first full Turkish translation. The Italian translation was updated by Francesco Buratti. The Spanish translation was updated by Jose A. León. And the Russian translation was updated.

Unless there is a critical bug that needs to be fixed, this is the last release in the 2.x series. The 3.x series will begin with the much anticipated addition of tabbed browsing.

Categories
Privacy Browser

Privacy Browser 2.16

The release of Privacy Browser happened earlier than I anticipated due to a need to fix an urgent bug, introduced in 2.15, that caused SSL certificate pinning to be ignored unless navigating history using the forward/back buttons or the history list. Not all of the planned features for 2.16 had been completed when this bug was discovered, but enough of them had been that I decided to release what was ready as 2.16 and push the rest off until the next release.

IP address pinning has been added to compliment SSL certificate pinning. This can provide protections against scenarios where DNS servers have been hijacked or redirected to provide bogus IP addresses. There have also been improvements to the layout of the SSL certificates in domain settings.

The current IP addresses are also now displayed in the View SSL Certificate dialog.

There are new menu items for opening a website with apps and other browsers. If an app is specified as the default for a particular schema it will be opened directly. Otherwise, the user will be presented with a list. If no app has specified an intent for the schema, it will reopen with Privacy Browser

These options are found under the new Share options menu.

The WebView night mode text selection color has been improved.

There have been various improvements to the bookmarks database view activity. There have also been some changes to some of the strings that reference numbers to make them easier to translate.

The Italian translation was updated by Francesco Buratti and the Spanish translation was updated by Jose A. León. The Russian translation was also updated and the partial Turkish translation is getting closer to being complete.

The next release of Privacy Browser will allow for scrolling the app bar and viewing crash logs, which should be a big help in troubleshooting problems. Baring unforeseen circumstances, I expect it to be the last release of the 2.x series.

Categories
Financial Reports Privacy Browser

2018 Financial Report

Going forward, I thought it would be helpful to post a yearly financial report on the growth of Privacy Browser.

Revenue

  • Google Play: $344.09
  • Google AdMob: $101.57
  • PayPal: $39.06
  • Bitcoin: $24.10
  • Amazon: $1.37

Total Revenue: $510.19

Google Play revenue comes from selling the standard flavor on Google Play. Google AdMob revenue comes from the display of ads in the free flavor, regardless of the distribution method. PayPal revenue comes mostly from selling the standard flavor on XDA Labs, although sometimes I also receive PayPal donations. Bitcoin revenue comes mostly from donations, although it is possible to purchase the standard flavor on XDA Labs using bitcoin. Amazon revenue comes from selling the standard flavor on the Amazon Appstore.

Install Base

Google Play reports some fairly detailed statistics about installations. The other distribution methods (F-Droid, XDA-Labs, the Amazon Appstore, and direct downloads from Stoutner.com) either do not track this information or provide only vague information. The screenshot below shows the installs of the standard flavor on active devices, which is defined as the “Number of Android devices that have been active in the past 30 days with the application installed”.

Unsurprisingly, even though there are far more installs of the free flavor, there are fewer active devices. This is because most users either decide they don’t like Privacy Browser, or they switch to using the standard flavor.

Categories
Privacy Browser Security and Privacy Canary

2018 Security and Privacy Canary

Backdoors

During 2018, Stoutner received 0 requests from governments or organizations to insert backdoors into Privacy Browser.

During 2018, Stoutner inserted 0 backdoors into Privacy Browser.

Privacy

During 2018, Stoutner received 0 requests from governments or organizations to weaken the privacy of Privacy Browser.

During 2018, Stoutner has made 0 changes to weaken the privacy of Privacy Browser.

Legal Requests for Information

During 2018, Stoutner receive 0 legal requests for information from government law enforcement organizations. These requests sought information for a total of 0 individuals.

During 2018, 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.

Categories
Privacy Browser

Privacy Browser 2.15.1

Privacy Browser 2.15.1 has been released. It is an emergency bug fix release that resolves a crash when opening a secondary activity on some devices.

Beginning with Privacy Browser 2.15, the drawer header padding is adjusted for phones with notches. The adjustment is calculated based on the height of the status bar every time the drawer moves (opens or closes). It turns out that on certain devices this creates a race condition where the new padding is applied to the header after the activity has been moved to the background and a new activity (like Settings, Guide, or About) has launched, causing a null object reference that crashes Privacy Browser. In my testing, this happens on certain devices running Android 5.0 and 5.1 (API 21 and 22) but not others, leading me to think the race condition might be caused by a combination of the OS settings and hardware speed.

The solution is to check that the views are not null before applying the new padding.

Categories
Privacy Browser

GeckoView

From time to time I receive suggestions from people that I change Privacy Browser to use Mozilla’s GeckoView instead of Android’s WebView to render pages. Instead of responding to each of these communications individually, I thought it helpful to write a general post covering this subject and explaining why I am not now considering doing so (although I am always open to it in the future if it becomes in the best interest of Privacy Browser to do so).

First, a little bit of background is necessary. The Android Open Source Project contains a standard system library called WebView that renders HTML content. It is programmatically similar to TextView, ImageView, EditText, or any of the other standard views that are included in Android. Many apps that users might not realize use this library to handle complex layouts. If WebView is removed from Android a large number of apps will crash unexpectedly.

In the open source world, there are two large pedigrees of code for rendering HTML content: WebKit (and its forks) and Gecko. Gecko is the engine developed by Mozilla and used in Firefox. Years ago, when Apple decided to make Safari they looked around at the existing code bases. They could have used Gecko, but they decided to fork KHTML and KJS (developed for KDE on Linux and used in Konqueror) and formed WebKit. When Google decided to get into the browser world they also built on WebKit instead of Gecko. Eventually they forked WebKit and created Blink. Opera used to have their own engine, but they eventually dropped it to use Blink (through a customized version of Chromium ). Edge recently did the same thing.

Android’s WebView was originally based on WebKit, but it switched to Blink beginning with Android 4.4 (KitKat, API 19). Originally, WebView was only updated with Android releases. But beginning with Android 5.0 (Lollipop, API 21), Google refactored the code so that WebView could be updated via an APK through the Play Store. Beginning with Android 7.0 (Nougat, API 24), Google allows different apps to provide the WebView library. Because the current WebView is built from the same code base as Chromium, by default the Chrome package provides Android’s WebView (if it is installed). Otherwise, the Android System WebView package provides it.

WebView is limited in the privacy controls it exposes to developers. For example, it isn’t possible to enable some JavaScript commands and disable others. It isn’t possible to disable WebRTC while JavaScript is enabled. It isn’t possible for some tabs to proxy through Orbot while other’s don’t. It isn’t possible to customize the CSS of a website without having JavaScript enabled. It isn’t possible to customize the user agent on resource requests. And it isn’t possible to spoof a large majority of fingerprinting information, like screen size, the system font list, and the canvas hash. Because of this, in the 4.x series of Privacy Browser I intend to create a rolling fork of WebView called Privacy WebView. This rolling fork will be composed of a set of minimally invasive patch files that add additional privacy controls without breaking API compatibility for existing commands. These patches will be rebased with each release of WebView. It is an ambitions project, and it will be quite time consuming, but it has a number of advantages.

  1. It is a lot simpler than creating an entirely new rendering engine.
  2. It will be API backwards compatible with Google’s WebView, which means that users can set it as the default WebView provider for all apps on their device.

Some people have suggested I consider using Bromite SystemWebView or GeckoView instead. Those who like GeckoView are usually primarily attracted to the idea of removing as much Google as they can from their lives. Although I am generally in favor of that idea, I do not feel that GeckoView is a good fit for Privacy Browser for the following reasons.

  1. GeckoView is not API compatible with WebView. This means a significant portion of Privacy Browser’s code would have to be rewritten (there are a lot of little bugs in getting a rendering engine to work correctly with things like domain settings). Not that I am opposed to refactoring code, but there has to be a significant benefit at the end of the tunnel to make it worth it.
  2. GeckoView does not expose a significantly greater portion of the privacy settings I need than Android’s WebView. As such, I would still be stuck creating a rolling fork of GeckoView with the same level of time commitment.
  3. Because GeckoView is not API compatible with WebView, a custom fork could not function as a drop-in replacement for Android’s WebView. Although this is not an absolute necessity, it is one of the nice things I am trying to accomplish with Privacy WebView.
  4. I don’t trust Mozilla much more than I trust Google. As a long time user of Firefox since the days it was called Phoenix, I have watched them go downhill and consistently make decisions that are not in the best privacy interests of their users. For example, if they really cared about user privacy they would incorporate their blocklists from Firefox Focus into the main Firefox product and apply them to all websites. But they won’t do this because they make hundreds of millions of dollars every years through their search contracts, and the search companies are not going to pay them that type of money if the tracking of users’ searches are blocked.
  5. I have significant concerns about Mozilla’s commitment to the Android ecosystem. If I rebase Privacy Browser on GeckoView, and down the road they decide it isn’t in their strategic interests to maintain it, I’ll be up the proverbial creek without the proverbial paddle.

As I mentioned at the top of this post, I am open to changing my mind about GeckoView (or any future rendering engine). But it doesn’t currently look like a good match for Privacy Browser.

Categories
Privacy Browser

Removal of Google’s Ad Consent Library

Privacy Browser 2.15 features the removal of Google’s Ad Consent library from the free flavor. This was added in Privacy Browser 2.10 to comply with the GDPR. It was never included in the standard flavor.

The Ad Consent library performed two functions. The first of which was to determine if a user was located in Europe. If so, an ad consent dialog was displayed. If the user was not located in Europe, ad consent is not legally required so the dialog was skipped and the ads were loaded.

The second function was to specify users as under-age, which causes all ads to be non-personalized and not include “remarketing”. I am not certain what Google means by that, but they do include this partial explanation on their website: “TFUA disables requests to third-party ad technology providers, such as ad measurement pixels and third-party ad servers”.

Without the ad consent library, it is only possible to set ads to be non-personalized. All app ads in Privacy Browser Free are set to be non-personalized. Note that Google has a fairly personalized definition of non-personalized.

Google considers ads to be personalized when they are based on previously collected or historical data to determine or influence ad selection, including a user’s previous search queries, activity, visits to sites or apps, demographic information, or location. Specifically, this would include, for example: demographic targeting, interest category targeting, remarketing, targeting Customer Match lists, and targeting audience lists uploaded in DoubleClick Bid Manager or Campaign Manager.

Non-personalized ads are ads that are not based on a user’s past behavior. They are targeted using contextual information, including coarse (such as city-level) geo-targeting based on current location, and content on the current site or app or current query terms. Google disallows all personalized targeting, including demographic targeting and user list targeting.

This explanation is written for webpage ads as well as app ads. Google does not have access to the URL that is being visited in Privacy Browser (they better not, anyway). But the advertisers do know that Privacy Browser Free is making the request, and they know things like city-level location.

With the removal of the Ad Consent library, all users of Privacy Browser Free will be shown the ad consent dialog. This complies with the GDPR and doesn’t require that Google attempt to determine if a user is in Europe every time the app launches (although they will do so anyway when they load an ad).

This removes the ability to specify users as under age. The irony of using a tracking library to specify that a user does not want to be tracked is not lost on me. Some may consider it futile to remove one Google library when Privacy Browser Free is still using Google’s Firebase Ads library to display ads and is built using Google’s Android suite of libraries and build tools to run on Android. Ultimately, my decision was made based on a desire to minimize my exposure to Google’s libraries beyond the standard Android toolchain. I would eventually like to replace the Firebase Ads library, but I will only do so when I find an ad network that I can independently verify takes user privacy seriously.

Beginning with Privacy Browser Free 2.15, all users will be show the following ad consent dialog when they launch the app for the first time.